MCP Server Card: как AI-агенты находят ваш сервер

MCP Server Card: как AI-агенты находят ваш сервер

Представьте, что интернет — это огромный город, а AI-агенты (вроде Claude, ChatGPT или будущих версий других ассистентов) — это курьеры, которые пытаются выполнить ваши поручения. Раньше они умели только «читать» сайты, то есть анализировать HTML-страницы. Но теперь им нужно не просто читать, а действовать: забронировать столик, найти товар по API, проверить наличие билетов. Для этого им нужен не просто сайт, а специальный «вход» — сервер, который понимает их язык запросов.

Здесь на сцену выходит Model Context Protocol (MCP) — открытый протокол, представленный компанией Anthropic в конце 2024 года. Если совсем просто: MCP — это способ, которым AI-агент подключается к внешним инструментам и данным. Агент (клиент) соединяется с MCP-сервером, а тот предоставляет ему набор «ручек» — инструментов (tools), ресурсов (resources) и шаблонов запросов (prompts). Но возникает логичный вопрос: как агент узнает, что у вас есть такой сервер? Как он найдет «входную дверь» в этом огромном городе?

Ответ, который сейчас формируется в сообществе разработчиков, — это так называемая MCP Server Card. Это не просто файл, а целая концепция «визитной карточки» вашего MCP-сервера, размещенная в предсказуемом месте вашего домена. В этой статье мы подробно разберем, что это такое, как это работает, кому это нужно, и почему пока это скорее развивающаяся практика, а не железный стандарт.

Проблема обнаружения: почему агенты не могут просто «постучаться»

Давайте разберемся с базовой архитектурой. MCP — это клиент-серверная модель. У вас есть:

• MCP-клиент — это среда, в которой живет AI-агент (например, десктопное приложение Claude, IDE или ваш собственный сервис).
• MCP-сервер — это программа (часто запущенная как отдельный процесс или доступная по HTTP), которая предоставляет агенту доступ к конкретным функциям: поиску по базе данных, отправке форм, получению курсов валют и т.д.

Протокол MCP определяет, как клиент и сервер общаются (формат сообщений, типы запросов). Но он не определяет, как клиент находит сервер. В мире традиционных API эту проблему решают с помощью документации: разработчик читает мануал, узнает URL эндпоинта и вручную прописывает его в коде. Для AI-агентов такой подход не работает. Агент не может прочитать документацию в браузере и понять, что ему нужно отправить POST-запрос на https://api.example.com/mcp.

Агентам нужен автоматический, предсказуемый способ обнаружения. Представьте, что вы говорите агенту: «Проверь наличие мест в отеле на сайте booking.example.com». Агент не знает, есть ли у этого сайта API, и тем более не знает, какой у него адрес. Ему нужна подсказка. И эта подсказка должна лежать в стандартном месте, чтобы агент мог проверить её за доли секунды.

Именно эту проблему и призвана решить MCP Server Card.

Историческая аналогия: /.well-known/ai-plugin.json и уроки прошлого

Эта проблема не нова. Когда в начале 2023 года экосистема плагинов ChatGPT только зарождалась, OpenAI столкнулась с той же задачей: как позволить ChatGPT находить сторонние плагины? Решение было простым и элегантным — использовать стандарт /.well-known/, который уже был зарезервирован для метаданных (например, /.well-known/security.txt или /.well-known/appspecific/com.apple.configurationprofiles).

Для плагинов ChatGPT был предложен путь /.well-known/ai-plugin.json. Этот файл содержал описание плагина: его название, описание для модели, логотип и, самое главное, URL к API. ChatGPT, получив задачу от пользователя, мог автоматически запросить этот файл у сайта, прочитать его и понять, как подключиться к плагину.

Важно подчеркнуть: это был исторический пример для другой, более ранней экосистемы. Экосистема плагинов ChatGPT была закрытой и централизованной (OpenAI контролировала магазин плагинов). MCP — это открытый протокол, и экосистема вокруг него гораздо более децентрализованная. Тем не менее, идея использования /.well-known/ для обнаружения метаданных оказалась настолько удачной, что сообщество разработчиков MCP естественным образом обратилось к ней.

