📚KonspektСоздать свой

mcp-handbook

📝 Текст

MCP — стандарт интеграции AI

Что такое MCP

MCP (Model Context Protocol) — коммуникационный слой между приложением, в котором живёт модель, и внешним сервисом. Он переносит бремя написания и поддержки интеграций со стороны разработчика на сторону производителя сервиса.

До ноября 2024 каждый разработчик, желавший дать модели доступ к своему сервису, писал интеграцию с нуля. После — это стало похоже на покупку кабеля USB-C: один разъём, и любая модель видит твои данные.

Метафора USB-C

До USB-C каждое устройство носило свой разъём (micro-USB, Lightning, mini-jack). USB-C перевернул логику: один разъём — любое устройство. Производители согласились на общий стандарт, потому что выгода от совместимости сильнее, чем выгода от lock-in.

То же самое сделал MCP с интеграциями для AI. Notion больше не нужно делать отдельный плагин для ChatGPT, отдельный для Claude, отдельный для Cursor. Достаточно одного MCP-сервера — и любое приложение, поддерживающее протокол, увидит твои страницы и базы.

Экосистема к маю 2026

  • 24K+ MCP-серверов в Glama (крупнейший каталог)
  • 9 400 — в официальном реестре
  • 97 млн загрузок SDK в месяц
  • 6/6 гипер-скейлеров на борту: Anthropic, OpenAI, Google, Microsoft, AWS, Apple
  • В декабре 2025 протокол передан в Linux Foundation
  • Рост 8× за один год

Чёрный ящик MCP

На уровне «как это выглядит» MCP — чёрный ящик с двумя сторонами:

  • С одной — твоё приложение (Claude Desktop, Cowork, Cursor, ChatGPT с поддержкой Apps)
  • С другой — внешний сервис (GitHub, Notion, Google Calendar, локальная файловая система, 1С)

Внутри ящика — стандартный обмен сообщениями: «какие у тебя инструменты?», «выполни вот этот», «дай мне содержимое вот этого документа», «запусти вот эту workflow». Эти сообщения одинаковые для любого сервиса.

Почему MCP победил

MCP был не первой попыткой. До него существовали OpenAI Plugins (умерли в 2024), Custom GPTs, кустарные интеграции через iPaaS-платформы вроде Zapier и Make. У каждого была своя проблема: vendor-lock, ограниченность кругом одной компании, дороговизна, негибкость.

MCP победил по трём причинам:

  1. Открытость — спецификация публична с первого дня
  2. Простота — JSON-RPC поверх stdin/stdout или HTTP
  3. Скорость согласия отрасли — OpenAI присоединился через четыре месяца после релиза, Google через пять, Microsoft и AWS в течение года

Главный сдвиг для пользователя

Раньше модель была собеседником: ты ей пересказывал контекст, она отвечала. Теперь модель — исполнитель в твоих системах: она сама читает почту, ищет в Notion, обновляет CRM, оставляет комментарий в Linear. MCP — это пуповина, через которую это происходит.

Хронология 2024–2026

За восемнадцать месяцев MCP прошёл шесть ревизий и стал стандартом, переданным в Linux Foundation. В мире инфраструктурных протоколов это очень мало: SMTP проектировали два года, HTTP/1.1 — десять лет, WebSocket — пять.

Пять важных точек

Ноя 2024 — Anthropic выпускает MCP как open-source стандарт 25 ноября 2024. SDK на Python и TypeScript, шесть pre-built серверов: Google Drive, Slack, GitHub, Git, Postgres, Puppeteer.

Мар 2025 — OpenAI присоединяется 26 марта 2025. Sam Altman публикует: «people love MCP». Поддержка появляется в Agents SDK, затем в Responses API и Realtime API, в декабре 2025 в ChatGPT появляются Apps на базе MCP.

Апр 2025 — Google объявляет поддержку 9 апреля 2025. Demis Hassabis подтверждает: Gemini и его SDK будут поддерживать MCP. Managed-имплементация в Google Cloud — 10 декабря 2025 (официальные MCP-серверы для BigQuery, Maps, GKE, Compute Engine).

Сен 2025 — Apple тихо включается 22 сентября 2025. В первой dev-бете iOS 26.1 и macOS Tahoe 26.1 находят код MCP-поддержки. Без публичного анонса. К маю 2026 Apple Intelligence...

Эволюция MCP и архитектура протокола

Хронология принятия MCP

26 марта 2025 — OpenAI присоединяется к MCP. Sam Altman публикует сообщение: «people love MCP». Поддержка появляется в Agents SDK, затем в Responses API и Realtime API. В декабре 2025 в ChatGPT появляются Apps на базе MCP. Принятие стандарта главным конкурентом Anthropic снимает риск «один протокол одной компании».

