MCP-серверы простыми словами

Спроси ассистента в IDE, какие поля есть в записи журнала потоков VPC. Он ответит по обучающим данным: гладко, уверенно и, вполне возможно, уже неверно. MCP-сервер даёт ему источник получше.

MCP-сервер это небольшая программа, которая добавляет ИИ-приложению одну новую способность: искать по этой документации, ходить в эту базу, запускать эту утилиту. Model Context Protocol (MCP), который Anthropic представила в ноябре 2024 года, это контракт, по которому такие программы подключаются к приложениям.

До MCP каждое ИИ-приложение подключало интеграции по-своему. Инструмент, через который один ассистент ходил в базу PostgreSQL, для следующей IDE приходилось собирать заново. Документация MCP сама сравнивает протокол с портом USB-C для ИИ-приложений: один разъём, много устройств. Но, как и с USB-C, всё работает, только если обе стороны договорились о деталях. К этому вернёмся в конце.

Как это устроено

Ролей три. Хост это приложение, в котором работаешь: Claude Code, IDE, фреймворк для агентов. Внутри хоста MCP-клиент держит соединение ровно с одним MCP-сервером. Хост с пятью серверами запускает пять клиентов.

Большинство серверов используют ради инструментов. Схема работы такая:

1. Клиент спрашивает сервер, что тот умеет (tools/list). Для каждого инструмента сервер возвращает имя, описание и JSON-схему входных параметров.
2. Хост передаёт эти описания модели вместе с промптом.
3. Когда модели нужен инструмент, она предлагает вызов. Хост его проверяет, при необходимости спрашивает разрешения у пользователя, и клиент отправляет tools/call.
4. Сервер запускает инструмент и возвращает результат. Хост кладёт результат обратно в контекст модели.

Хост координирует, сервер даёт доступ к системе, модель принимает решения. Заметь, чего модель не делает: с сервером она не общается вообще. Она предлагает вызов, а делает его хост.

Инструменты это одна из трёх вещей, которые может предложить сервер. Ресурсы это данные, которые приложение может прочитать, у каждого свой URI. Промпты это шаблоны сообщений, которые выбирает пользователь. Всё это ходит в виде сообщений JSON-RPC 2.0.

Что говорит текущая спецификация

На октябрь 2026 года последняя редакция спецификации называется 2026-07-28. Четыре момента в ней легко понять неправильно:

• Два стандартных транспорта. В stdio клиент запускает сервер как дочерний процесс, и они обмениваются JSON-RPC построчно через stdin и stdout. В Streamable HTTP каждое сообщение уходит POST-запросом на один MCP-эндпоинт, а ответ приходит в виде JSON или SSE-потока, привязанного к этому запросу. Всё остальное, включая WebSocket, это нестандартный транспорт. Спецификация такие транспорты разрешает, но работают они, только если их поддерживают обе стороны. Claude Code, например, принимает тип сервера ws в JSON-конфигурации. Это возможность клиента, а не часть стандарта.
• Сессий на уровне протокола нет. Рукопожатия initialize больше нет. Каждый запрос несёт версию протокола и возможности клиента в _meta, поэтому самому MCP больше не нужна привязка к экземпляру сервера. А сможет ли любая реплика обработать вызов, зависит от того, где инструмент хранит своё состояние. Если серверу нужно состояние между вызовами (открытая транзакция, корзина покупок), он возвращает явный идентификатор из одного инструмента и принимает его аргументом в следующем.
• Любой обмен начинает клиент. Серверу запрещено отправлять JSON-RPC-запросы. Он отвечает на запросы, может слать уведомления о запросе, который ещё выполняется (например, о прогрессе), и присылает уведомления об изменениях в поток, который клиент открыл через subscriptions/listen. Если серверу посреди вызова что-то нужно, например подтверждение от пользователя, он отвечает результатом input_required, и клиент повторяет исходный запрос, приложив ответы.
• Подписка сообщает о самом факте изменения, а не о его содержимом. Для ресурса с подпиской сервер присылает notifications/resources/updated с URI. Новое содержимое клиент забирает сам через resources/read.

А теперь страшная тайна, и она про третий пункт. По текущей спецификации сервер не может отправить клиенту ни одного запроса. Всё, что он говорит, это либо ответ, либо уведомление.

