Зробіть сайт доступним для виклику агентами: 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 зарезервований для discovery на транспортному рівні. 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 discovery, а не замінює його. 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 і discovery через каталог співіснують. Використовуйте формулювання з урахуванням версій і перевіряйте, що насправді очікує ваш клієнт чи валідатор.
• Вкладати в картку список інструментів. Перелік примітивів винесли з 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.