9 апреля 2025 — Google объявляет поддержку. Demis Hassabis подтверждает: Gemini и его SDK будут поддерживать MCP. Реальная managed-имплементация в Google Cloud приходит 10 декабря 2025 — выходят официальные MCP-серверы для BigQuery, Maps, GKE, Compute Engine.

22 сентября 2025 — Apple тихо включается. В первой dev-бете iOS 26.1 и macOS Tahoe 26.1 находят код MCP-поддержки. Без публичного анонса. К маю 2026 Apple Intelligence работает с MCP-серверами через обновлённый Siri и App Intents.

8 декабря 2025 — Anthropic передаёт MCP в Agentic AI Foundation под зонтиком Linux Foundation. Протокол больше не зависит от одной компании. Vendor-lock как аргумент против использования MCP — мёртв.

Эволюция спецификации

За полтора года протокол прошёл от raw v0.1 до зрелого v1.0 — шесть ревизий. Скорость, нетипичная для инфраструктурных стандартов.

  • Март 2025 — появились tool annotations (отметки readOnly, destructive, idempotent) и новый транспорт Streamable HTTP, заменивший устаревший HTTP+SSE.
  • Июнь 2025 — добавили структурированный output для инструментов, ссылки на ресурсы внутри результатов инструментов, обязательную проверку audience у токенов через RFC 8707 Resource Indicators.
  • Ноябрь 2025 — в стабильную версию вошли Tasks API для долгих операций, формализованная Elicitation (структурный запрос ввода у пользователя) и Client Identity Metadata Document как альтернатива Dynamic Client Registration.

Версии спецификации

Дата Версия Ключевые изменения
2024-11-05 v0.1 Первый релиз
2025-03-26 v0.5 Streamable HTTP + annotations
2025-06-18 v0.8 Structured output + resource_link
2025-11-25 v1.0 Tasks · Elicitation · CIMD
в работе draft —

Практические последствия

MCP требует понимания, какая версия у host'а и у сервера. Самое распространённое окно несовместимости:

  • старый клиент не понимает новых полей вроде structuredContent;
  • новый клиент не получает annotations от старого сервера.

К маю 2026 production-сервера держат две версии параллельно: 2025-03-26 (большинство клиентов) и 2025-06-18+ (Claude Desktop, Cowork, новые SDK). Версия согласуется на этапе initialize-handshake.

Архитектура: три роли

В MCP три участника: host, client, server. Терминология отличается от привычной, потому что протокол спроектирован поверх JSON-RPC, где эти роли имеют исторический смысл.

Host — приложение пользователя

То, что пользователь открывает на компьютере или в браузере: Claude Desktop, Cowork, Cursor, Zed, VS Code с Copilot, ChatGPT, Microsoft Copilot Studio, Junie от JetBrains. У host'а есть пользовательский интерфейс, история разговоров, настройки и доступ к модели через API (OpenAI, Anthropic, Google или локальную).

Host решает, к каким MCP-серверам подключиться, как показывать пользователю результаты, когда требовать подтверждение. Host — «начальник», который пользуется библиотекой клиента, чтобы общаться с подчинёнными серверами.

MCP Client — библиотека внутри host'а

Не отдельное приложение, а кусок кода, который умеет говорить с MCP-серверами по протоколу JSON-RPC. Когда Claude Desktop показывает список инструментов от Notion-сервера — внутри работает MCP Client, который послал серверу запрос tools/list.

В одном host'е может быть несколько MCP Client сессий одновременно — по одной на каждый подключённый сервер.

MCP Server — обёртка для сервиса

Отдельный процесс или сервис, который говорит по протоколу MCP с одной стороны и понимает API внешнего сервиса с другой. Локальный MCP-сервер запускается как отдельный процесс (например, npx @modelcontextprotocol/server-filesystem). Удалённый MCP-сервер живёт на чужом сервере (например, mcp.notion.com/mcp).

MCP-сервер декларирует, что он умеет: какие инструменты предлагает, какие ресурсы хранит, какие готовые prompt'ы доступны. Эти три категории — tools, resources, prompts — называются примитивами.

Точные термины

  • «Клиент MCP» — библиотека внутри приложения, не пользователь.
  • «Сервер MCP» — программа-обёртка, не удалённая машина.
  • «Host» — полное приложение, в котором сидит и UI, и client, и модель.

С точки зрения пользователя видно только host. Всё, что под капотом — MCP Client, JSON-RPC, серверы — невидимо.

Три примитива

Все способы, которыми MCP-сервер может предоставлять что-то приложению, делятся на три категории. Главное отличие — кто решает, когда это использовать.

