Сделайте сайт доступным для вызова агентами: MCP, Agent Skills, A2A

Сделать сайт доступным для вызова агентами — значит опубликовать машиночитаемые точки обнаружения: MCP Server Card, индекс Agent Skills, A2A Agent Card — поверх контента, который агенты уже умеют читать. Первая волна «дружественного к ИИ веба» была про читаемость: robots.txt, llms.txt, зеркала в Markdown, структурированные данные, Link-заголовки. Это помогает агенту понять вашу страницу. Чтобы он начал действовать — оформить заказ, вызвать калькулятор, запустить рабочий процесс, — нужно решить другую задачу. Агенту нужно заранее знать, что он вообще может вызвать, по какому протоколу, на каком эндпоинте, с какой версией и с какими ограничениями.

Сразу оговорка, потому что сфера быстро меняется. По состоянию на июнь 2026 года большинство этих стандартов ещё не устоялись. MCP Server Card относится к экспериментальному расширению, а не к зафиксированной core-спецификации, а WebMCP — это черновик W3C Community Group, чья поверхность API продолжает меняться (дорожная карта Model Context Protocol). Поэтому относитесь к написанному ниже как к направлению, в котором рынок уже движется, а не как к готовому стандарту, который можно скопировать дословно.

Ключевые выводы

• Читаемый против доступного для вызова. Читаемый веб помогает агенту понять ваш контент; доступный для вызова — позволяет ему выполнить ваш рабочий процесс. Слой вызова — это обнаружение: карточки и манифесты, которые объявляют, что можно вызвать, где и как.
• MCP Server Card — это документ обнаружения, а не замена хэндшейка и не список инструментов. Текущая экспериментальная схема содержит идентичность (name, description, version) плюс remotes (транспорт type + url); инструменты обнаруживаются во время выполнения.
• Agent Skills объявляют процедуры, а не транспорт. Файл /.well-known/agent-skills/index.json перечисляет навыки по name, description, url и digest, а агенты загружают их постепенно.
• A2A Agent Card описывает удалённого агента как равноправный сервис по адресу /.well-known/agent-card.json (переименован из старого agent.json). WebMCP делает инструменты страницы доступными для вызова прямо в браузере.
• Внедрение пока крошечное: Cloudflare нашла MCP Server Card и API Catalog менее чем на 15 из 200 000 сайтов (Cloudflare, 2026). Просканируйте домен, чтобы увидеть, какие слои агент находит сегодня.

От читаемого к доступному для вызова: что на самом деле меняется?

Сдвиг — от понимания к вызову. Спецификация A2A проводит границу чётко: MCP стандартизирует, как агент подключается к инструментам, API и источникам данных, а A2A стандартизирует, как независимые агенты общаются друг с другом (A2A Protocol). MCP — это «как агент использует возможность»; A2A — «как один агент находит и вызывает другого как равного».

На практике они работают слоями. A2A-агент принимает задачу, а затем внутри себя обращается к MCP, чтобы вызвать нужные инструменты и данные. Так что это не конкурирующие стандарты — это разные этажи одного здания, и большинство реальных архитектур используют не один.

Вот формула, которую стоит запомнить: читаемый веб помогает агенту понять ваш контент; веб, доступный для вызова, помогает агенту выполнить ваш рабочий процесс. Первое приносит цитату или упоминание. Второе превращает ваш сайт, приложение или API в рабочую поверхность, которой агентные системы действительно могут управлять.

Ничего из этого не окупится без читаемого слоя под ним. Если агент вообще не может загрузить и разобрать ваши страницы — об этом речь в том, что такое готовность к ИИ-агентам — безупречный манифест ничего не изменит. Доступность для вызова — это следующий этаж, а не замена фундамента.

Что такое MCP Server Card и где он размещается?

MCP Server Card — это небольшой JSON-документ, который позволяет клиенту узнать об удалённом MCP-сервере, его идентичности и способе подключения к нему ещё до полного хэндшейка. Чаще всего путаются в двух вещах: где он размещается и что должно быть внутри.

Где он размещается: помните про дрейф пути

