Урок 7.2. Что такое MCP

Зачем это нужно

В уроке 7.1 мы разобрали tool как исполняемую capability агента. Но если каждая AI application подключает tools по-своему, быстро возникает интеграционный зоопарк.

Один и тот же GitHub workflow приходится отдельно встраивать в:

• Codex;
• Claude Code;
• Cursor;
• внутренний agent host;
• IDE extension;
• CI automation;
• кастомный multi-agent orchestrator.

Каждый клиент по-своему решает:

• как узнать доступные tools;
• как передать arguments;
• как получить result;
• как дать read-only context;
• как показать reusable prompts;
• как управлять permissions;
• как подключить local или remote server.

MCP - Model Context Protocol - нужен как стандартный слой между AI applications и внешними capabilities.

Главная цель урока - понять архитектуру MCP: host, MCP client, MCP server, tools, resources, prompts и external systems.

Основная идея

Model Context Protocol - это стандартный способ соединять AI applications с внешними context и capabilities.

Упрощенно:

AI application хочет использовать внешний мир.
MCP задает общий протокол, как этот внешний мир подключить.

Базовая схема:

AI Agent / Host
       |
   MCP Client
       |
       v
   MCP Server
   |-- Tools
   |-- Resources
   `-- Prompts
       |
       v
External System

External system может быть:

• GitHub;
• Jira;
• Linear;
• PostgreSQL;
• browser automation;
• internal API;
• documentation store;
• monitoring system;
• CI/CD platform.

MCP не заменяет агента и не является моделью. MCP стандартизирует границу доступа к tools и context.

MCP как граница системы

MCP полезно понимать не как "еще один способ вызвать API", а как системную границу между agent host и внешними capabilities. На этой границе решается, какие действия доступны, как они описаны модели, какие данные можно читать, какие prompts можно предложить пользователю и какие permissions применяются.

Без такой границы каждая agent application начинает изобретать собственный способ подключать GitHub, database, docs, CI, browser automation и internal APIs. В одном клиенте tool называется github_action, в другом call_github, в третьем просто run. Где-то output structured, где-то plain text. Где-то write action требует approval, где-то нет. В результате команда не может уверенно сказать, что "агент имеет безопасный доступ к GitHub". У нее есть набор разных, несовместимых интеграций.

MCP предлагает другой mental model:

External capability is packaged once as a server.
Host connects through a known protocol.
Capabilities are discoverable.
Tools, resources and prompts have metadata.
Policies can be applied at the boundary.

Это не означает, что MCP автоматически делает интеграцию хорошей. Плохо спроектированный MCP server все еще может быть опасным. Но MCP дает место, где можно выразить хороший дизайн: узкие tools, read-only resources, reusable prompts, scopes, approvals, logs и понятные errors.

Для курса важна именно эта мысль: MCP не про "модную интеграцию", а про переносимую и управляемую границу capability.

Ключевые термины

Почему не хватит "просто API"

Можно спросить:

Почему агент просто не вызывает REST API напрямую?

Потому что у agent integrations есть повторяющиеся проблемы:

• model-facing descriptions;
• input schemas;
• structured outputs;
• tool discovery;
• read-only resources;
• prompt templates;
• permissions;
• approvals;
• audit;
• local tools;
• remote services;
• multiple AI clients.

Обычный REST API обычно проектируется для приложения или backend service. MCP проектируется именно для AI applications, которым нужно предоставить tools и context в понятном, discoverable и управляемом виде.

Что меняется для разработчика

Если смотреть глазами backend-разработчика, MCP может казаться лишней прослойкой над уже существующим API. Но agent-facing integration отличается от обычной backend integration.

Обычный backend client обычно пишет человек-программист. Он читает документацию API, выбирает endpoint, обрабатывает edge cases в коде, добавляет retries, логирует результат и деплоит приложение. LLM-agent работает иначе: он видит descriptions, выбирает tool по текстовому описанию, строит arguments в момент выполнения и использует результат как часть reasoning loop.

Из-за этого для agent integration особенно важны:

• names and descriptions, которые модель не перепутает;
• schema, которая ограничивает arguments;
• output, который модель может превратить в evidence;
• permissions, которые не зависят от доброй воли модели;
• resource boundaries, чтобы data не стала instruction;
• prompts, которые помогают пользователю запускать типовые workflows;
• audit, чтобы действия агента можно было восстановить.

MCP собирает эти требования в один interface. Разработчик MCP server проектирует не просто "обертку над API", а модель взаимодействия между AI host, external system и policy.

Хороший вопрос при проектировании MCP server:

Что должен увидеть agent host,
чтобы модель могла безопасно и предсказуемо использовать capability?

Ответ редко ограничивается endpoint URL. Обычно нужны primitive type, description, schema, permissions, examples, error semantics и approval policy.

Участники MCP

MCP Host

Host - это AI application.

Примеры:

Codex-like coding agent
Claude Desktop
IDE agent
internal support agent
multi-agent orchestrator

Host отвечает за:

• взаимодействие с пользователем;
• выбор model/runtime;
• управление MCP clients;
• permission UI;
• включение tool/resource metadata в контекст модели;
• обработку results;
• policies.

MCP Client

Client - это connector внутри host для одного MCP server.

Если host подключен к трем servers, обычно есть три clients:

Host
├── MCP Client -> GitHub MCP Server
├── MCP Client -> PostgreSQL MCP Server
└── MCP Client -> Docs MCP Server

Client отвечает за:

• соединение с server;
• discovery capabilities;
• отправку requests;
• получение responses;
• передачу data в host.

MCP Server

Server - это программа, которая предоставляет primitives:

tools
resources
prompts

Server может быть:

• local process;
• remote HTTP service;
• wrapper вокруг SaaS API;
• wrapper вокруг internal system;
• read-only documentation provider;
• local filesystem/context provider.

Server не обязан быть "большим сервисом". Но если он дает внешние capabilities агенту, его нужно проектировать с permissions и audit.

MCP layers

MCP удобно мыслить двумя слоями:

Для курса 101 важно понимать не детали wire protocol, а engineering boundary:

Data layer говорит "что доступно и как вызвать".
Transport layer говорит "как доставить сообщение".

На практике MCP поддерживает local transports, например stdio, и remote transports, например Streamable HTTP. Local server удобен для инструментов на машине разработчика. Remote server удобен для SaaS, team services и shared integrations.

Tools, Resources, Prompts

MCP server может предоставлять три главных server primitives:

Главная ошибка новичка:

Все превращать в tool.

Если capability только читает context, возможно, это resource. Если это reusable instruction, возможно, это prompt. Если это действие с side effects, это tool.

Эту границу подробно разберем в уроке 7.3.

Capability Discovery

MCP нужен не только для вызова tools. Он еще позволяет host понять, что server умеет.

Упрощенный flow:

Зачем discovery:

• host не должен угадывать server capabilities;
• tools/resources/prompts могут меняться;
• permissions могут ограничивать список доступного;
• UI может показать пользователю, что подключено;
• модель получает только релевантные capabilities.

Local MCP server

Local server запускается на машине пользователя или agent environment.

Примеры:

filesystem MCP server
local git MCP server
local docs index
local browser automation server
local test runner wrapper

Плюсы:

• быстрый доступ к локальным файлам;
• нет сетевой задержки;
• удобно для developer workflows;
• можно использовать local credentials или local environment.

Минусы:

• сложнее share между командой;
• зависит от local setup;
• security зависит от machine permissions;
• не всегда подходит для SaaS integrations.

Remote MCP server

Remote server работает как сетевой сервис.

Примеры:

GitHub MCP server
Sentry MCP server
Jira MCP server
PostgreSQL gateway
internal observability server
company docs server

Плюсы:

• общий endpoint для разных clients;
• centralized permissions;
• audit logs;
• team governance;
• проще обновлять server-side logic.

Минусы:

• нужна authentication;
• нужно думать о scopes;
• есть network failure modes;
• выше требования к security;
• нужна политика для write/destructive actions.

Пример 1: GitHub

MCP server для GitHub может предоставить:

Tools:

create_issue(title, body, labels)
comment_on_pr(pr_number, body)
request_review(pr_number, reviewers)

Resources:

github://repo/pull/123/diff
github://repo/issues/456
github://repo/actions/runs/789/logs

Prompts:

review_pull_request
summarize_issue_thread
prepare_release_notes

Agent workflow:

Read PR diff resource
Use review prompt
Maybe call comment_on_pr tool after user approval

Пример 2: PostgreSQL

MCP server для database может предоставить:

Resources:

db://main/schema
db://main/tables/users
db://main/views/monthly_revenue

Read tools:

query_readonly(sql)
explain_query(sql)

Write tools, если вообще разрешены:

request_migration_review(migration_sql)

Важно: не нужно делать run_any_sql(sql) без ограничений. Database MCP особенно требует least privilege.

Пример 3: Documentation

Docs MCP server может быть почти полностью resource-oriented:

Resources:

docs://architecture/current
docs://adr/004-event-boundaries
docs://runbooks/payments-incident

Prompts:

summarize_runbook
answer_with_sources
draft_adr

Tools могут вообще не понадобиться, если server только отдает read-only knowledge.

Что MCP не делает

MCP не является:

• LLM model;
• agent planner;
• replacement для specs;
• replacement для skills;
• secret manager сам по себе;
• universal security solution;
• reasoner;
• deployment platform;
• guarantee, что tool безопасен.

MCP задает стандартный interface. Без правильного design плохой MCP server просто стандартизирует плохую интеграцию.

MCP и Skills

Skills и MCP часто работают вместе, но отвечают за разные вопросы.

Пример:

Skill: review-code-against-spec
MCP Resource: github://repo/pull/123/diff
MCP Tool: comment_on_pr()
MCP Prompt: review_pull_request

Skill может сказать:

Read PR diff resource, compare with spec, produce findings.
Only call comment tool after user confirms.

MCP дает capability. Skill задает procedure.

Практика: MCP схема для demo workflow

Задача:

AI agent должен помочь разработчику обработать GitHub PR:
1. Прочитать diff.
2. Сравнить его со spec.
3. Проверить CI.
4. Написать review summary.
5. По approval оставить comment в PR.

Нарисуйте схему:

Host:

MCP Clients:

MCP Servers:

Tools:

Resources:

Prompts:

Approval points:

Пример ответа:

Host:
Codex-like coding agent

MCP Clients:
- GitHub client
- Docs/spec client
- CI client

MCP Servers:
- GitHub MCP server
- Project docs MCP server
- CI MCP server

Resources:
- github://repo/pull/123/diff
- docs://specs/team-invitations
- ci://runs/456/logs

Tools:
- comment_on_pr(pr, body)
- rerun_ci(run_id)

Prompts:
- review_pr_against_spec

Approval points:
- comment_on_pr requires user confirmation
- rerun_ci may require confirmation depending on cost

Типичные ошибки

Критерии готовности

После урока студент должен уметь:

• объяснить, зачем нужен MCP;
• назвать роли host, MCP client и MCP server;
• объяснить tools, resources и prompts на верхнем уровне;
• отличить local MCP server от remote MCP server;
• нарисовать MCP architecture для простого workflow;
• объяснить, как MCP связан со skills;
• назвать границы MCP.

Краткое резюме

MCP - это протокол для подключения AI applications к внешним context и capabilities. Он помогает не писать отдельную интеграцию под каждого agent client.

Ключевая архитектура:

Host -> MCP Client -> MCP Server -> External System

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

• tools для действий;
• resources для context;
• prompts для reusable templates.

MCP делает integrations переносимыми и управляемыми, но не отменяет необходимость проектировать permissions, scopes, approvals и safety boundaries.

Вопросы для самопроверки

1. Чем MCP host отличается от MCP client?
2. Почему один host может иметь несколько MCP clients?
3. Что MCP server предоставляет agent application?
4. Когда лучше local MCP server, а когда remote MCP server?
5. Почему MCP не заменяет skills?

Что дальше

В следующем уроке мы разберем три primitives MCP подробнее: tools, resources и prompts. Это важная граница: если read-only context ошибочно сделать write-capable tool, agent system станет опаснее без реальной пользы.