Аналитический доклад: Model Context Protocol (MCP) – архитектура, техническая реализация и вектор развития

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

Для ИИ-приложений MCP играет примерно ту же роль, что USB-C для техники: это универсальный интерфейс, не привязанный к конкретной языковой модели, через который можно подключаться к базам данных, системам контроля версий, API и локальным файлам. Протокол впервые представила Anthropic в конце 2024 года, а затем передала его под управление Agentic AI Foundation – проекта The Linux Foundation. Это дало протоколу независимое управление и помогло ему быстрее закрепиться в индустрии.

К 2026 году протокол перестал быть экспериментом и превратился в фактический стандарт для инфраструктуры автономных агентов. Цифры из аналитических отчетов говорят о массовом внедрении: MCP-серверы используют в продакшене или ограниченном продакшене более 41% опрошенных компаний-разработчиков. В официальном реестре числится около 10 000 активных публичных серверов, а SDK скачивают более 97 миллионов раз в месяц. Такой охват объясняется продуманной архитектурой: она позволяет ИИ-системам безопасно находить и подключать инструменты на лету.

Архитектура и структурные компоненты протокола

В основе MCP лежит двухуровневая клиент-серверная архитектура: она разделяет уровень данных (Data Layer) и транспортный уровень (Transport Layer). Компоненты общаются по стандарту удаленного вызова процедур JSON-RPC 2.0 – отсюда независимость от языка программирования и простота интеграции.

В этой топологии три ключевых элемента, и работают они в рамках общего жизненного цикла. Первый – хост (MCP Host), то есть само ИИ-приложение: среда разработки вроде Cursor или Visual Studio Code, десктопный клиент Claude Desktop или консольная утилита Claude Code. Хост хранит контекст пользователя, направляет вызовы к языковой модели и спрашивает у пользователя явное разрешение, прежде чем выполнить потенциально опасное действие.

Под каждый подключаемый источник данных хост создает второго участника – MCP-клиента (MCP Client). Клиент держит соединение, маршрутизирует запросы и ведет жизненный цикл протокола, пряча сетевую кухню от логики хоста^. Третий элемент – MCP-сервер (MCP Server): изолированный процесс или удаленный веб-сервис, который отдает контекст, инструменты и промпты. Серверы делают модульными и не привязывают к конкретной языковой модели.

Примитивы взаимодействия

Обмен данными идет через строго типизированные примитивы – именно они задают, что умеют серверы и клиенты. На стороне сервера таких примитивов три. Ресурсы (Resources) – это контекст для чтения, аналог GET-запросов в REST API: модель может получить содержимое файлов, ответы из базы данных или документацию. Инструменты (Tools) – исполняемые функции, через которые модель меняет состояние внешних систем: например, выполняет SQL-запрос или делает коммит в репозиторий. Промпты (Prompts) – серверные шаблоны инструкций, которые забирают сложный промпт-инжиниринг со стороны клиента.

Со спецификации 2026-07-28 схемы ввода и вывода инструментов перешли на полную поддержку стандарта JSON Schema 2020-12 (предложение SEP-2106). Теперь можно описывать сложную композицию схем (oneOf, anyOf, allOf), условные операторы и ссылки ($ref, $defs) – а значит, надежнее проверять передаваемые аргументы.

На стороне клиента тоже есть свои примитивы – через них сервер может попросить хост что-то сделать. Извлечение (Elicitation) дает серверу право приостановить инструмент и обратиться к пользователю за дополнительными параметрами или подтверждением. Сэмплирование (Sampling) раньше позволяло серверу напрямую просить хост сгенерировать текст средствами его LLM, но в свежих ревизиях протокола (SEP-2577) его признали устаревшим – вместо него предлагают напрямую работать с провайдерами LLM.

Транспортный уровень и модели развертывания

Поскольку уровень данных не зависит от транспорта, MCP одинаково работает и на локальной машине разработчика, и в распределенном облачном кластере. Спецификация описывает два официальных транспорта, у каждого свои рабочие свойства и свои сценарии развертывания. Старый транспорт на базе HTTP и Server-Sent Events (SSE) в 2026 году официально объявили устаревшим.