По сути, MCP Server Card — это попытка применить тот же принцип, что и ai-plugin.json, но для новой, более гибкой и открытой экосистемы. Это не прямое копирование, а скорее эволюционное развитие той же идеи: сделать так, чтобы сервер можно было найти без предварительной настройки.

Честный разбор: почему единого стандарта пока нет

Теперь самое важное, о чем мы обязаны сказать честно и прямо: на данный момент (середина 2025 года) не существует единого ратифицированного стандарта для MCP Server Card. Это не официальная часть спецификации MCP, которую выпустила Anthropic. Спецификация MCP определяет протокол взаимодействия, но не определяет механизм обнаружения серверов через well-known URL.

То, что мы называем MCP Server Card — это сложившаяся, развивающаяся практика. Разработчики и компании, которые уже запустили свои MCP-серверы, интуитивно пришли к использованию /.well-known/ путей по аналогии с другими стандартами. Они публикуют JSON-файлы с описанием своих серверов, надеясь, что клиенты (AI-агенты) научатся их находить.

Что это значит на практике?

• Нет гарантии, что ваш файл будет найден. Разные клиенты могут искать разные пути. Кто-то ожидает /.well-known/mcp.json, кто-то — /.well-known/mcp/server.json, а кто-то — просто /mcp.json в корне.
• Нет утвержденной схемы JSON. Поля, которые вы включите в карточку, могут быть проигнорированы или интерпретированы неверно. Спецификация MCP определяет поля для сервера (name, version, protocolVersion), но не для файла-визитки.
• Это поле для экспериментов. Сейчас сообщество активно обсуждает, как должен выглядеть этот файл. Возможно, через год появится официальная рекомендация, но пока мы находимся в стадии «дикого запада».

Означает ли это, что не нужно ничего делать? Нет, совсем наоборот. Как и в случае с ранними веб-стандартами, те, кто внедряет практику сейчас, формируют будущий де-факто стандарт. Если большинство MCP-серверов будут публиковать карточку по пути /.well-known/mcp.json, то клиенты начнут искать именно там. Это самоподдерживающийся процесс.

Наш инструмент «Проверка MCP Server Card» создан именно для того, чтобы помочь вам сориентироваться в этой неопределенности. Он проверяет несколько наиболее распространенных кандидатных путей и сообщает, нашли ли они валидный JSON.

Практика: какие пути проверяет инструмент и как оформить карточку

Наш инструмент проверки не гадает, а действует системно. Он последовательно обращается к нескольким путям на вашем домене, которые сообщество разработчиков чаще всего обсуждает как кандидатов на стандартное место размещения MCP Server Card. Вот эти пути:

• /.well-known/mcp.json — наиболее вероятный кандидат, следующий логике стандарта /.well-known/.
• /.well-known/mcp/server.json — вариант с подпапкой для серверов, если планируется размещать несколько типов метаданных.
• /mcp.json — простой путь в корне домена, который также встречается в обсуждениях.

Инструмент заходит на каждый из этих путей и проверяет, возвращается ли валидный JSON. Если JSON найден, он проверяет наличие обязательных (базовых) полей: name и version или protocolVersion. Это минимальный набор, без которого карточку нельзя считать полезной.

Как же выглядит правильно оформленная карточка? Вот пример валидного JSON, который удовлетворит и наш инструмент, и большинство клиентов:

{
  "name": "example-hotel-booking",
  "description": "MCP-сервер для поиска и бронирования номеров в отелях. Предоставляет инструменты для поиска по датам, количеству гостей и фильтрам.",
  "version": "1.2.0",
  "protocolVersion": "2024-11-05",
  "server": {
    "url": "https://api.example.com/mcp",
    "type": "http"
  },
  "tools": [
    {
      "name": "search_hotels",
      "description": "Поиск доступных отелей по заданным критериям"
    },
    {
      "name": "book_room",
      "description": "Бронирование конкретного номера"
    }
  ]
}

Разберем поля подробнее:

• name (обязательное) — уникальное имя вашего MCP-сервера. Оно должно быть кратким и отражать суть сервиса.
• description (желательное) — описание для AI-агента. Важно! Агент читает это описание, чтобы понять, может ли ваш сервер помочь с задачей пользователя. Пишите четко, какие функции вы предоставляете и какие проблемы решаете.
• version (обязательное) — версия вашего сервера. Рекомендуется использовать семантическое версионирование (например, 1.2.0).
• protocolVersion (обязательное) — версия протокола MCP, которую поддерживает ваш сервер. На момент написания статьи актуальной является версия, указанная в официальной документации MCP (например, 2024-11-05).
• server.url — фактический URL, по которому MCP-клиент может подключиться к вашему серверу. Это может быть эндпоинт HTTP или другой тип транспорта.
• tools — краткий перечень инструментов, которые вы предоставляете. Это не обязательно, но помогает агенту быстро оценить функциональность.

Обратите внимание: это не финальная схема, а рекомендуемая практика. Поля могут меняться по мере развития экосистемы.

Кому это нужно уже сейчас, а кому рано об этом думать

Мы будем максимально честны: MCP Server Card нужна не всем. Если у вас обычный контентный сайт (блог, новостной портал, корпоративный лендинг) без какого-либо API, то этот инструмент вам не нужен. AI-агенты и так могут читать ваш контент через HTML. Им не нужен MCP-сервер для того, чтобы прочитать статью или узнать ваш телефон.

MCP Server Card актуальна для сайтов и сервисов, которые уже предоставляют MCP-сервер для внешних интеграций. Это, например:

• Сервисы бронирования (отели, рестораны, билеты на мероприятия) — если у вас есть API для поиска и бронирования, имеет смысл предоставить его через MCP.
• Поисковые и аналитические платформы — если у вас есть API для поиска по базе данных товаров, документов или любых других сущностей.
• Бизнес-инструменты — CRM, бухгалтерия, управление проектами. Если у вас есть API, вы можете захотеть, чтобы AI-агенты могли с ним работать.
• Погодные сервисы, курсы валют, любые открытые данные — если у вас есть API, который может быть полезен агенту.

Если вы относитесь к этой категории, то размещение MCP Server Card — это способ заявить о себе в мире AI. Это как разместить файл robots.txt для поисковых ботов, но только для AI-агентов. Вы говорите: «Эй, агенты, у меня есть API, и вот как к нему подключиться».

Если же у вас нет API и вы не планируете его создавать, то вам действительно рано об этом думать. Сосредоточьтесь на классическом SEO: качественный контент, правильная разметка, быстрая загрузка. Когда (и если) у вас появится API, тогда и вернетесь к этой теме.

Связь с архитектурой MCP: tools, resources, prompts

Чтобы лучше понять, зачем нужна MCP Server Card, давайте кратко рассмотрим, как устроен MCP-сервер изнутри. Это поможет вам правильно составить описание в карточке.

MCP-сервер предоставляет клиенту три типа сущностей:

• Tools (инструменты) — это функции, которые агент может вызывать. Например, search_hotels, book_room, get_exchange_rate. Инструмент принимает параметры (в формате JSON Schema) и возвращает результат. Это аналог функций в программировании.
• Resources (ресурсы) — это данные, которые агент может прочитать. Например, файл с прайс-листом, база знаний, лог событий. Ресурсы имеют URI и могут быть прочитаны клиентом.
• Prompts (шаблоны запросов) — это готовые промпты, которые сервер предлагает клиенту. Они помогают агенту правильно сформулировать запрос к серверу. Например, шаблон «Поиск отеля» может содержать подсказки по параметрам.

Когда агент находит ваш MCP-сервер (например, через MCP Server Card), он сначала получает список доступных tools, resources и prompts. Затем он решает, какой инструмент вызвать для решения задачи пользователя.

MCP Server Card служит своеобразным «входным билетом» в этот мир. Она не заменяет сам процесс обнаружения tools (это происходит через протокол MCP после подключения), но она позволяет агенту найти ваш сервер и понять, стоит ли к нему подключаться.

Как проверить MCP Server Card у себя

Проверить, правильно ли вы оформили карточку и доступна ли она по ожидаемым путям, очень просто. Для этого мы создали специальный инструмент «Проверка MCP Server Card».