Обновление, октябрь 2026: В первой версии статьи MCP назывался двунаправленным, с состоянием и не зависящим от транспорта. Там же говорилось, что сервер может сам присылать клиенту ресурсы, а WebSocket значился среди транспортов. В редакции 2025-11-25 действительно были рукопожатие initialize, сессии и запросы от сервера, но даже там подписка только сообщала, что ресурс изменился, а WebSocket никогда не входил в стандартные транспорты. Редакция 2026-07-28 убрала рукопожатие и сессии протокола, заменила запросы от сервера многошаговыми запросами (MRTR) и перенесла уведомления об изменениях в subscriptions/listen. Ещё она объявила устаревшими Roots, Sampling и Logging. Клиенты и серверы, которые поддерживают обе эпохи, распознают, на какой версии работает другая сторона, и переключаются на совместимый режим.

Три сервера, которыми я пользуюсь

Два из трёх это серверы AWS, и да, я работаю в AWS. Вот что умеет каждый и где он запущен.

AWS Documentation MCP работает локально. Клиент запускает его через uvx и общается с ним по stdio. Его инструменты ищут по документации AWS через официальный поисковый API документации (search_documentation), забирают страницу в Markdown (read_documentation, read_sections), вытаскивают нужные строки из больших таблиц вроде квот сервисов (search_table) и подсказывают связанные страницы (recommend). Я спрашиваю: «Какие поля есть в записи журнала потоков VPC? Дай ссылку на страницу». Модель ищет, читает страницу и отвечает по актуальной документации, со ссылкой, которую можно проверить.

AWS Knowledge MCP это полностью управляемый удалённый сервер. AWS размещает его по адресу https://knowledge-mcp.global.api.aws, подключение идёт по Streamable HTTP. Ему не нужны ни аккаунт AWS, ни аутентификация. Но у него есть лимиты на частоту запросов, а клиент должен уметь работать с удалёнными серверами (или запускать прокси из stdio в HTTP). Индекс у него шире документации: справочники API, анонсы новинок, руководства по началу работы, блоги, архитектурные материалы, рекомендации Well-Architected, руководства по устранению неполадок, документация CDK и CloudFormation, Amplify и Strands Agents, а также навыки для агентов. Ещё он отвечает на вопросы о доступности сервисов по регионам. Я беру его, когда ответ собирается из нескольких источников: «Доступен ли этот API в моём регионе и что про этот паттерн говорит Well-Architected?»

Разница в одной таблице:

Если клиент умеет работать с удалёнными серверами, Knowledge MCP охватывает больше, и его собственный FAQ предлагает просто попробовать. Documentation MCP по-прежнему полезен, когда нужен локальный процесс или документация AWS для Китая. Но при AWS_DOCUMENTATION_PARTITION=aws-cn доступны только read_documentation и get_available_services.

QMD ищет по моему хранилищу Obsidian. QMD (Query Markup Documents) это локальный поисковый движок для Markdown с открытым исходным кодом. В нём есть полнотекстовый поиск BM25 (qmd search), векторный поиск (qmd vsearch) и гибридный режим с расширением запроса, слиянием рангов и переранжированием языковой моделью (qmd query), причём модели работают на локальной машине. Команда qmd mcp отдаёт тот же поиск как MCP-сервер: по умолчанию через stdio, а если нужен один общий долгоживущий процесс, то через HTTP. В моём хранилище лежат архитектурные заметки, разборы проблем с Kubernetes и материалы курсов. Я спрашиваю: «Покажи мои заметки про консолидацию в Karpenter». Модель вызывает инструмент query из QMD, получает подходящие заметки с путями и отвечает по моим собственным заметкам, а не по общим обучающим данным.

Вот все три в проектном .mcp.json для Claude Code: два локальных процесса и один удалённый эндпоинт.

{
  "mcpServers": {
    "awslabs.aws-documentation-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR",
        "AWS_DOCUMENTATION_PARTITION": "aws"
      }
    },
    "aws-knowledge-mcp-server": {
      "type": "http",
      "url": "https://knowledge-mcp.global.api.aws"
    },
    "qmd": {
      "command": "qmd",
      "args": ["mcp"]
    }
  }
}

Каждый из них это тонкая прослойка над источником данных. Рассуждает модель, доступ даёт сервер. И все три только читают. Многие серверы ещё и пишут: заводят тикеты, применяют манифесты Kubernetes, меняют облачные ресурсы. Протокол тот же, радиус поражения совсем другой.