Транспорт stdio хорошо ложится на инструменты разработчика: запускается просто, сетевой задержки почти нет. Клиент (например, VS Code) порождает дочерний процесс сервера и передает ему переменные окружения напрямую. Но при корпоративном масштабировании у этой схемы появляются проблемы. Отдельный процесс на каждого пользователя (фан-аут) съедает лишние ресурсы, а на каждом новом соединении приходится платить за «холодный старт» – порядка 200–400 мс для Python и Node.js.

Корпоративный сектор переходит на Streamable HTTP ради централизованного управления. Этот транспорт позволяет поставить общий пул MCP-серверов за балансировщик нагрузки или корпоративный шлюз (Gateway). Тогда можно применять ролевую модель доступа (RBAC), ограничивать частоту запросов (rate limiting) и собирать сквозной аудит – всего этого децентрализованный stdio не дает.

Стандартизация конфигурации и экосистема SDK

Чтобы код работал на разных платформах, индустрия договорилась об общих стандартах для SDK и конфигурационных файлов. Разработка держится в основном на двух языках – TypeScript и Python, и у каждого своя ниша в зависимости от того, кто в команде.

Официальный TypeScript SDK (@modelcontextprotocol/sdk) – стандарт для высоконагруженных серверов и клиентских интеграций. Он работает на Node.js, Bun и Deno и дает строгую типизацию через связку с Zod, Valibot или ArkType²⁰. Дата-сайентисты и инженеры ИИ чаще берут Python SDK. В Python-экосистеме популярен фреймворк FastMCP: он построен на декораторах в духе FastAPI и сам выводит JSON-схемы из аннотаций типов Python (Pydantic). Прототип на нем собрать заметно проще³.

Чем больше становилось MCP-клиентов, тем острее вставала проблема разнобоя в конфигурациях: разные среды разработки использовали разные форматы (JSON, TOML), разные корневые ключи и разные пути к файлам²³. В итоге сообщество сошлось на едином стандарте – файле mcp.json. Он описывает запуск серверов, передачу аргументов и подстановку переменных окружения, причем политики можно переопределять по иерархии: глобально, на уровне проекта и на уровне пользователя.

Иерархия удобна на практике. Enterprise-команда может зафиксировать стандартный набор MCP-инструментов (скажем, корпоративный сервер JIRA или анализатор кода Sentry) в файле .mcp.json в корне репозитория. Отдельный разработчик переопределяет в своей глобальной конфигурации токены аутентификации и держит секреты вне системы контроля версий. А администраторы раскатывают системный managed-mcp.json, чтобы применять списки блокировки («denylist»).

MCP, Function Calling или LangChain

При проектировании агентов один из главных вопросов – что брать: MCP, встроенный Function Calling или высокоуровневые фреймворки оркестрации вроде LangChain и LangGraph. Задачи у них пересекаются, но уровни абстракции совершенно разные.

Function Calling встроен в сами языковые модели: модель запрашивает конкретный инструмент и получает структурированный JSON¹⁶. LangChain – это фреймворк, который управляет логикой: оборачивает инструменты в классы, ведет память, гоняет циклы рассуждений (ReAct) и обрабатывает ошибки¹⁶. MCP же не занимается ни оркестрацией логики, ни графами состояний – это чисто инфраструктурный слой, который стандартизирует доступ к внешним сервисам¹⁷.

MCP оправдан там, где нужны переносимость, безопасность на стороне сервера и динамическое обнаружение инструментов. Если же архитектуре нужны сложные многоэтапные рассуждения, MCP не вытесняет LangChain, а работает вместе с ним. Адаптеры langchain-mcp-adapters подтягивают удаленные MCP-инструменты в агенты LangChain – так стандартизированный доступ к данным сочетается с мощной оркестрацией. У такой связки есть и цена: MCP генерирует полные JSON-схемы, и это расходует больше токенов LLM, чем компактные схемы, написанные вручную под Function Calling.

Информационная безопасность и управление уязвимостями

Главный побочный эффект MCP – перевернутая модель доверия. В обычных системах данные запрашивает клиент. В агентных системах на базе MCP решения нередко принимает сервер: он отдает ИИ-клиенту контекст, который прямо влияет на следующие действия модели – в том числе через Prompt Injection. Чем прочнее MCP закреплялся как стандарт корпоративной интеграции, тем пристальнее исследовательские лаборатории смотрели на безопасность его реализаций.