Вам нужно просто ввести адрес вашего сайта (домен) в форму. Инструмент сделает следующее:

1. Проверит наличие файла по путям /.well-known/mcp.json, /.well-known/mcp/server.json и /mcp.json.
2. Проверит, является ли содержимое валидным JSON.
3. Проверит наличие базовых полей name и version или protocolVersion.
4. Выдаст отчет с указанием, какие пути работают, а какие нет, и какие поля отсутствуют.

Если инструмент не находит файл, это не значит, что у вас нет MCP-сервера. Это значит лишь, что вы не разместили карточку-визитку в ожидаемом месте. Если же вы еще не создали карточку, но имеете MCP-сервер, рекомендуем сделать это сейчас, пока экосистема формируется.

Кроме того, вы можете проверить доступность вручную, открыв в браузере адрес https://ваш-сайт/.well-known/mcp.json. Если вы увидите JSON, значит, файл доступен.

FAQ: Частые вопросы о MCP Server Card

1. Это не выдумка, а реальная вещь?

Да, это реально существующая практика, которую обсуждают и внедряют разработчики в экосистеме MCP. Однако важно понимать: это не официальный стандарт, ратифицированный какой-либо организацией. Это развивающаяся практика, основанная на аналогии с другими well-known файлами (например, /.well-known/ai-plugin.json из экосистемы плагинов ChatGPT). Наш инструмент проверяет именно эти неофициальные, но распространенные пути.

2. Где официальная документация на MCP Server Card?

Официальной документации именно на «MCP Server Card» на данный момент не существует, потому что нет официального стандарта. Есть документация по самому протоколу MCP (на сайте modelcontextprotocol.io), но она не описывает механизм обнаружения через well-known файлы. Мы рекомендуем следить за обсуждениями в репозитории MCP на GitHub и в сообществе разработчиков.

3. Мой сайт на WordPress или Tilda. Могу ли я разместить MCP Server Card?

Технически да, если у вас есть доступ к файловой системе или возможность редактировать заголовки ответов сервера. На WordPress вы можете создать файл в корне сайта через FTP или использовать плагин для управления файлами. На конструкторах сайтов (Tilda, Readymag) это может быть сложнее, так как они не дают доступа к корневой директории. Если у вас нет возможности разместить файл по пути /.well-known/, вы можете использовать путь /mcp.json (в корне), если конструктор это позволяет.

4. Что если я размещу карточку по одному пути, а клиент ищет по другому?

Это риск, который существует из-за отсутствия стандарта. Чтобы минимизировать его, мы рекомендуем размещать карточку по всем трем путям, которые проверяет наш инструмент: /.well-known/mcp.json, /.well-known/mcp/server.json и /mcp.json. Содержимое файлов может быть одинаковым. Это не гарантирует, что все клиенты найдут вас, но значительно повышает шансы.

5. Какие поля обязательны, а какие нет?

Наш инструмент проверяет обязательность наличия полей name и version или protocolVersion. Это минимальный набор. Остальные поля (description, server.url, tools) желательны, но не обязательны для прохождения проверки. Однако для реальной работы AI-агента вам обязательно нужно указать URL вашего MCP-сервера, иначе агент найдет карточку, но не сможет подключиться.

6. MCP Server Card — это то же самое, что и файл sitemap.xml для SEO?

Концептуально есть сходство: оба файла помогают автоматизированным клиентам находить ресурсы. Но sitemap.xml предназначен для поисковых роботов, которые индексируют контент для поиска. MCP Server Card предназначена для AI-агентов, которые хотят не просто прочитать, а выполнить действие через ваш API. Это разные слои экосистемы, и они не заменяют друг друга. Хороший сайт может иметь оба файла.

В заключение напомним: мы находимся в начале пути формирования новой практики. MCP Server Card — это не панацея и не обязательный атрибут, но это важный шаг к тому, чтобы сделать ваш сервис доступным для нового поколения автоматизированных клиентов. Используйте наш инструмент «Проверка MCP Server Card», чтобы убедиться, что вы делаете все правильно, и следите за развитием экосистемы MCP. Возможно, уже через год этот файл станет таким же стандартным, как robots.txt.