Что значит «простыми словами»

MCP-серверы не магия. Сервер это JSON-RPC API, у которого контрактом служит схема.

Если ошибается источник, ошибается и ответ. Устаревшая документация даёт устаревшие ответы, а база с плохими данными кормит модель плохими данными. Модель опирается на результат инструмента, когда строит ответ, поэтому выбирать надёжные серверы приходится самому. Всё, что сервер приносит из внешнего мира, это недоверенный ввод: загруженный извне контент давно стал классическим каналом для промпт-инъекций.

Аутентификация зависит от сервера. Для AWS Knowledge MCP она не нужна. В конфигурации AWS Documentation MCP учётных данных AWS нет. Серверы, которые вызывают API AWS, используют те учётные данные, которые им дали, обычно профиль AWS и регион. Для HTTP-серверов спецификация описывает авторизацию через OAuth. Для stdio она рекомендует брать учётные данные из окружения.

При stdio клиент запускает сервер как локальный процесс. Этот процесс работает с правами пользователя ОС и с теми учётными данными и переменными окружения, которые ему передали. Сервер, запущенный с админским профилем, может всё, что этот профиль разрешает, даже если отдавать такие права никто не собирался. Поэтому выдавай каждому серверу только те права, которых хватает для его задачи, и выбирай серверы, которые по умолчанию только читают. Сервер EKS MCP, например, отказывается выполнять изменяющие операции, пока не добавишь --allow-write. Вызовы, которые что-то меняют, пусть подтверждает человек. Спецификация рекомендует всегда оставлять человеку возможность отклонить вызов инструмента.

Контекст это бюджет. Каждое описание инструмента занимает место в контексте, когда клиент передаёт его модели. Если клиент передаёт все описания сразу, часть бюджета уходит ещё до первого сообщения. Сколько именно, зависит от числа инструментов, размера их схем и того, как клиент их загружает, а не от одного только числа серверов. Клиенты решают это по-разному. Claude Code по умолчанию откладывает загрузку MCP-инструментов: на старте сессии загружаются только имена инструментов и инструкции серверов, а полные описания он подтягивает через поиск инструментов, когда они нужны. В Kiro для этого есть powers (появились в декабре 2025 года). Power это пакет, который объединяет конфигурацию MCP-сервера с инструкциями и включается по ключевым словам в разговоре, так что его инструменты загружаются, только когда они нужны задаче. Самое дешёвое решение работает в любом клиенте: подключай только те серверы, которые нужны для работы.

Когда писать свой

Начни с серверов, которые кто-то поддерживает. На 5 октября 2026 года в репозитории awslabs/mcp в src/ лежал 61 каталог с серверами, один из них помечен как устаревший. Там есть серверы для EKS, ECS, CloudWatch, DynamoDB, IAM, а также для цен и биллинга.

Со старыми эталонными серверами осторожнее. Исходные серверы PostgreSQL, GitHub, Slack и Google Drive от проекта MCP переехали в архив servers-archived: их больше не поддерживают и не выпускают для них исправлений безопасности. Действующий эталонный набор (Filesystem, Git, Fetch, Memory и ещё несколько) нужен, чтобы показать протокол и SDK, и в его README прямо сказано, что для продакшена эти серверы не предназначены. Для настоящей интеграции выбирай активно поддерживаемый сервер, часто от самого вендора, и ищи его в MCP Registry. Для понимания масштаба: в декабре 2025 года проект MCP насчитывал 10 тысяч активных серверов.