Примитив Кто управляет Описание
Tools Модель Функции, которые модель решает вызвать сама, чтобы получить информацию или выполнить действие. Пользователь не выбирает вручную. Примеры: search_files, get_weather, create_pr
Resources Приложение Read-only данные, которые подтягивает код host'а — не модель и не пользователь напрямую. Через них работает автодополнение в UI, drag-and-drop файлов, упоминания через @. Примеры: docs://documents, file:///plan.md, linear://issues/{id}
Prompts Пользователь «Быстрые команды» для юзера — слэш-команды и workflow-кнопки. Примеры: @notion-doc, @gmail-thread, /format/summarize

Один и тот же сервер может одновременно предоставлять tools, resources и prompts. Они независимы — у каждого свой триггер.

MCP примитивы и путь запроса

Три примитива MCP: кто управляет

В MCP есть три типа примитивов, каждый управляется своей стороной:

  • TOOLS — управляются моделью. Это функции, которые модель решает вызвать сама, чтобы получить информацию или выполнить действие. Пользователь не выбирает вручную — модель оценивает контекст и решает: «здесь нужен инструмент». Примеры: search_files, create_invoice, get_weather, create_pr.
  • RESOURCES — управляются приложением (host). Это read-only данные, которые подтягивает код host'а — не модель и не пользователь напрямую. Через них работает автодополнение в UI, drag-and-drop файлов, упоминания через @ и автоматическая подача контекста. Примеры: docs://documents, file:///plan.md, linear://issues/{id}.
  • PROMPTS — управляются пользователем. Это пред-собранные шаблоны workflow, которые пользователь запускает через слэш-команды, кнопки или меню. Внутри prompt — заранее отлаженная инструкция от автора сервера. Примеры: /format, /summarize, /code-review.

Почему это разделение важно

Если ты автор MCP-сервера — это разделение определяет, как пользователь будет с тобой взаимодействовать. Один и тот же функционал можно упаковать тремя способами.

Пример: задача «дать пользователю быстро отформатировать документ в Markdown»:

  • Можно сделать tool — модель сама решит вызвать, когда пользователь попросит «отформатируй».
  • Можно сделать prompt с командой /format — пользователь вызовет вручную.
  • Можно вообще не делать ни того, ни другого — а сделать resource для исходного документа и положиться на стандартное умение модели форматировать текст.

Хороший дизайн MCP-сервера использует все три примитива одновременно:

  • Tools — для действий, которые модель должна уметь делать самостоятельно.
  • Resources — для данных, которые приложение должно показывать в UI (выпадающий список файлов в @-меню).
  • Prompts — для workflow, которые пользователь хочет запускать прицельно, не описывая каждый раз словами.

Зачем это знать пользователю

Когда ты подключаешь новый MCP-сервер и видишь, что он предоставляет двадцать tools, пять resources и три prompts — ты понимаешь, чего ждать:

  • Двадцать tools — модель будет ими пользоваться, проси её прицельно.
  • Пять resources — попробуй @-упоминания в чате.
  • Три prompts — попробуй / и посмотри готовые workflow.

Пример в реальном интерфейсе: Claude Cowork

Возьмём Claude Cowork — десктопное приложение от Anthropic, которое в 2026 году стало флагманом MCP-экосистемы для не-программистов. Когда подключаешь MCP-сервер от Notion:

  • Tools. В диалоге, когда пишешь «создай в Notion план встречи на завтра», Claude сам решает вызвать create_page с нужными параметрами. Это происходит автоматически, ты видишь только подтверждение «Claude хочет выполнить инструмент».
  • Resources. Когда пишешь @ и видишь выпадающий список своих Notion-страниц с автодополнением — это resources. Cowork сам подтянул список через resources/list, показал для выбора, после выбора подтянул содержимое.
  • Prompts. Когда пишешь / и видишь готовые workflow вроде «Summarize meeting notes» или «Format as Markdown» — это prompts. Их написал автор MCP-сервера один раз, ты используешь без необходимости формулировать промпт самостоятельно.

Три разные части интерфейса, три разных способа взаимодействия — и всё это один протокол. Понимание разделения полезно даже если ты только пользователь: оно объясняет, почему что-то происходит в чате, и помогает выжать максимум из подключённых интеграций.

Двенадцать шагов. Полный путь запроса

Это самая важная диаграмма во всей книге. От «пользователь нажал Enter» до «модель ответила» проходит двенадцать шагов. Каждый имеет понятного владельца.

Простой пример: ты в Claude Cowork, подключён MCP-сервер от GitHub. Ты пишешь в чат: «Какие у меня сейчас открытые pull request'ы во всех репозиториях?» Жмёшь Enter. То, что происходит дальше — балет, в котором участвуют четыре стороны: ты, host (Cowork), MCP Client + MCP Server, и внешний сервис (GitHub). Балет занимает несколько секунд, но в нём двенадцать чётких шагов.

Шаги поштучно