С путём нужно быть осторожным, потому что здесь реальный дрейф версий. Ранний черновик SEP-1649 предлагал /.well-known/mcp.json — именно поэтому «well-known mcp.json» сегодня ищут и цитируют. Но эта работа перешла в линию SEP-2127.

Текущее экспериментальное расширение снова смещает акцент. Карточка может размещаться по любому незарезервированному URI, а GET <streamable-http-url>/server-card зарезервирован для обнаружения на транспортном уровне. URL карточки клиенты должны узнавать через каталог, а не угадывать well-known путь (SEP-1649, экспериментальная схема). Поэтому не подавайте /.well-known/mcp.json как устоявшийся стандарт. Для июня 2026 года это слишком категорично.

Что входит в карточку

Форма тоже изменилась. В ранних материалах фокус был на serverInfo, protocolVersion, transport и capabilities. Текущая экспериментальная схема ServerCard больше похожа на метаданные реестра: обязательны $schema, name, description и version. Удалённые эндпоинты попадают в remotes, где каждой записи нужны type и url (supportedProtocolVersions и headers — необязательны).

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/v1/server-card.schema.json",
  "name": "com.example/weather",
  "description": "Remote MCP server for weather lookups and forecasts.",
  "version": "1.0.0",
  "remotes": [
    {
      "type": "streamable-http",
      "url": "https://api.example.com/mcp",
      "supportedProtocolVersions": ["2025-06-18"]
    }
  ]
}

Вот что большинство материалов понимает неправильно: карточка — это слой обнаружения, а не реестр всех инструментов. Обсуждение SEP-2127 намеренно держит перечисление примитивов (tools, resources, prompts) вне карточки, потому что статический манифест расходится с живой поверхностью, зависящей от авторизации, флагов функций и конфигурации (обсуждение discovery).

Во время выполнения сервер всё равно согласует protocolVersion и capabilities и отвечает на операции перечисления (схема MCP); карточка лишь подводит клиента к точке подключения. Сама её схема прямо называет свои поля рекомендательными, а не авторитетной основой для решений по безопасности.

Что объявляют Agent Skills?

Agent Skills отвечают на другой вопрос: не «куда подключаться?», а «какой процедуры придерживаться, работая с вами?». Навык — это каталог с обязательным SKILL.md и необязательными scripts/, references/ и assets/. Его YAML-фронтматтер требует name и description, и именно это описание сообщает агенту, что делает навык и когда его применять (спецификация Agent Skills).

Для веб-обнаружения RFC от Cloudflare добавляет индекс по адресу /.well-known/agent-skills/index.json. В версии v0.2.0 он содержит $schema и массив skills, где для каждой записи обязательны name, type, description, url и digest (agent-skills-discovery-rfc). digest — это SHA-256, которым клиент проверяет загруженный артефакт.

{
  "$schema": "https://schemas.cloudflare.com/agent-skills/index/v0.2.0.json",
  "skills": [
    {
      "name": "scan-url",
      "type": "skill-md",
      "description": "Run an agent-readiness scan on a public URL and read the 0–100 score.",
      "url": "https://example.com/.well-known/agent-skills/scan-url/SKILL.md",
      "digest": "sha256:7d8f…"
    }
  ]
}

Масштабируемость обеспечивает прогрессивное раскрытие. Сначала агент загружает лёгкий каталог — только имена и описания. Если задача подходит, он загружает полный SKILL.md. И только потом, лишь при необходимости, читает связанные файлы, скрипты и ресурсы. Агент может знать о десятках навыков, не расходуя контекст на все сразу.

Так что Agent Skills — это манифест применения, а не вызова. Они объявляют не транспорт и не эндпоинт, а процедуры: как правильно вызвать ваш API, как согласовать Markdown (см. как отдавать Markdown ИИ-агентам), как оформить заказ, как соблюсти ваши лимиты запросов. Карточка сообщает, что у вас есть; навык — как этим правильно пользоваться.

A2A Agent Card и WebMCP: где их место?

