MCP (Model Context Protocol)

Короткая версия

MCP решает interop-проблему в agent stack:

• AI app хочет работать с внешним миром;
• tools и data sources живут в разных системах;
• писать уникальную интеграцию под каждую пару "app x service" дорого и хрупко.

MCP даёт общий протокол для:

• подключения серверов;
• объявления capabilities;
• чтения context;
• вызова tools;
• обмена дополнительными signals между client и server.

В current framing важно помнить:

• architecture = host -> client -> server;
• основные transports = stdio и Streamable HTTP;
• protocol stateful и работает через lifecycle negotiation;
• кроме tools/resources/prompts есть ещё client/server capabilities;
• MCP особенно полезен в agents, coding, enterprise integrations и internal tooling.

Зачем MCP, если у меня уже есть function calling?

1. Какую проблему решает MCP

До MCP agent ecosystem упиралась в одно и то же:

• у каждого приложения свои plugin interfaces;
• у каждого tool vendor свой format;
• каждая интеграция ломается отдельно;
• перенос tools между clients дорогой;
• security model размазана по самодельным adapters.

MCP снижает эту интеграционную энтропию.

Его practical value:

• один protocol surface для разных hosts;
• переиспользуемые servers;
• единая mental model для tools и context;
• более чистая дорога к remote agent infrastructure.

2. Архитектура host-client-server

Current MCP architecture строится вокруг трёх ролей.

Host

Host — это приложение, в котором работает пользователь или agent runtime:

• Claude Desktop;
• coding IDE;
• agent framework;
• internal enterprise app;
• other AI-enabled host.

Host управляет сессией и trust boundary.

Client

Client живёт внутри host и говорит с MCP server по протоколу:

• инициализирует соединение;
• согласует capabilities;
• получает tools/resources/prompts;
• вызывает server methods;
• проксирует результаты в host/runtime.

Server

Server предоставляет capabilities:

• tools;
• resources;
• prompts;
• иногда дополнительные features вроде logging/completions/tasks/experimental extensions.

Сервер можно понимать как стандартизированный adapter к внешней системе.

3. MCP уже не сводится к трём сущностям

Старые intro-статьи часто останавливаются на resources + tools + prompts. Это всё ещё core layer, но current protocol уже шире.

Server-side capabilities

Lifecycle docs отдельно выделяют capability negotiation для:

• prompts;
• resources;
• tools;
• logging;
• completions;
• tasks;
• extensions;
• experimental.

Client-side capabilities

На client side current MCP также знает про:

• roots;
• sampling;
• elicitation;
• tasks;
• extensions;
• experimental.

Это важно, потому что current MCP больше похож на настоящий protocol stack, чем на каталог удалённых функций.

4. Что такое roots, sampling и elicitation

Эти capability layers и отличают modern MCP framing от старых базовых explainers.

Roots

roots задают доступные filesystem or workspace boundaries, которые client показывает server.

Практический смысл:

• ограничить сервер не всем диском, а нужной областью;
• явно задавать рабочий контекст;
• уменьшать accidental overreach.

Sampling

sampling позволяет server просить client выполнить LLM generation.

Это важная idea:

• server не обязательно сам содержит модель;
• он может просить client/host сделать model-backed step;
• protocol thus coordinates context and generation together.

Elicitation

elicitation позволяет server запросить у client дополнительные данные или подтверждение.

Это особенно полезно там, где нужно:

• уточнение параметров;
• extra user input;
• approval-like interaction.

5. Lifecycle и capability negotiation

Current MCP lifecycle уже нельзя сводить к фразе "клиент подключился и получил список tools".

Нормальный поток выглядит так:

1. client открывает transport;
2. шлёт initialize;
3. server возвращает protocol version и capabilities;
4. client шлёт initialized;
5. стороны переходят к normal operation.

В lifecycle docs отдельно прописаны:

• version negotiation;
• capability negotiation;
• требования к последовательности сообщений.

Это и делает протокол пригодным для cross-vendor interoperability, а не просто для "пакета helper scripts".

6. Transport layer: что устарело

Старые статьи про MCP часто фиксируют transport layer как stdio + SSE. В 2026 это уже неточная рамка.

Current practical picture:

• stdio остаётся важным для local servers;
• Streamable HTTP стал ключевым transport для remote scenarios;
• старые SSE-oriented mental models больше не покрывают весь current protocol surface.

Если статья оставляет у читателя ощущение, что MCP почти целиком про локальные процессы, она уже устарела.

7. Где MCP особенно полезен

MCP оправдан сильнее всего там, где tools and context need to travel across applications.

Типовые сценарии:

• coding agents;
• repo and issue management;
• enterprise assistants;
• internal docs/data access;
• observability/admin tooling;
• browser/computer-use adjacent environments.

Особенно полезен MCP там, где есть:

• несколько clients;
• повторно используемые server capabilities;
• mix of local and remote tool environments.

8. Где MCP не нужен

MCP не обязателен всегда.

Он может быть избыточен, если:

• у вас один простой internal tool;
• только один host и одна интеграция;
• portability не нужна;
• проще написать небольшой custom adapter;
• tool surface очень узкий.

То есть MCP полезен не потому, что он модный, а потому что он снимает повторяющуюся interop-боль.

9. Security boundary

MCP сам по себе не гарантирует безопасность.

Реальные риски:

• over-broad filesystem access;
• dangerous write tools;
• remote server trust issues;
• prompt injection через external data;
• weak approval boundaries;
• accidental capability exposure.

Поэтому рядом с MCP всегда должны стоять:

• permission policy;
• least privilege;
• roots boundaries;
• tool filtering;
• approval flows;
• auditing and logs.

10. Связь с tool use

MCP и tool use связаны, но не равны.

Полезная рамка:

• tool use отвечает на question "как модель инициирует действие";
• MCP отвечает на question "как tools и context стандартизированно публикуются и подключаются".

Именно поэтому MCP так хорошо сочетается с agent runtimes:

• OpenAI Agents SDK;
• Claude Agent SDK;
• IDE agents;
• internal orchestration systems.

Минимальная mental model

Host
  -> Client
    -> initialize
    -> capability negotiation
    -> tools/resources/prompts access
    -> tool calls / resource reads / additional protocol flows
  -> MCP Server

Этой схемы уже достаточно, чтобы не путать MCP с "простым JSON API для функций".

Что уточнить в архитектурной статье

Если вы проектируете MCP integration, обычно надо ответить на 5 вопросов:

1. local server или remote server?
2. какие trust boundaries между host и server?
3. нужны только tools или ещё resources/prompts/logging?
4. какие client capabilities реально поддерживаются?
5. где approval и permission model?

Почему roots и transports важны

Local coding agent:
  host -> stdio server -> repo tools

Remote enterprise assistant:
  host -> Streamable HTTP server -> internal systems

Это два разных operational режима. Если их смешать в одну абстракцию без security design, problems придут быстро.

У нас coding IDE и internal docs server. Когда MCP начинает окупаться?

Проверьте себя