Каждый шаг имеет одного владельца — кто-то конкретный за него отвечает:

  1. User query. Ты пишешь запрос в чате и нажимаешь Enter. Host получает текст.
  2. Tool discovery. Host понимает: чтобы ответить, нужна модель, а модели нужны инструменты. Сам он список инструментов не помнит — спрашивает у MCP Client.
  3. List tools exchange. Host вызывает функцию list_tools() у MCP Client. На самом деле это происходит обычно один раз при подключении сервера и кэшируется.
  4. MCP communication. Client отправляет на сервер JSON-RPC запрос tools/list. Сервер отвечает массивом доступных инструментов с их описаниями и схемами параметров.
  5. Claude request. Host берёт твой запрос и список инструментов, отправляет всё в API модели (Claude или другой).
  6. Tool use decision. Модель видит твой вопрос «какие у меня открытые PR». Видит список инструментов, в котором есть get_prs. Решает: нужен этот инструмент. Возвращает host'у не текстовый ответ, а структуру «вызови инструмент с такими параметрами».
  7. Tool execution request. Host просит MCP Client выполнить указанный инструмент.
  8. External API call. Client отправляет на MCP Server запрос tools/call. Сервер внутри вызывает GitHub API.
  9. Results flow back. GitHub возвращает JSON с pull request'ами. Сервер пересылает его в Client как результат инструмента.
  10. Tool result to Claude. Host получает результат и отправляет его в модель — теперь как контекст для следующего хода диалога.
  11. Final response. Модель видит данные и формулирует человеческий ответ: «У тебя сейчас три открытых PR: один в проекте X, два в проекте Y. Самый старый ждёт ревью с 5 мая».
  12. User gets answer. Host показывает ответ в чате. Ты видишь две строки, не подозревая, что под капотом было двенадцать шагов.

Зачем этим заморачиваться

Понимание двенадцати шагов помогает диагностировать проблемы:

  • Если ответ медленный — узкое место скорее всего в шагах 4 или 8 (сетевые вызовы).
  • Если ответ неточный — проблема в шаге 6 (модель неправильно выбрала инструмент или параметры).
  • Если ответ вообще не приходит — где-то отвалилась цепочка, и ты можешь понять где, не открывая код.

Выбор MCP-хоста и первое подключение

Спецификация MCP не привязана к конкретному приложению — любой host, реализующий клиента, может подключать любые MCP-серверы. Однако реальная зрелость, удобство и порог входа сильно отличаются.

Сравнение MCP-хостов

Топ-1: Claude Cowork

Десктопное приложение от Anthropic, вышедшее в GA в апреле 2026. Главная фишка — MCP-серверы поставляются как plugins: бандл из skill, MCP и subagent, упакованный в один установочный пакет. Каталог встроен в UI, установка в один клик, ключи запрашиваются через форму. Для не-программиста это самый прямой путь. Появилась новая версия плагина — Cowork сам предложит обновить.

  • Минусы: только desktop (mac + Win с фев 2026), требует подписку Pro ($20). В России проблема оплаты — нужны карты Казахстана, Армении, Грузии или Узбекистана.

Топ-2: Claude.ai web

Самый низкий порог входа для пробы. Открываешь claude.com → Settings → Connectors → Add custom connector → вставляешь URL вида https://server.example.com/mcp → OAuth → готово. Никакого терминала, никакого config-файла.

  • Free план позволяет подключить один connector — достаточно для понимания MCP.
  • Pro план снимает лимит.
  • Минус: Free даёт только один connector.

Топ-3: ChatGPT Apps

С декабря 2025 в ChatGPT появились Apps — под капотом это MCP. Если ты уже платишь Plus ($20+) за ChatGPT, переключаться на Anthropic ради MCP не обязательно. Никаких config-файлов, установка из встроенного маркетплейса. Custom MCP-серверы доступны через Developer Mode (нужно включать отдельно в настройках).

Другие хосты

  • Claude Desktop (ноябрь 2024) — для тех, кто любит редактировать config-файлы.
  • Cursor (март 2025, $20/мес Pro) — программист, MCP внутри IDE.
  • VS Code + Copilot (июль 2025 GA, $10/мес) — разработчик с VS Code.
  • Zapier MCP (2025, Free / от $20) — 8000+ интеграций без кода.

Самый бесплатный путь на май 2026

Claude.ai Free (1 connector) → подключить Zapier MCP endpoint (free tier) → получить готовую интеграцию с 8000+ приложениями без единой строки кода и без подписок.

Первое подключение за 30 минут: Cowork шаг за шагом

Что понадобится

  • 30 минут времени
  • $20 подписка Cowork Pro
  • macOS / Win (любая ОС с фев 2026)
  • 1 аккаунт Anthropic