Если MCP Server Card описывает поверхность инструментов, то A2A Agent Card описывает удалённого агента как равноправный сетевой сервис. В A2A 1.0 клиент ищет её по адресу https://{domain}/.well-known/agent-card.json — теперь это постоянный well-known суффикс. Помните про дрейф: ранние версии A2A использовали /.well-known/agent.json; в актуальных релизах это agent-card.json (A2A Protocol, A2A v0.2.0). Это хрестоматийный пример, почему важны формулировки с учётом версий.

Карточка богаче, чем имя и краткое описание. A2A 1.0 включает name, description, version, supportedInterfaces (у каждого url, protocolBinding и protocolVersion), capabilities, securitySchemes, security, defaultInputModes, defaultOutputModes и skills, плюс необязательные provider, documentationUrl, signature и iconUrl. Это полноценное описание сервиса, а не низкоуровневое обнаружение инструментов.

Самый простой способ держать эти три сущности порознь:

WebMCP: инструменты в браузере

WebMCP требует самых аккуратных формулировок. Опубликованный черновик W3C открывает API через document.modelContext: у Document появляется modelContext с методом registerTool() и событием toolchange. Он работает только в защищённых контекстах (secure contexts), интегрируется с Permissions Policy со списком разрешённых источников по умолчанию 'self' и позволяет инструменту задавать видимость по origin через exposedTo (черновик WebMCP). Это не «LLM читает DOM» — это встроенный в браузер способ публиковать инструменты, доступные для вызова.

// WebMCP — the published draft surface (still evolving)
document.modelContext.registerTool({
  name: "add_to_cart",
  description: "Add a product to the cart by SKU.",
  // inputSchema, execute handler, …
});

Но navigator.modelContext — имя, которое вам могло попадаться, — тоже не выдумка. Протоколы заседаний WebML Community Group фиксируют резолюцию, называющую navigator.modelContext корневым объектом, и группа сейчас обдумывает, как внешние агенты должны перечислять и вызывать инструменты страницы (протоколы WebML CG). Честное резюме? Сегодня черновик по-прежнему ведёт с document.modelContext.registerTool(), тогда как рабочее направление — более общий объект на уровне браузера. Напишите так — и через квартал ваш материал не будет выглядеть устаревшим.

Как это связано с обнаружением API и OpenAPI?

Оно надстраивается над классическим обнаружением API, а не заменяет его. RFC 9727 стандартизирует /.well-known/api-catalog как URI, по которому клиент получает документ со ссылками на ваши опубликованные API и их описания — вместо того чтобы угадывать расположение файлов OpenAPI или парсить HTML-документацию (RFC 9727). А OpenAPI затем описывает каждый HTTP-API в машино- и человекочитаемой форме, так что клиент понимает поверхность и семантику, не читая исходники и не разбирая трафик (OpenAPI 3.2.0).

Каждый слой отвечает ровно на один вопрос. Вот и вся ментальная модель:

Проще говоря: делаете обнаружение API — ваша поверхность становится доступной для обнаружения; делаете MCP, A2A или WebMCP — она становится доступной для вызова; публикуете Agent Skills — она становится пригодной для правильного использования. Войны стандартов не требуется; это этажи одного здания, и вы обустраиваете те, что нужны вашему продукту. Контентный сайт может остановиться на читаемом слое; API оформления заказа или агентный сервис поднимается выше.

Какие ошибки встречаются чаще всего?

Главный провал — описывать нестабильную точку обнаружения как канон, и сильнее всего это бьёт по MCP. Пять сценариев встречаются снова и снова:

