Зачем это нужно
После урока 7.4 может появиться соблазн:
Давайте завернем в MCP все.
Но это плохая инженерная привычка. MCP полезен как boundary для внешних, shared, permissioned capabilities. Он не должен становиться обязательной упаковкой для каждой локальной команды.
Иногда лучший инструмент для агента:
npm test
или:
./scripts/verify.sh
без MCP server, без network transport, без отдельной auth model и без protocol lifecycle.
Главная цель урока - научиться видеть overengineering и выбирать самый простой безопасный механизм.
Основная идея
MCP не нужен, если capability:
локальная
+
простая
+
одноклиентская
+
без external auth
+
без shared governance
+
без сложной structured integration
В таких случаях MCP может добавить больше риска, чем пользы.
Принцип:
Use the simplest mechanism that gives enough control.
Не самый сложный. Не самый модный. Достаточный.
Почему простое решение часто безопаснее
В agent development сложность сама по себе является риском. Каждый дополнительный слой добавляет новые способы ошибиться:
- агент может неправильно выбрать capability;
- server может быть недоступен;
- schema может устареть;
- credentials могут быть настроены слишком широко;
- permissions могут дублировать уже существующие правила;
- logs могут стать неполными;
- error может появиться не в задаче, а в integration layer.
Когда capability локальная и понятная, простой механизм часто безопаснее именно потому, что его легче проверить. Если студент видит:
npm test
он понимает, какая команда выполняется, где она выполняется и как увидеть результат. Если вместо этого появляется MCP server, нужно понимать lifecycle server'а, transport, client config, tool schema, permission mapping и failure modes. Иногда это оправдано. Для локального test command чаще нет.
Простота здесь не означает "без контроля". Правильная простая схема все равно может иметь guardrails:
Project command:
./scripts/verify.sh
Hook:
BeforeCommit runs scripts/verify.sh
CI:
Runs the same script in clean environment
Agent rule:
Report command result as evidence
Это управляемый процесс без MCP. Он лучше, чем сложная integration, которая не добавляет safety.
Критерий:
Если simpler mechanism уже дает verification, scope и evidence,
не поднимайтесь на уровень MCP без дополнительной причины.
Ключевые термины
| Термин | Значение |
|---|---|
| Overengineering | Добавление лишнего слоя сложности без достаточной пользы. |
| Local Command | Команда, выполняемая в репозитории или среде разработки. |
| Local Script | Script в repo, например scripts/verify.sh. |
| Direct Tool | Tool, встроенный в agent runtime без MCP. |
| Protocol Layer | Дополнительный слой взаимодействия client/server. |
| Single-client Workflow | Capability нужна только одному agent host или одному проекту. |
| Operational Cost | Стоимость поддержки, debugging, updates, permissions и monitoring. |
| Blast Radius | Масштаб ущерба при ошибке capability. |
Пример: npm test
Задача:
Agent должен запускать tests проекта.
Очевидное решение:
npm test
или:
npm test -- tests/api/projects.test.ts
Нужен ли MCP?
Обычно нет.
Почему:
- команда уже есть в проекте;
- она локальная;
- не требует external auth;
- результат виден через stdout/stderr;
- scope можно ограничить рабочей директорией;
- один agent runtime может запустить ее напрямую;
- skill может описать, когда ее запускать.
MCP server вокруг npm test может добавить:
- отдельный process;
- config;
- transport errors;
- schema drift;
- permissions duplication;
- debugging overhead.
Если пользы нет, слой лишний.
Когда local script лучше MCP
Local script хорош, когда:
- действие живет внутри repo;
- оно нужно только этому проекту;
- нет external service;
- нет shared multi-client потребности;
- нет сложной auth;
- script deterministic;
- его легко проверить локально;
- он версионируется вместе с кодом.
Пример:
scripts/
├── verify.sh
├── check-openapi.sh
└── generate-types.sh
Skill может сказать:
Run `scripts/check-openapi.sh` when the API contract changed.
Не обязательно делать:
OpenAPI MCP server with check_contract tool
если check используется только в одном repo.
Когда direct tool лучше MCP
Direct tool может быть встроен в agent runtime:
read_file(path)
search_repository(query)
apply_patch(patch)
run_shell(command)
MCP не нужен, если:
- host уже предоставляет эту capability;
- capability low-level и локальная;
- нет необходимости делиться ей между clients;
- permission model host уже достаточна;
- protocol boundary ничего не улучшает.
Например, coding agent обычно уже умеет:
- читать files;
- искать по repo;
- применять patches;
- запускать commands с approval.
Не нужно оборачивать каждый из этих actions в отдельный MCP server внутри того же host.
Когда skill лучше MCP
Иногда задача не требует новой capability. Она требует правильной procedure.
Пример:
Как добавить endpoint с tests и OpenAPI update?
Это skill:
create-api-endpoint/SKILL.md
А не MCP.
Skill может использовать existing tools:
read_file
search_repository
apply_patch
run_tests
MCP нужен только если endpoint workflow требует external capability, например:
- прочитать GitHub issue;
- обновить external API catalog;
- запросить schema из remote database;
- оставить PR comment.
Когда resource file лучше MCP resource
Если информация статична и живет в repo, храните ее в repo.
Пример:
docs/adr/004-api-boundaries.md
docs/development/testing.md
skills/create-api-endpoint/references/api-style.md
MCP resource полезнее, если:
- источник внешний;
- context динамический;
- нужны per-user permissions;
- много clients;
- нужен search API;
- источник не может быть просто checked-in file.
Не усложняйте local docs:
docs://local/adr/004
если агент может прочитать:
docs/adr/004-api-boundaries.md
Cost of unnecessary MCP
Лишний MCP создает не только "немного кода".
Он добавляет:
- server lifecycle;
- client configuration;
- connection failures;
- protocol compatibility;
- auth decisions;
- permissions mapping;
- schema versioning;
- deployment или local install;
- logs;
- docs;
- testing;
- security review;
- support burden.
Для маленькой локальной команды это может быть absurdly heavy.
Decision table
| Capability | Лучший механизм | Почему |
|---|---|---|
npm test |
Project command/direct tool | Local, simple, existing. |
./scripts/check-openapi.sh |
Local script | Repo-specific deterministic check. |
| "Как добавить endpoint" | Skill | Procedure, not capability. |
docs/adr/*.md |
Local files/references | Static repo context. |
| GitHub PR comment | MCP tool | External write, auth, audit. |
| Read GitHub PR diff | MCP resource | External dynamic context. |
| Query production DB | MCP tool with strict policy | External sensitive action. |
| One-off data cleanup | Manual task or migration workflow | MCP may hide risk. |
Сценарий 1. Local formatter
Задача:
Run project formatter before final diff.
Команда:
npm run format
MCP нужен?
Нет, если:
- formatter уже в project scripts;
- agent runtime умеет запускать commands;
- нет external auth;
- команда не shared service.
Достаточно:
Project rule:
Run formatter before final diff when files were edited.
Tool:
run_shell or run_project_command.
Сценарий 2. OpenAPI validation
Задача:
Проверить OpenAPI contract после изменения endpoint.
Вариант 1:
scripts/check-openapi.sh
MCP не нужен, если check локальный и repo-specific.
Вариант 2:
Company-wide API registry validates contracts for 40 services and publishes compatibility reports.
MCP может быть нужен:
- external system;
- shared interface;
- auth;
- structured result;
- audit.
Вывод:
Не сама тема "OpenAPI" решает.
Решает boundary: local script или shared external service.
Сценарий 3. Local database for tests
Задача:
Agent должен поднять docker compose и прогнать integration tests.
MCP обычно не нужен.
Лучше:
docker compose up -d
npm run test:integration
с approval, если команда дорогая или меняет local state.
MCP может понадобиться, если:
- это shared database service;
- нужно per-user auth;
- queries должны логироваться;
- schema/resources используются несколькими clients.
Сценарий 4. One-off script
Задача:
Один раз переименовать 20 files в repo.
Не нужен MCP.
Лучше:
- локальный script;
- careful patch;
- git diff review;
- tests.
MCP server для одноразового rename workflow будет просто сложнее.
Сценарий 5. Company-wide docs search
Задача:
Agent должен искать по Confluence/Notion/Drive docs.
MCP часто нужен.
Почему:
- docs external;
- permissions per user;
- search API;
- dynamic updates;
- много clients;
- нужны source links;
- возможно redaction.
Это хороший контраст с local docs/ в repo.
Anti-pattern: MCP как wrapper вокруг shell
Плохо:
tool: run(command)
description: Runs any shell command.
Почему это плохой MCP:
- слишком широкие права;
- schema ничего не ограничивает;
- approvals сложные;
- audit мало полезен;
- command injection risk;
- server становится remote shell.
Лучше:
run_tests(path, mode)
check_openapi(contract_path)
generate_types(schema_path)
И еще лучше: если это только local repo command, оставить script/direct command.
Anti-pattern: MCP ради naming
Иногда MCP создают, чтобы capability выглядела "официальнее":
format_code MCP server
lint_code MCP server
read_readme MCP server
Но official-looking layer не делает workflow лучше.
Признак проблемы:
MCP server сложнее самой capability.
Если server нужен только для того, чтобы вызвать одну строку shell, вероятно, он не нужен.
Anti-pattern: hiding risk
MCP может случайно скрыть опасность за красивым tool name.
Плохо:
sync_environment()
Что внутри?
- deploy?
- delete?
- migrate?
- overwrite config?
- restart service?
Лучше:
read_environment_status()
create_preview_deployment()
request_production_deploy()
rollback_deployment()
Если action high-risk, MCP должен делать риск видимым, а не прятать его.
Simplicity ladder
Выбирайте самый простой достаточный механизм:
1. Existing file/context
2. Project command
3. Local script
4. Skill procedure
5. Direct host tool
6. MCP resource/tool/prompt
7. Full external service integration
Поднимайтесь выше только если lower level не дает нужного:
- reuse;
- permissions;
- structured schema;
- external access;
- audit;
- multi-client support.
Как решение эволюционирует
Отказ от MCP сегодня не означает запрет MCP навсегда. Хорошая архитектура может расти постепенно.
Например, сначала команда имеет локальный script:
scripts/check-openapi.sh
Потом этот script начинают копировать в несколько repos. Затем появляется shared API registry. Потом агентам нужно получать compatibility reports из registry, а не только запускать локальный check. Потом несколько AI clients должны использовать один и тот же interface. На этом этапе MCP может стать правильным следующим шагом.
Эволюция может выглядеть так:
Local script
-> shared script package
-> internal service
-> MCP server exposing resources/tools
Важно, чтобы каждый шаг решал реальную проблему. MCP не должен появляться в начале только потому, что когда-нибудь capability может стать shared. Но и оставаться на shell script навсегда не нужно, если requirements выросли.
Хороший architecture note:
Current decision:
Use local script because capability is repo-specific and has no external auth.
Revisit if:
- more than 3 repos need it;
- output must be consumed by multiple agent clients;
- external registry becomes source of truth;
- audit or per-user scopes become required.
Так студент учится не спорить "MCP или не MCP" абстрактно, а фиксировать условия пересмотра решения.
Practice: выбрать механизм
Классифицируйте:
| Capability | Механизм | Почему |
|---|---|---|
| Запустить unit tests | ||
| Прочитать local ADR | ||
| Создать Jira ticket | ||
| Применить coding workflow для endpoint | ||
| Проверить status CI в GitHub Actions | ||
| Запустить local formatter | ||
| Получить production payment logs |
Возможное решение:
| Capability | Механизм | Почему |
|---|---|---|
| Unit tests | Project command/direct tool | Local existing action. |
| Local ADR | File/resource in repo | Static context. |
| Jira ticket | MCP tool | External write, auth, audit. |
| Endpoint workflow | Skill | Procedure. |
| GitHub Actions status | MCP resource/tool | External dynamic data. |
| Local formatter | Project command | Simple local action. |
| Production payment logs | MCP resource/tool with strict policy | Sensitive external context. |
Checklist: MCP не нужен, если
- capability локальная;
- команда уже есть в repo;
- это one-off task;
- нет external auth;
- нет shared clients;
- нет central audit requirement;
- нет dynamic external data;
- нет side effects вне local workspace;
- schema не добавляет ценности;
- skill или script решает проблему проще;
- MCP server будет сложнее самой capability.
Checklist: пересмотреть решение, если
- capability начала использоваться в нескольких projects;
- разные agent clients копируют одну integration;
- появились credentials/scopes;
- появились external writes;
- нужен audit;
- нужны per-user permissions;
- local script начал зависеть от SaaS API;
- output нужно сделать structured для разных clients;
- появились security incidents или near misses.
Тогда MCP может стать оправданным на следующей итерации.
Типичные ошибки
| Ошибка | Симптом | Исправление |
|---|---|---|
| "MCP для всего" | Система становится тяжелой | Начать с simplest sufficient mechanism. |
| Wrapper around shell | Tool принимает arbitrary command | Использовать local command или узкий tool. |
| Static docs через server | Slow and brittle | Читать local docs directly. |
| Skill заменяют MCP | Capability вместо procedure | Вернуть workflow в skill. |
| One-off migration server | Сложность больше задачи | Сделать migration/spec/test workflow. |
| Нет removal strategy | Старые MCP servers остаются навсегда | Периодически ревьюить capability catalog. |
Критерии готовности
После урока студент должен уметь:
- объяснить, почему MCP не нужен для каждой команды;
- сравнить local script, skill, direct tool и MCP;
- распознать overengineering;
- выбрать простой безопасный механизм;
- объяснить, когда решение нужно пересмотреть;
- сравнить
npm testи CI/MCP integration.
Краткое резюме
MCP - мощный integration boundary, но не универсальная упаковка. Он нужен для shared, external, structured, permissioned capabilities. Для локальных команд, repo scripts, static docs и one-off workflows часто лучше использовать более простой механизм.
Главная формула:
MCP должен уменьшать сложность системы в целом,
а не только красиво упаковывать маленькую команду.
Вопросы для самопроверки
- Почему
npm testобычно не требует MCP? - Когда local script стоит оставить script, а не превращать в MCP tool?
- Чем skill лучше MCP для повторяемой procedure?
- Какие признаки говорят, что решение пора пересмотреть в сторону MCP?
- Почему
run_any_commandкак MCP tool опасен?
Что дальше
Когда MCP действительно нужен, следующий вопрос - безопасность. В уроке 7.6 мы разберем least privilege, scopes, credentials, audit logs, approvals, destructive actions и prompt injection. MCP не делает tool безопасным автоматически. Он только дает место, где безопасность можно спроектировать.