Шаги

  1. 3 мин — Скачай Cowork на claude.com → раздел «Download». Если нет подписки Pro — пройди payment flow. В России — карта Казахстана, Армении, Грузии или Узбекистана.
  2. 2 мин — Установи и залогинься. Cowork покажет пустой чат. В правом верхнем углу — иконка plugins.
  3. 5 мин — Открой каталог plugins. Для первого знакомства выбери Filesystem (reference-сервер от Anthropic, даёт Claude доступ к локальным файлам).
  4. 3 мин — Установи Filesystem plugin. Cowork спросит, к каким папкам дать доступ. Важно: дай только тем папкам, которые реально нужны. Не давай доступ к домашней директории целиком.
  5. 2 мин — Проверь подключение. В нижней панели чата — индикатор «1 plugin active». Нажми — увидишь список tools: read_file, list_directory, search_files и другие.
  6. 5 мин — Сделай первый тестовый запрос: «Покажи список файлов в моей рабочей папке и кратко опиши, что там лежит».
  7. 5 мин — Попробуй второй сценарий: «Найди в этой папке все документы, где упоминается такой-то проект, и собери их ключевые тезисы в одну сводку».
  8. 5 мин — Добавь второй plugin (Google Drive, Notion или Linear). Каждый установит свой MCP-сервер и попросит авторизоваться через OAuth.

Что нельзя забывать

Доступ, который ты даёшь MCP-серверу, можно отозвать в любой момент: Settings → Plugins → отключи. Параллельно зайди в сам сервис и отзови OAuth-токен — простое отключение plugin'а не убирает данные у сервера.

Если что-то пошло не так

  • «Plugin не отвечает» — перезапусти Cowork. Если не помогло — удали и установи заново.
  • «Claude не видит мой файл» — проверь, что папка добавлена в roots Filesystem plugin'а.
  • «OAuth не проходит» — проверь, что в браузере по умолчанию ты залогинен в нужный аккаунт.
  • «Tool не работает» — посмотри логи: Help → View Logs.

MCP-сценарии и карта серверов

Сценарии использования MCP

Сценарий 1. Маркетолог

Подключаются: Notion, Google Analytics 4, Google Drive, Slack (или Telegram MCP). Возможность: «Возьми отчёт по последней кампании из Notion, дополни данными из GA за прошлую неделю, собери черновик письма команде и положи его в Drive». Claude сам читает Notion-страницу, обращается через GA4 MCP к данным, формирует выводы, сохраняет результат в Google Drive. Экономия: с 1-2 часов до 5-10 минут.

Сценарий 2. Продажник

Подключаются: HubSpot (или AmoCRM через community-сервер), Gmail/Outlook, Google Calendar, LinkedIn (через community). Возможность: «Перед встречей с такой-то компанией собери всю историю взаимодействий, последние письма, события в календаре, подскажи, на чём фокусироваться». Claude поднимает карточку из CRM, читает переписку, смотрит расписание, формирует пре-брифинг. Экономия: 20-30 минут подготовки на встречу.

Сценарий 3. Руководитель

Подключаются: Linear (или Jira/Asana), Slack/Teams, Google Drive, GitHub (для тех. руководителя). Возможность: «Дай еженедельный обзор: что закрыто, что застряло, где блокеры, кто отстаёт от плана». Claude читает Linear-проекты, статусы тикетов, активность в Slack, формирует executive summary. Экономия: актуальная картина команды без открытия шести дашбордов.

Сценарий 4. Создатель контента

Подключаются: Notion, Google Drive, Buffer (или PostFast), соцсети через Zapier MCP endpoint. Возможность: «Возьми черновик статьи из Notion, адаптируй под LinkedIn, Telegram, X, запланируй публикацию через Buffer». Экономия: с часа до 10 минут плюс ревью.

Сценарий 5. Аналитик

Подключаются: PostgreSQL (или MySQL/BigQuery), Snowflake, Google Sheets, Sequential Thinking MCP. Возможность: «Посмотри в базе тикетов саппорта тренд за последний квартал, выдели топ-5 категорий проблем, сгенерируй выводы, положи в Sheets». Claude составляет SQL-запросы, выполняет через MCP-сервер, анализирует, кладёт результат в Sheets. Экономия: с часа до 10 минут плюс ревью. Главное — модель видит контекст всех данных, а не нарезку.

Общий паттерн

Во всех сценариях один приём: подключи 3-5 MCP-серверов, покрывающих основной рабочий контекст. AI перестаёт быть «собеседником, которому всё надо объяснять» и становится «исполнителем в твоих системах».

Карта серверов (май 2026)

Общая статистика

В экосистеме MCP идентифицировано около 1 190 серверов в 23 доменах (кураторская карта, не все существующие — всего 24 тыс. в Glama).

Плотность по доменам

Лидируют три кластера:

  • Communication + Files/Storage: 120+
  • Web/Search (браузеры, скрапинг, исследования): 105
  • Data (БД, BI, хранилища): 93