Свой сервер пиши, когда под задачу ничего не подходит. Для внутреннего API, CMDB, системы тикетов или конвейера деплоя сначала проверь готовые коннекторы и серверы на основе OpenAPI. Свой пиши, если они не подходят. Протокол здесь самое простое, потому что всю работу с сообщениями берут на себя официальные SDK (к первому уровню относятся SDK для TypeScript, Python, Go, C#, Rust и Ruby). Сложно другое: сделать инструменты полезными. Лучше вообще без инструмента, чем с тем, который вываливает всю таблицу в JSON. Возвращай полезные срезы: отфильтрованные, постраничные, с теми полями, которые нужны модели для следующего шага.

Перед тем как писать, проверь, что уже есть. Сначала казалось, что для моего хранилища придётся писать свой сервер. У него своя структура папок, и универсальный сервер Filesystem ищет файлы по glob-шаблону, но не заметки по смыслу. В QMD уже был гибридный поиск по Markdown с переранжированием результатов, так что мне хватило встроенного MCP-сервера.

Куда всё движется

Следующая остановка MCP после IDE: агенты в продакшене. Amazon Bedrock AgentCore Runtime умеет запускать MCP-серверы по Streamable HTTP, а AgentCore Gateway превращает API и функции Lambda в MCP-совместимые инструменты за одним эндпоинтом. Strands Agents загружает инструменты MCP-сервера и отдаёт их агенту как любые другие инструменты. Тот же сервер, что подключён к Claude Code, может стоять за агентом в продакшене. Здесь помогает ядро без состояния из спецификации 2026-07-28: без сессий протокола запросы расходятся по экземплярам, как в любой другой HTTP-нагрузке, если сам инструмент не держит состояние на конкретной реплике.

Переход от инструмента разработчика к продакшен-среде меняет приоритеты. На первый план выходят задержка, надёжность и наблюдаемость. Сервер, которого хватает для интерактивной работы в IDE, может оказаться слишком медленным или хрупким для агентного цикла, который вызывает инструменты параллельно и повторяет неудачные вызовы.

Если делаешь серверы для агентов в продакшене, относись к ним как к любому другому сервису. Логируй каждый вызов инструмента. Отдавай метрики: число вызовов, задержку, долю ошибок. Сообщай о сбоях как об ошибках самого инструмента (isError: true) с понятным сообщением, чтобы агент мог исправить входные данные и повторить вызов, а не гадать. Данные для программной обработки возвращай в structuredContent, а структуру ответа описывай через outputSchema, где это помогает. При временных сбоях повторяй вызов с растущей задержкой и ограничением числа попыток, а для записи сначала защитись от повторного выполнения. Прежде чем подключать агента, проверь сервер под нагрузкой. Заранее задай целевую задержку, число одновременных запросов и пропускную способность.

Контракт

MCP это открытый стандарт. В декабре 2025 года Anthropic передала его в Agentic AI Foundation (AAIF), целевой фонд при Linux Foundation. Фонд основали Anthropic, Block и OpenAI при поддержке Google, Microsoft, AWS, Cloudflare и Bloomberg. Спецификация и SDK открыты, а техническое направление по-прежнему определяют мейнтейнеры MCP.

В этом и смысл. Сервер пишешь один раз, и он работает в Claude Code, Cursor, Kiro, VS Code и других клиентах. Условие такое: у обеих сторон общая версия протокола и транспорт, а клиент поддерживает возможности, на которые опирается сервер. Редакция 2026-07-28 поменяла то, что идёт по сети, так что проверь эти три пункта, прежде чем обещать «работает везде».

Кто хоть раз делал одну и ту же интеграцию для пяти разных ИИ-инструментов, тот знает, почему это важно.

Связанные материалы

• Доклад: Построение Production GenAI: MCP и мульти-агентные системы, Code Europe, Краков, 2025-07-01. MCP на живых демо: диагностика Kubernetes и генерация Terraform.
• Доклад в формате chalk talk: AWS Summit Warsaw 2026 (DOP202), Integrated AI Agents & Code Assistants with MCP & AWS, 2026-05-06.
• Спецификация: modelcontextprotocol.io/specification/latest (внешний ресурс, первоисточник).

Источники

Утверждения о протоколе и AWS сверены с этими официальными источниками 2026-10-05.

• Спецификация MCP 2026-07-28: транспорты, шаблоны обмена сообщениями, ресурсы, инструменты и что изменилось с 2025-11-25
• Блог MCP: The 2026-07-28 Specification и MCP joins the Agentic AI Foundation
• modelcontextprotocol/servers и modelcontextprotocol/servers-archived
• awslabs/mcp: AWS Knowledge MCP Server, AWS Documentation MCP Server и Amazon EKS MCP Server
• Общая доступность AWS Knowledge MCP Server (What’s New, 2025-10-01)
• Deploy MCP servers in AgentCore Runtime и AgentCore Gateway
• Strands Agents: MCP tools
• Claude Code: MCP и Introducing Kiro powers
• tobi/qmd