Зачем это нужно
MCP полезен, но не бесплатен. Он добавляет новый слой:
- server;
- client configuration;
- schemas;
- permissions;
- authentication;
- logs;
- versioning;
- failure modes;
- operational support.
Поэтому вопрос не должен звучать так:
Можно ли сделать MCP server?
Почти всегда можно.
Правильный вопрос:
Дает ли MCP достаточно пользы, чтобы оправдать новый integration layer?
Главная цель урока - научиться принимать решение: когда capability стоит оформлять как MCP, а когда лучше оставить локальной командой, script, resource file, skill или прямой встроенный tool.
Основная идея
MCP стоит использовать, когда capability:
внешняя
+
переиспользуемая
+
структурированная
+
требует controlled access
+
полезна нескольким AI clients
Не каждый tool должен стать MCP. Но если команда хочет безопасно и переносимо дать агентам доступ к GitHub, Jira, database, docs, CI или observability, MCP часто становится правильной границей.
MCP как архитектурное решение
Решение "использовать MCP" похоже на решение "выделить отдельный сервис" или "сделать public API". Оно влияет не только на текущую задачу, но и на будущую поддержку, безопасность, debugging и повторное использование.
Если capability маленькая и локальная, MCP может быть лишним слоем. Но если capability становится общей точкой доступа к внешней системе, MCP превращается в архитектурную границу: через нее проходят credentials, permissions, schemas, logs, approvals и user-facing capabilities.
Поэтому важно оценивать не только техническую возможность:
Can we expose this through MCP?
Почти всегда да.
Оценивать нужно engineering value:
Will MCP make this capability safer, clearer, more reusable or easier to govern?
Если ответ "нет", protocol layer не нужен. Если ответ "да", MCP может окупить свою сложность.
Хороший пример - GitHub PR workflow. Команда может сначала дать агенту local git commands. Но как только агент должен читать remote PR comments, смотреть CI status, оставлять review comments и работать из разных clients, появляется value в общей MCP boundary. Там можно настроить scopes, audit, approval для comments и единый interface для нескольких agent hosts.
Плохой пример - локальная команда formatting. Если она уже существует в package.json, запускается в текущем repo и не требует внешних permissions, MCP не добавляет архитектурной ценности.
Короткая формула:
MCP оправдан не сложностью команды,
а ценностью общей управляемой границы.
Ключевые термины
| Термин | Значение |
|---|---|
| External System | Сервис или среда вне самого agent runtime: GitHub, DB, Jira, CI, browser. |
| Reusable Interface | Capability, которую используют разные agents, users или workflows. |
| Controlled Capability | Действие с явными scopes, permissions, audit и constraints. |
| Multi-client Reuse | Один server используется разными AI applications. |
| Integration Layer | Слой между agent host и внешней системой. |
| Cost of Abstraction | Цена нового слоя: поддержка, debugging, security, versioning. |
| Capability Boundary | Граница, где определяется, что agent может делать. |
| Scope | Ограниченное право доступа, например read issues или comment PR. |
| Auditability | Возможность понять, какие actions выполнялись и почему. |
Хорошие случаи для MCP
MCP особенно полезен для integrations:
AI -> GitHub
AI -> Jira / Linear
AI -> PostgreSQL
AI -> Browser automation
AI -> Internal API
AI -> Documentation
AI -> Monitoring / logs
AI -> CI
AI -> Feature flag system
Но не из-за названий сервисов, а из-за свойств этих integrations.
Как читать критерии
Критерии ниже не нужно понимать как независимые галочки. Они усиливают друг друга.
Например, "external service" сам по себе еще не доказывает, что нужен MCP. Можно один раз вызвать external API из script'а для migration report. Но если external service плюс authentication, плюс write actions, плюс несколько clients, плюс audit requirement, MCP становится гораздо сильнее.
Так же "structured schema" само по себе не означает MCP. Локальный script тоже может принимать structured arguments. MCP нужен, когда schema является частью shared integration contract между server и несколькими AI hosts.
Думайте о критериях как о накоплении давления:
Один критерий -> подумать.
Несколько критериев вместе -> MCP становится кандидатом.
Auth + side effects + reuse + audit -> MCP почти наверняка стоит рассмотреть.
В учебных задачах полезно проговаривать это вслух. Агент не должен просто сказать "используем MCP". Он должен объяснить, какие свойства capability делают protocol boundary оправданной.
Критерий 1. External service
Если capability обращается к внешнему сервису, MCP может дать стандартную boundary.
Пример:
create_github_issue(title, body, labels)
comment_on_pr(pr, body)
get_ci_status(branch)
read_sentry_issue(issue_id)
Почему MCP уместен:
- нужен authentication;
- нужны scopes;
- важны audit logs;
- actions имеют side effects;
- список capabilities должен быть discoverable;
- разные agents могут использовать один server.
Если же capability локальная:
npm test
MCP может быть лишним. Это тема урока 7.5.
Критерий 2. Multi-client reuse
MCP особенно силен, когда одна capability нужна нескольким AI clients.
Пример:
Company GitHub MCP server
-> Codex
-> Claude Code
-> Cursor
-> internal support agent
-> release automation agent
Плюсы:
- один interface;
- одна permission model;
- один audit layer;
- меньше дублирования integrations;
- проще обновлять behavior server-side;
- легче отключить опасную capability centrally.
Если capability нужна только одному локальному script в одном репозитории, multi-client benefit отсутствует.
Критерий 3. Structured schema
MCP полезен, когда входы и выходы должны быть строго описаны.
Пример плохого interface:
github(command: string)
Пример лучше:
create_issue({
repo: string,
title: string,
body: string,
labels: string[]
})
comment_on_pr({
repo: string,
pr_number: integer,
body: string
})
Structured schema помогает:
- валидировать arguments;
- показывать clear approval UI;
- логировать действия;
- снижать prompt injection risk;
- возвращать predictable results;
- тестировать tools.
Критерий 4. Authentication и scopes
Если capability требует credentials, MCP server может стать местом, где доступ ограничен.
Пример:
GitHub token:
- read pull requests
- read issues
- comment on PR
- no repository administration
- no secrets access
Или database:
PostgreSQL role:
- read schema
- read selected tables
- no write
- no DDL
- statement timeout
- row limit
Правильная мысль:
Агент не должен владеть root token.
Tool должен получать только минимальные права для своей задачи.
Критерий 5. Controlled side effects
Если action меняет состояние, MCP может помочь сделать это управляемо:
- создать issue;
- оставить PR comment;
- изменить ticket status;
- rerun CI;
- deploy preview;
- update feature flag;
- создать incident note.
Controlled side effect означает:
- tool ясно называется;
- input schema ограничена;
- permission scope узкий;
- approval policy понятна;
- action logged;
- result observable.
Критерий 6. Dynamic context
MCP полезен, когда context живет вне репозитория и меняется:
- GitHub PR diff;
- issue comments;
- CI logs;
- database schema;
- monitoring alerts;
- runbook updates;
- customer support tickets;
- docs search index.
Если context статический и лежит в репозитории, иногда достаточно обычного файла:
docs/architecture.md
skills/create-api-endpoint/references/api-style.md
Если context динамический, permissions-aware и общий для нескольких clients, MCP выглядит сильнее.
Критерий 7. Audit и governance
MCP полезен, когда команда хочет видеть:
- кто вызвал tool;
- через какой agent host;
- с какими arguments;
- какой result вернулся;
- был ли approval;
- какой scope использовался;
- были ли denied actions.
Это особенно важно для:
- production data;
- customer data;
- billing;
- deployment;
- access management;
- incident operations.
Без audit MCP может стать просто удобным туннелем для опасных действий. Это не цель.
Decision checklist
Перед созданием MCP server спросите:
| Вопрос | Если да |
|---|---|
| Capability нужна нескольким agent clients? | MCP сильный кандидат. |
| Capability обращается к external service? | MCP сильный кандидат. |
| Нужны credentials/scopes? | MCP сильный кандидат. |
| Нужна structured schema? | MCP полезен. |
| Есть side effects? | MCP может дать control boundary. |
| Нужно audit logging? | MCP полезен. |
| Данные динамические и внешние? | MCP полезен. |
| Нужны read resources и write tools вместе? | MCP полезен. |
| Это одна локальная команда? | Скорее MCP не нужен. |
| Это one-off workflow? | Скорее MCP не нужен. |
Decision score
Можно использовать простую оценку.
| Критерий | Балл |
|---|---|
| External service | +2 |
| Multi-client reuse | +2 |
| Auth/scopes | +2 |
| Structured schema needed | +1 |
| Side effects | +2 |
| Audit required | +2 |
| Dynamic external context | +1 |
| One local command | -2 |
| Single user, single repo | -1 |
| No auth, no side effects | -1 |
Интерпретация:
| Score | Решение |
|---|---|
| 0-2 | MCP скорее не нужен. |
| 3-5 | Посмотреть на cost/benefit. |
| 6+ | MCP сильный кандидат. |
Это не научная формула, а способ сделать обсуждение явным.
Сценарий 1. GitHub PR review
Задача:
Agent должен читать PR diff, comments, CI status и по approval оставлять review comment.
MCP нужен?
Скорее да.
Почему:
- external service;
- auth/scopes;
- read resources: PR diff, comments, CI logs;
- write tools: comment, request changes;
- several clients могут использовать один server;
- audit важен.
Design:
Resources:
- github://repo/pull/123/diff
- github://repo/pull/123/comments
- github://repo/pull/123/checks
Tools:
- comment_on_pr(pr, body)
- request_review_changes(pr, body)
Prompts:
- review_pr_against_spec
Approval:
Read resources: auto within repo scope.
Comment tool: approval or explicit user request.
Request changes: approval required.
Сценарий 2. PostgreSQL schema и read-only query
Задача:
Agent должен читать database schema и иногда выполнять read-only query.
MCP нужен?
Часто да.
Почему:
- database external или shared system;
- credentials и scopes критичны;
- resource для schema;
- tool для query;
- read limits, timeout, redaction;
- audit нужен.
Design:
Resources:
- db://main/schema
- db://main/tables/users
Tools:
- query_readonly(sql, max_rows)
- explain_query(sql)
Policy:
No writes.
No DDL.
Row limits.
Statement timeout.
Redact sensitive columns.
Сценарий 3. Project documentation
Задача:
Agent должен отвечать по внутренней документации и ADR.
MCP нужен?
Зависит.
Если docs лежат в репозитории:
docs/adr/*.md
docs/development/*.md
MCP может быть лишним.
Если docs в shared system:
Notion
Confluence
Google Drive
internal docs search
MCP становится полезным.
Design:
Resources:
- docs://adr/current
- docs://runbook/payments
- docs://api/auth
Prompts:
- answer_with_sources
- draft_adr
Tools могут не понадобиться.
Сценарий 4. Browser automation
Задача:
Agent должен открыть web UI, заполнить форму, проверить состояние.
MCP нужен?
Возможен, если browser automation должна быть reusable и controlled.
Почему:
- действия могут менять внешнее состояние;
- нужны permissions и approval;
- нужен state handle для browser context;
- several agent clients могут использовать один automation server;
- logs/screenshots полезны для audit.
Но для локального Playwright debug одного проекта часто достаточно локального script или встроенного tool.
Decision зависит от масштаба.
Сценарий 5. CI status и rerun
Задача:
Agent должен читать CI status и иногда перезапускать job.
MCP нужен?
Скорее да, если это shared team workflow.
Разделение:
Resource:
- ci://repo/branch/main/latest
- ci://runs/123/logs
Tool:
- rerun_ci_job(run_id)
Policy:
Read status: auto.
Rerun: maybe approval if costly.
Cancel workflow: approval required.
Cost of abstraction
MCP добавляет стоимость:
- server нужно писать или подключать;
- schemas нужно поддерживать;
- permissions нужно проектировать;
- credentials нужно хранить безопасно;
- logs нужно анализировать;
- failures нужно debug;
- versions нужно обновлять;
- clients нужно конфигурировать;
- security нужно ревьюить.
Если выгоды меньше стоимости, не создавайте MCP.
Признаки хорошей инвестиции:
- capability часто используется;
- capability важна для нескольких workflows;
- risk достаточно высок, чтобы нужен central control;
- integration сложно повторять в каждом client;
- schema и permissions стабилизируются.
MCP vs прямой встроенный tool
Иногда tool можно встроить прямо в agent runtime без MCP.
| Встроенный tool | MCP |
|---|---|
| Быстро для одного client | Лучше для нескольких clients |
| Меньше infrastructure | Лучше standard boundary |
| Подходит для local-only | Подходит для external/shared |
| Permissions часто host-specific | Permissions можно централизовать |
| Меньше portability | Больше portability |
Решение:
Если capability локальная и маленькая, встроенный tool проще.
Если capability shared, external и permissioned, MCP сильнее.
Практика: нужен ли MCP
Оцените 5 возможностей:
| Capability | MCP? | Причина |
|---|---|---|
npm test для текущего repo |
||
| GitHub PR comments | ||
| Read-only database schema | ||
Local script ./scripts/format.sh |
||
| Company docs search in Confluence |
Возможное решение:
| Capability | MCP? | Причина |
|---|---|---|
npm test |
Нет | Local command, no shared external integration. |
| GitHub PR comments | Да | External service, auth, write action, audit. |
| Read-only database schema | Да, если DB external/shared | Credentials, scopes, dynamic resource. |
./scripts/format.sh |
Нет | Local deterministic script. |
| Company docs search | Да | External docs, dynamic context, multiple clients. |
Типичные ошибки
| Ошибка | Симптом | Исправление |
|---|---|---|
| MCP для каждой команды | Слишком много servers | Оставить local commands/scripts. |
| MCP без permissions | Agent получает слишком широкие права | Design scopes до tools. |
| MCP ради моды | Нет reuse, только complexity | Проверить decision score. |
| Один huge MCP server | Большая blast radius | Делить по domain/risk. |
| Tool вместо resource | Read-only data получает write-like risk | Использовать resources. |
| Нет audit | Невозможно расследовать действия | Логировать calls/results/approvals. |
| No fallback | При недоступности server агент застревает | Описать degradation path. |
Критерии готовности
После урока студент должен уметь:
- объяснить, когда MCP оправдан;
- применить checklist решения;
- оценить external service, auth, scopes, reuse и audit;
- отличить хороший MCP use case от overengineering;
- спроектировать primitives для GitHub/DB/docs/CI сценария;
- назвать cost of abstraction.
Краткое резюме
MCP стоит использовать, когда capability должна быть переносимой, структурированной, внешней, permissioned и reusable. Особенно сильные случаи: GitHub, Jira/Linear, database, docs search, monitoring, CI и internal APIs.
Но MCP не бесплатен. Это новый operational и security слой. Поэтому решение должно быть осознанным:
Если нужна shared controlled capability - MCP.
Если нужна простая локальная команда - скорее нет.
Вопросы для самопроверки
- Какие признаки делают capability хорошим кандидатом на MCP?
- Почему multi-client reuse важен?
- Когда database schema лучше отдавать через MCP resource?
- Почему
create_pr_commentтребует другой policy, чем чтение PR diff? - Какие costs появляются при добавлении MCP server?
Что дальше
В следующем уроке разберем противоположную сторону: когда MCP не нужен. Это важно, потому что agentic systems легко превращаются в музей абстракций, где простая команда npm test идет через server, protocol, auth layer и пять failure modes.