Далее: E-com, Finance, HR/Legal (84), Gaming/Media (78), Productivity/PM/Notes/Tasks (70), Marketing/CRM/Sales (68), Design/AI generation (66), AI/ML infra/MLOps (58), Health (58), DevOps (52), Construction/AEC (40), Manufacturing/IIoT (32), Gov/Compliance (35), Travel/Home (37/36), RE/Logistics (30/25).

Пустые категории (окна возможностей)

Удивительно мало серверов там, где они нужны:

  • HR и payroll: ноль крупных vendor-MCP (Workday, BambooHR, Rippling, Gusto, Deel)
  • Tax compliance: ноль (TaxJar, Avalara, Vertex)
  • Reinsurance и actuarial: ноль (Swiss Re, Munich Re, RMS)
  • EV charging: ноль (ChargePoint, EVgo, Electrify America)
  • Mining: ноль (рынок $19.7B)

Это не баг, а окно возможностей — занять нишу первым реалистично уже в 2026 году.

Российский след

Production-уровень русские серверы:

  • Bitrix24 — официальный сервер от Bitrix
  • Yandex Cloud AI Studio MCP Hub — Yandex Tracker, Yandex Search, amoCRM, Контур.Фокус
  • Sber GigaChat + GigaCowork — бета в мае 2026, коннекторы к корпоративным системам
  • 1С — community-сервер mcp-1c и коммерческий ARQA
  • Yandex Maps — community-сервер с geocoding и PNG-рендером
  • СДЭК — community-сервер для расчёта стоимости и трекинга
  • AmoCRM, МойСклад, HH.ru, Т-Банк, Ozon Seller (с 466 API методов!), Telegram, VK — community
  • ЦБ РФ, ФНС due diligence (EFRSB, FSSP, КАД), ЕГРЮЛ/ЕГРИП — community от atomno-labs

Главные блокеры: оплата подписок Claude/ChatGPT (нужны карты СНГ-стран) и геоблокировка claude.ai.

Типы MCP-серверов

Три типа по уровню доверия

  1. Vendor — сделан производителем (Notion MCP от Notion, GitHub MCP от GitHub, Linear MCP от Linear, Atlassian от Atlassian, Stripe от Stripe). Самый надёжный, vendor-grade SLA, обновляется автоматически.
  2. Community — сделан энтузиастом. Качество от «лучше vendor'а» до «брошен месяц назад». Больший охват, риск abandonware. Читай SECURITY.md.
  3. Reference — сделан Anthropic (Filesystem, Memory, Fetch, Time, Sequential Thinking, Git, Everything). Не интеграции с сервисами, а примитивы.

Правило приоритета

Vendor > Reference > Community. Если нужна интеграция с Notion — ставь vendor-MCP. Если нет — смотри reference. Если и его нет — community, но проверь репозиторий.

Чёрные дыры экосистемы

Anthropic архивировал 13 из 20 своих первоначальных reference-серверов. Активных только 7: Filesystem, Memory, Fetch, Time, Sequential Thinking, Git, Everything. Остальные переехали к vendor'ам или в community — здоровый сигнал, экосистема растёт самостоятельно.

Как читать качество community-сервера

Перед установкой проверь:

  • Last commit: если больше шести месяцев назад — скорее всего заброшен
  • Stars и forks: помогают в сравнении с альтернативами
  • SECURITY.md: если нет — автор не подумал о безопасности
  • Issues с тегом security: если есть открытые — не ставь
  • Maintainer: один человек — выше риск abandonware
  • Каталог: серверы в Glama с пометкой «Verified» проходят базовый security-чек

Никогда не устанавливай community-сервер «потому что популярный в Smithery». OX Security доказали в апреле 2026: 9 из 11 публичных регистров прини...

MCP протокол: JSON-RPC, lifecycle, транспорты, OAuth

Проверка community-сервера перед установкой

Перед установкой community-сервера стоит потратить пять минут на проверку по следующим критериям:

  • Last commit — если последний commit был больше шести месяцев назад, серверу не доверять (скорее всего заброшен или схема устарела).
  • Stars и forks — сами по себе не значимы, но в сравнении с альтернативами помогают.
  • SECURITY.md — если файла нет, автор не подумал про безопасность. Не критично, но настораживает.
  • Issues с тегом security — если есть открытые баги по безопасности, не ставить.
  • Maintainer — один человек или организация? Один человек — выше риск abandonware.
  • Каталог — серверы в Glama с пометкой «Verified» проходят базовый security-чек. Это не гарантия, но фильтр.

Никогда не устанавливать community-сервер «потому что популярный в Smithery». OX Security доказали в апреле 2026: 9 из 11 публичных регистров принимают malicious payload без проверки. Популярность не равна безопасности.

JSON-RPC 2.0 — фундамент протокола MCP