Крупные аудиты 2025–2026 годов показали, что с инфраструктурой дела плохи. По данным BlueRock Security, из 7000 проверенных MCP-серверов более 36,7% оказались уязвимы к подделке серверных запросов (SSRF), а до 41% внедрений вообще не имели базовой аутентификации на уровне протокола. Эти дыры активно эксплуатировали – отсюда десятки опубликованных CVE (Common Vulnerabilities and Exposures), включая критическое удаленное выполнение кода (RCE) в популярных пакетах.

Ключевые векторы атак и механизмы эксплуатации

Одна из самых опасных уязвимостей в экосистеме – Server-Side Request Forgery (SSRF): через нее злоумышленник превращает MCP-сервер в прокси для атаки на внутреннюю сеть. Показательный случай – CVE-2026-45609 в модуле springaicommunity:mcp_security (до исправления в версии 0.1.9 уязвимость имела высокую оценку критичности). Фреймворк во время обнаружения OAuth-метаданных обрабатывал произвольные URL и не проверял, не ведут ли они во внутренние подсети. В реальной атаке на платформу телефонии злоумышленник через неаутентифицированный конечный автомат MCP вызвал инструмент проксирования аудио и подсунул ему URL метаданных AWS (http://169.254.169.254/). Сервер сходил по этому внутреннему адресу и вернул атакующему рабочие ключи IAM. Дальше через Local File Inclusion (LFI) он получил доступ к базе данных и полностью захватил облачную инфраструктуру.

Еще одна системная проблема – анти-паттерн Token Passthrough (сквозная передача токена). Он возникает, когда MCP-сервер берет токен доступа от клиента и без проверки шлет его дальше, в нижестоящие API. Так рушатся границы доверия и контроль доступа: нижестоящий API видит запрос от сервера, но не понимает, кто реальный пользователь. Аудит становится невозможным, а сервер превращается в прокси для кражи данных.

Раздувание области действия (Scope Inflation) делает последствия взлома еще тяжелее. Серверы часто публикуют сразу все возможные разрешения (например, files:* или admin:*), а клиенты запрашивают их одним блоком. Если такой токен перехватят, радиус поражения (Blast Radius) выходит фатальным: скомпрометированный агент или угнанная сессия получают неограниченный доступ ко всем системам. Отдельная история – локальные серверы на транспорте stdio: они работают с правами пользователя операционной системы. Если клиент не запускает их в песочнице (sandbox) и не спрашивает явного согласия на исполнение потенциально опасного бинарника, злоумышленник может прописать вредоносные команды прямо в файл .mcp.json.

Архитектурные политики смягчения рисков

Спецификация и отраслевые стандарты задают довольно жесткий набор правил для защиты MCP-инфраструктуры.

1.     Отказ от сессионной аутентификации

Протокол запрещает аутентификацию по предсказуемым сессиям. Каждый входящий запрос проверяется криптографически стойким токеном (например, OAuth 2.1 с PKCE), а идентификатор сессии привязывается к уникальному идентификатору пользователя (<user_id>:<session_id>) – иначе сеанс можно угнать.

2.     Защита от SSRF и принудительное применение IMDSv2

Любой инструмент, который принимает URL, обязан проверять его по строгому «белому списку» доменов и отклонять протоколы вроде file:// или gopher://. В AWS дополнительно требуют включать IMDSv2: эта конфигурация запрашивает PUT-запрос с токеном, прежде чем отдать метаданные, и тем самым гасит базовые SSRF-атаки.

3.     Изоляция локального окружения (Sandboxing)

IDE-клиенты вроде VS Code включают изоляцию через настройку sandboxEnabled в mcp.json. Она ограничивает серверу доступ к файловой системе – писать разрешено только в каталог проекта – и к сетевым доменам, а к чувствительным каталогам вроде ~/.ssh доступ закрыт.

4.     Централизация через MCP Gateway

Единая точка входа (API Gateway) для всех Streamable HTTP-соединений позволяет централизованно управлять идентичностью агентов и не давать им бесконтрольно плодиться (Agent Sprawl). Заодно она ведет сквозной журнал действий агентов, который можно отдавать в SIEM-системы.

Наблюдаемость и телеметрия (Observability)

Чтобы понимать, какие решения принимает автономный агент, нужна глубокая наблюдаемость. MCP интегрирован с OpenTelemetry для распределенной трассировки. Спецификация фиксирует строгие семантические соглашения: например, метрика mcp.client.operation.duration измеряет время вызова на стороне клиента, а mcp.server.operation.duration – на стороне сервера.

MCP не зависит от транспорта, поэтому обычного проброса HTTP-контекста не хватает: в одном потоке мультиплексируется много отдельных JSON-RPC сообщений. Чтобы их различать, контекст трассировки – идентификаторы traceparent и tracestate по стандарту W3C – кладут прямо в объект _meta внутри параметров MCP-запроса. Когда используются LLM-промпты, в имена спанов (Span names) добавляют конкретные цели, например {gen_ai.tool.name}. Так инженеры по надежности (SRE) точно видят, на каком шаге агентной цепочки произошел сбой.

Дорожная карта на 2026–2027 годы

Релиз-кандидат спецификации 2026-07-28 завершил превращение протокола из инструмента для локальных прототипов в распределенную инфраструктуру корпоративного класса. Эта ревизия формализовала новые механизмы и вдобавок запустила независимый цикл версионирования через систему предложений по расширению (SEP).

Одно из ключевых изменений архитектуры – полный отказ от состояния (Stateless Protocol Core). По SEP-2575 и SEP-2567 протокол избавился от рукопожатия (initialize) и от управления протокольными сессиями (Mcp-Session-Id). Теперь любой запрос несет метаданные клиента в объекте _meta, и обработать его может любой сервер за балансировщиком нагрузки. Запросы от сервера к клиенту тоже переделали (SEP-2322): вместо того чтобы держать открытыми SSE-потоки, сервер возвращает состояние InputRequiredResult. Пока ждут реакции пользователя, транспорт нагружается меньше.

Дорожная карта на ближайшие годы делает упор на двух вещах: больше автономности у ИИ и удобнее работа с интерфейсами.

1.     Асинхронные задачи (Tasks Extension)

Задачи прошли путь от экспериментальной функции до официального расширения. Теперь агент может запустить длительную операцию (например, анализ больших массивов данных) одним запросом, отключиться и позже вернуться за результатом через операции tasks/get и tasks/update. Для неблокирующих рабочих процессов это принципиально.

2.     Интерактивные интерфейсы (MCP Apps)

Расширение SEP-1865 разрешает серверам возвращать шаблоны HTML-интерфейсов. Хост рендерит их в защищенном iframe. Действия пользователя в таком интерфейсе уходят обратно в хост по обычному JSON-RPC, так что все механизмы аудита и безопасности остаются в силе.

3.     Событийно-ориентированная модель (Triggers and Events)

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

4.     Композитные навыки (Skills)

Серверы перестанут отдавать только атомарные инструменты и начнут предлагать высокоуровневые «навыки». Вместе с инструментом сервер сможет передать агенту собственные инструкции и подсказки по его применению – и многоэтапные рассуждения станут предсказуемее.

Заключение

MCP изменил то, как языковые модели общаются с внешним миром. Он дал открытый стандартный слой поверх JSON-RPC, и кастомные интеграции стали не нужны: ИИ-системы научились сами находить и использовать корпоративные базы данных, API и инструменты разработчика.

Путь MCP от транспорта stdio для локальных IDE к распределенному Streamable HTTP открыл ему дорогу в крупные корпоративные инфраструктуры. Но вместе с масштабом пришли и серьезные риски безопасности. Когда внешние серверы дают ИИ не только данные, но и инструкции, модель контроля доступа переворачивается, и защитную архитектуру приходится продумывать заново. Без строгой аутентификации, защиты от SSRF и связки с системами IAM через выделенные шлюзы (Gateway) протокол открывает путь к масштабным утечкам данных. И чем ближе MCP к полной асинхронности и событийной модели (Triggers/Tasks), тем меньше он похож на простой интерфейс обмена данными – он становится базовой операционной средой для будущих автономных агентов.

Источники

1.     What is Model Context Protocol (MCP)? - GitHub, https://github.com/resources/articles/what-is-mcp-model-context-protocol

2.     Basics of MCP - Anyscale Docs, https://docs.anyscale.com/mcp

3.     Model Context Protocol - GitHub, https://github.com/modelcontextprotocol

4.     Specification - Model Context Protocol, https://modelcontextprotocol.io/specification/2025-11-25

5.     Model Context Protocol, https://modelcontextprotocol.io/docs/getting-started/intro

6.     Model context protocol (MCP) - OpenAI Agents SDK, https://openai.github.io/openai-agents-python/mcp/

7.     MCP Is Just Getting Started: Unpacking MCP Founder's Vision for 2026, https://obot.ai/blog/mcp-is-just-getting-started-founders-vision-2026/

8.     MCP Adoption Statistics 2026: Model Context Protocol - Digital Applied, https://www.digitalapplied.com/blog/mcp-adoption-statistics-2026-model-context-protocol

9.     Architecture overview - Model Context Protocol, https://modelcontextprotocol.io/docs/learn/architecture

10. Claude Code MCP Servers: How to Connect, Configure, and Use Them - Builder.io, https://www.builder.io/blog/claude-code-mcp-servers

11. Security Best Practices - Model Context Protocol, https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices

12. The 2026-07-28 MCP Specification Release Candidate | Model Context Protocol Blog, https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/

13. Stdio vs Streamable HTTP for MCP: What changes when you move from local development to enterprise deployment - Truefoundry, https://www.truefoundry.com/blog/mcp-stdio-vs-streamable-http-enterprise

14. Transport · Cloudflare Agents docs, https://developers.cloudflare.com/agents/model-context-protocol/protocol/transport/

15. The future of MCP: 2026 roadmap, enterprise adoption, and what comes next - Toloka AI, https://toloka.ai/blog/the-future-of-mcp-enterprise-adoption/

16. MCP vs Function Calling vs LangChain: AI Agent Guide - RoxyAPI, https://roxyapi.com/blogs/mcp-vs-function-calling-vs-langchain-tools-ai-agents

17. MCP vs. Function Calling: Choosing the Right Framework for AI Phone Agents - Goodcall, https://www.goodcall.com/voice-ai/mcp-vs-function-calling

18. MCP vs LangChain Tools: When to Use Each and How They Work Together (2026), https://www.getknit.dev/blog/integrating-mcp-with-popular-frameworks-langchain-openagents

19. Enterprise MCP Use Cases: 2026 Roadmap and Trends - CData Software, https://www.cdata.com/blog/enterprise-mcp-use-cases-roadmap-2026

20. The official TypeScript SDK for Model Context Protocol servers and clients - GitHub, https://github.com/modelcontextprotocol/typescript-sdk

21. Building Your First MCP Server: TypeScript vs. Python - DEV Community, https://dev.to/kenwalger/building-your-first-mcp-server-typescript-vs-python-31ch

22. MCP JSON Configuration FastMCP, https://gofastmcp.com/integrations/mcp-json-configuration

23. Proposal: Universal MCP Configuration File Standard #2218 - GitHub, https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/2218

24. MCP Configuration Across AI Agents - Uno Platform, https://platform.uno/blog/mcp-configuration-across-ai-agents/

25. MCP Server - Shortcut Help Center, https://help.shortcut.com/hc/en-us/articles/36443434285844-MCP-Server

26. MCP Setup | Schema App Support, https://support.schemaapp.com/support/solutions/articles/33000295442-mcp-setup

27. Use MCP Servers - Visual Studio (Windows) | Microsoft Learn, https://learn.microsoft.com/en-us/visualstudio/ide/mcp-servers?view=visualstudio

28. MCP configuration reference - Visual Studio Code, https://code.visualstudio.com/docs/copilot/reference/mcp-configuration

29. Add and manage MCP servers in VS Code, https://code.visualstudio.com/docs/agent-customization/mcp-servers

30. LangChain vs MCP: When to Use Each (2026 Guide) | Apigene Blog, https://apigene.ai/blog/langchain-vs-mcp

31. Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation, https://www.nsa.gov/Portals/75/documents/Cybersecurity/CSI_MCP_SECURITY.pdf?ver=bmgiSbNQLP6Z_GiWtRt6bg%3D%3D

32. MCP Security Issues: Enterprise Risks & Proven Solutions - Truefoundry, https://www.truefoundry.com/blog/mcp-security-issues

33. How an Unauthenticated MCP Server Led to SSRF, LFI, and AWS Credential Theft, https://www.cloudsek.com/blog/aivigil-mcp-security-case-study

34. CVE-2026-45609: Spring AI MCP Security SSRF Vulnerability - SentinelOne, https://www.sentinelone.com/vulnerability-database/cve-2026-45609/

35. Semantic conventions for Model Context Protocol (MCP) - OpenTelemetry, https://opentelemetry.io/docs/specs/semconv/gen-ai/mcp/