• Фантомные манифесты. Писать «стандарт MCP требует ровно такой путь», когда /.well-known/mcp.json, /.well-known/mcp/server-card.json, /.well-known/mcp-server и обнаружение через каталог сосуществуют. Используйте формулировки с учётом версий и проверяйте, что на самом деле ожидает ваш клиент или валидатор.
• Вкладывать в карточку список инструментов. Перечисление примитивов вынесли из Server Card намеренно. Статический список расходится с живой, зависящей от авторизации поверхностью и порождает неверные допущения по безопасности.
• Красивый манифест без рабочего эндпоинта и версии. remote нужны как минимум type и url; A2A supportedInterfaces нужны url, protocolBinding и protocolVersion. Discovery без транспорта и версионирования — это не интерфейс, доступный для вызова, а просто JSON-афиша.
• Считать Agent Skills ещё одним эндпоинтом. Навык не объявляет ни транспорта, ни биндинга. Это набор инструкций, загружаемый постепенно, — другой слой, нежели MCP или ваш API.
• Игнорировать дрейф версий. agent.json в A2A стал agent-card.json; WebMCP разрывается между document.modelContext и navigator.modelContext. Пропустите эти переходы — и за квартал ваш материал превратится в набор фантомных путей.

Общее во всех пяти случаях одно: обнаружение полезно, только когда ведёт к чему-то реальному и версионированному. Манифест, к которому нельзя подключиться, — это украшение.

Как проверить, что сайт доступен для вызова агентами?

Проверяете так же, как это делал бы агент: запрашиваете каждую точку обнаружения и убеждаетесь, что она парсится, ведёт к реальному эндпоинту и несёт версию. Это ограниченный, проверяемый список — ровно для этого и нужно сканирование. Категория протоколов и API в aiSiteReady почти полностью соответствует содержанию этой статьи. Она запускает проверку MCP Server Card, проверку индекса Agent Skills, проверку готовности A2A / WebMCP и проверку API Catalog. Рядом с ними — ещё примерно 15–20 проверок, которые объединяются в Agent Readiness Score от 0 до 100. Точные проверки и веса — на странице методологии.

А разрыв во внедрении — это и есть возможность. В апреле 2026 года Cloudflare сообщила, что стандарты вроде MCP Server Card и API Catalog встречались менее чем на 15 сайтах из выборки в 200 000 доменов (Cloudflare, 2026). Слой читаемого веба сейчас переполнен; этот — нет, и у тех, кто раньше других, ещё есть пространство.

Эти проверки мы строили на собственном стеке, и это заставляло нас проверять утверждения на практике. aiSiteReady предоставляет реальный MCP-сервер с Server Card, индекс Agent Skills с рабочим SKILL.md и API Catalog по RFC 9727, указывающий на публичный документ OpenAPI. Откройте /.well-known/agent-skills/index.json на этом домене и проверьте. Создавая сканер, мы прошли через каждую спецификацию выше; этот материал — устойчивая к изменениям версий карта, которой нам не хватало в самом начале.

Короткий чек-лист напоследок:

• Есть классический HTTP-API? Опубликуйте API Catalog и дайте ссылку на документацию OpenAPI.
• Есть удалённая MCP-поверхность? Опубликуйте MCP Server Card с метаданными транспорта и версии, а не только с именем.
• Публикуете удалённого агента? Добавьте A2A Agent Card по текущему well-known пути.
• Хотите, чтобы агенты правильно пользовались вашим продуктом? Опубликуйте индекс Agent Skills и настоящие файлы SKILL.md.
• Ваш продукт работает в браузере и содержит действия для пользователя? Поэкспериментируйте с WebMCP, чтобы сделать страницу доступной для прямого вызова.

Затем запустите бесплатное сканирование: оно загружает ваш домен так, как это сделал бы агент, и показывает, какие слои реально найдены, с исправлениями по влиянию — без регистрации, для любого публичного URL, с результатами на английском, украинском или русском. Оценка — это диагностика готовности, а не гарантия результата на последующих этапах.

Одна фраза, которую стоит запомнить: следующий этап веба для ИИ — это не просто сайты, которые приятно читать, а сайты и приложения, которые можно надёжно обнаружить, понять и вызвать через стандартные слои. Читаемость даёт цитирование. Доступность для вызова даёт использование.

У IMozz 20 лет в разработке ПО, а последний год он строит продукты с помощью LLM. Он развивает aiSiteReady — сканер только для чтения, который проверяет, может ли ИИ-агент прочитать и вызвать сайт, — а сам сервис как рабочий пример публикует собственную MCP Server Card и индекс Agent Skills.