MCP — это не самостоятельный протокол с нуля, а удобный набор соглашений поверх JSON-RPC 2.0. Зная JSON-RPC, можно знать 70% синтаксиса MCP.

JSON-RPC 2.0 описывает три типа сообщений: request, response и notification. Все они — обычные JSON-объекты, передаваемые по любому транспорту, который умеет передавать текст.

Три типа сообщений

Request — запрос, ожидающий ответа. Главное — наличие id. По нему сторона, получившая response, поймёт, какому именно request он соответствует. Если параллельно идут несколько запросов, id помогает разрулить, кто кому отвечает.

Пример (клиент → сервер, спрашивает «какие есть инструменты?»):

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

Response — ответ на конкретный request. Если что-то пошло не так — вместо result приходит error.

Пример (сервер → клиент, тот же id):

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "search_files",
        "description": "Search files by query",
        "inputSchema": { ... }
      }
    ]
  }
}

Пример с ошибкой:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32601,
    "message": "Method not found"
  }
}

Notification — асинхронное уведомление без ожидания ответа. Нет id, потому что ответа не ждут.

Пример:

{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}

Стандартные коды ошибок

Код Имя Когда возникает
-32700 Parse error JSON невалидный, не распарсился
-32600 Invalid Request Структура запроса не соответствует спеке
-32601 Method not found Такого метода у сервера нет
-32602 Invalid params Параметры не прошли валидацию по schema
-32603 Internal error Сервер упал при обработке
-32000 ... -32099 Server-defined MCP-специфичные ошибки (в т.ч. -32042 URL elicitation)

Почему JSON-RPC, а не GraphQL или gRPC

JSON-RPC — самый простой выбор из возможных: текстовый, читается глазами, не требует кодогенерации, работает поверх любого транспорта, отлично подходит для агентского паттерна «вопрос-ответ». Сложные протоколы (gRPC, GraphQL) дали бы больше возможностей, но повысили бы порог входа и количество багов реализации.

Жизненный цикл. Initialize и capabilities

Перед обменом запросами клиент и сервер должны договориться: какая у них версия протокола, что каждая сторона умеет, какие фичи опциональны. Эта церемония называется handshake.

Initialize handshake

  1. Клиент → сервер: «здравствуй, я такой-то»
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "roots": { "listChanged": true },
      "sampling": {},
      "elicitation": {}
    },
    "clientInfo": {
      "name": "claude-cowork",
      "version": "1.2.0"
    }
  }
}
  1. Сервер → клиент: «здравствуй, я такой-то, умею это»
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "tools": { "listChanged": true },
      "resources": { "subscribe": true },
      "prompts": { "listChanged": true }
    },
    "serverInfo": {
      "name": "github-mcp",
      "version": "2.0.0"
    }
  }
}

Capabilities negotiation

В handshake обе стороны декларируют, что они умеют:

  • Сервер объявляет наличие: tools, resources, prompts, logging, completions, experimental.
  • Клиент объявляет: roots, sampling, elicitation, experimental.

Если сервер хочет использовать sampling, но клиент его не объявил — сервер не должен слать sampling/createMessage. Это безопасное вырождение: вместо ошибки сервер либо обходится без фичи, либо отказывается работать с явным сообщением.

Нормальная работа

После notifications/initialized начинается обычный режим: запросы, ответы, нотификации в обе стороны. Ход разговора зависит от того, что нужно host'у — он может вообще не звать tools/list, если уже знает каталог из кэша.

Shutdown

  • Для stdio транспорта shutdown — это просто закрытие потока (EOF на stdin). Сервер видит, что клиент отвалился, и завершает процесс.
  • Для Streamable HTTP — закрытие SSE-стрима плюс явный DELETE /mcp с session ID для очистки состояния.

Транспорты: stdio и Streamable HTTP

В официальной спецификации MCP только два транспорта:

  • stdio — для локальных процессов
  • Streamable HTTP — для всего остального

Старый HTTP+SSE объявлен deprecated в марте 2025. WebSocket в спеке нет — Streamable HTTP закрывает все use cases.

stdio — для локальных серверов

Самый простой транспорт. Host запускает MCP-сервер как отдельный процесс. Они общаются через stdin/stdout: каждое JSON-сообщение — одна строка, заканчивающаяся \n. Логи сервер пишет в stderr, чтобы не мешать протоколу.

Плюсы: простая отладка, видно весь поток; полный доступ к локальным ресурсам.
Минусы: только локально, нельзя дистанционно; нужно запускать процесс на каждом устройстве.

Streamable HTTP — для удалённых

Введён в марте 2025 на смену HTTP+SSE. Один endpoint POST /mcp, на котором сервер может отвечать либо обычным JSON (для коротких операций), либо text/event-stream (для долгих, со streaming-обновлениями).

Ключевые особенности:

  • Single endpoint — не нужно два отдельных URL для запросов и стрима.
  • MCP-Session-Id header — с 2025-11-25 в camelCase. Используется для stateful серверов, которые хранят сессионное состояние.
  • Last-Event-ID — для resumability: если соединение оборвалось, клиент может попросить сервер «продолжи с того места, где был».
  • 403 на bad Origin — защита от незарешённых browser-based клиентов.

Что отличает remote MCP от локального

Локальный MCP-сервер живёт на твоей машине, в твоём процессе, с правами твоего пользователя. Удалённый — на чужом сервере, с своими правами, с обязательной авторизацией через OAuth. Эти два режима — два разных мира с точки зрения безопасности.

OAuth 2.1 — авторизация удалённых серверов

Для удалённых MCP-серверов спецификация требует OAuth 2.1 с PKCE. Это не просто «логин-пароль», а сложная цепочка из пяти RFC, которая защищает от целого класса атак и при правильной реализации делает remote MCP таким же безопасным, как локальный.

Стек обязательного (к маю 2026)

Спецификация требует от удалённых серверов:

  1. OAuth 2.1 + PKCE с S256 (MUST с 2025-03-26) — защита от code interception
  2. Resource Indicators RFC 8707 (MUST с 2025-06-18) — токены bound к конкретному серверу, защита от token passthrough
  3. Protected Resource Metadata RFC 9728 — discovery AS через /.well-known/oauth-protected-resource
  4. Authorization Server Metadata RFC 8414 — discovery endpoints
  5. DCR (RFC 7591) или CIMD (с 2025-11-25) — регистрация клиентов

Зачем такая сложность

Каждый элемент закрывает реальную атаку:

  • PKCE закрывает атаку на code interception (когда вредонос перехватывает auth code между browser и client).
  • Resource Indicators закрывают token passthrough (когда токен, выпущенный для одного сервера, кто-то использует для доступа к другому).
  • PRM и AS Metadata закрывают подмену authorization server.

OAuth 2.1 handshake и MCP протокол

OAuth 2.1 Handshake для remote MCP

Компоненты и требования

  • OAuth 2.1 + PKCE с S256 (MUST с 2025-03-26) — защита от code interception
  • Resource Indicators RFC 8707 (MUST с 2025-06-18) — токены bound к конкретному серверу, защита от token passthrough
  • Protected Resource Metadata RFC 9728 — discovery AS через /.well-known/oauth-protected-resource
  • Authorization Server Metadata RFC 8414 — discovery endpoints
  • DCR (RFC 7591) или CIMD (с 2025-11-25) — регистрация клиентов

Семь шагов handshake

Зелёные стрелки — успех, красная — отказ доступа на старте.

Каждый элемент закрывает реальную атаку:

  • PKCE закрывает атаку на code interception (когда вредонос перехватывает auth code между browser и client)
  • Resource Indicators закрывают token passthrough (когда токен, выпущенный для одного сервера, кто-то использует для доступа к другому)
  • PRM и AS Metadata закрывают подмену authorization server (клиент знает заранее, кто легитимный AS)
  • DCR/CIMD закрывают необходимость предварительной регистрации каждого клиента вручную — это критично для масштаба экосистемы

Конечный пользователь всего этого не видит. Он видит: «open this link in browser to authorize Notion access» → проходит → возвращается → готово. Под капотом — семь HTTP-запросов и пять разных RFC.

Последовательность handshake

  1. Запрос без токена → 401 + WWW-Authenticate (PRM URL)
  2. GET /.well-known/oauth-protected-resource → PRM с auth_servers[]
  3. GET /.well-known/oauth-authorization-server → endpoints + scopes
  4. POST /register (DCR) ИЛИ передача CIMD URL → client_id
  5. /authorize?code_challenge=S256(verifier)&resource=MCP_URL → браузер открывается, пользователь одобряет → auth code → redirect_uri
  6. POST /token + code + code_verifier + resource → access_token + refresh_token
  7. Authorization: Bearer access_token

Tools. Глубокий разбор

Tools — самая используемая часть протокола. Полная схема параметров, аннотации, типы возвращаемого контента, два уровня обработки ошибок. Полный референс на актуальной спеке 2025-11-25.

Полная схема Tool

{
  "name": "search_repository",
  "title": "Repository Search",
  "description": "Full-text search...",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string" },
      "max_results": { "type": "integer", "default": 20 }
    },
    "required": ["query"]
  },
  "outputSchema": { ... },
  "annotations": {
    "title": "Search Repository",
    "readOnlyHint": true,
    "destructiveHint": false,
    "idempotentHint": true,
    "openWorldHint": false
  }
}
🔒

Продолжение скрыто

Для чтения полного конспекта необходима авторизация и подписка Konspekt PRO

ВойтиПолучить PRO →