Роутинг MCP и плагинов в ChatGPT/Codex, Claude Code, Cursor и Antigravity

Роутинг в агентной среде — это не скрытый «диспетчер», который гарантированно выбирает лучший инструмент. На практике это цепочка: клиент обнаруживает MCP-серверы, плагины и инструкции, собирает доступный модели каталог, модель выбирает tool по запросу и metadata, после чего политики доступа, transport и auth решают, можно ли выполнить вызов. Надежная конфигурация поэтому начинается с узкого набора инструментов, уникальных namespaces, least privilege и проверяемых approval/logging rules, а не с установки максимального числа интеграций.

Материал актуален на 6 сентября 2026 года. Внутренние алгоритмы ранжирования OpenAI, Anthropic, Cursor и Google не опубликованы, поэтому ниже сравниваются только документированные механизмы и тесты, которые можно воспроизвести.

Что именно маршрутизируется

В разговоре о MCP словом «роутинг» часто называют разные процессы. Из-за этого две команды могут обсуждать одну интеграцию, но иметь в виду разные проблемы: у одной сервер не обнаружился, у другой модель выбрала похожий tool, у третьей вызов остановила политика.

Полезно разделять девять уровней:

Уровень	Вопрос, на который он отвечает	Типичная ошибка
Discovery	Где host ищет конфиги, плагины, skills и rules?	Отредактирован global config, а активен project config
Каталог	Какие tools, descriptions и schemas видит модель?	Сервер подключен, но tool скрыт deny list или не прошел schema validation
Выбор модели	Какой tool подходит к запросу?	Два похожих search конкурируют, а descriptions не разделяют сценарии
Namespace	Как отличить одинаковые имена из разных источников?	Policy написана для bare name и не совпадает с namespaced tool
Политика	Разрешен ли server/tool и нужен ли approval?	«Read-only» annotation принят за надежную гарантию
Transport	Где исполняется вызов: stdio или HTTP?	Windows-host пытается запустить Linux path либо container обращается к своему localhost
Auth	Какая identity и какие scopes сопровождают вызов?	Один общий token открывает данные нескольких tenants
Scope	Для какого пользователя, проекта или workspace доступна интеграция?	Личный server незаметно переопределяет team configuration
Lifecycle	Когда server стартует, обновляется, отключается и повторяет вызов?	После update остались старые credentials или process, а retry повторил mutation

MCP, plugin, connector, skill и rule — разные слои

Сравнивать «MCP или plugin» можно только после определения задачи. MCP дает модели внешние данные и действия. Plugin упаковывает компоненты для установки. Skill объясняет workflow. Rule добавляет инструкцию в контекст. Ни один из этих слоев не заменяет backend authorization.

Сущность	Назначение	Пример	Граница доверия
Native tool	Функция самого host: shell, edit, browser, file search	Запустить тесты или изменить файл	Sandbox и approvals конкретного клиента
MCP server	Локальный процесс или remote service с tools/resources/prompts	Прочитать issue, запросить БД, создать задачу	Код сервера, его auth/ACL и downstream API
Connector или app	Готовое подключение внешнего продукта, часто поверх remote MCP	Google Drive, GitHub, Slack	OAuth, workspace policy, UI и provider account
Plugin	Установочный пакет из одного или нескольких компонентов	Skill + MCP + hooks + optional UI	Publisher, manifest, dependencies и updates
Skill	SKILL.md с инструкциями, references, templates и иногда scripts	Проверить PR по внутреннему чек-листу	Prompt-level guidance и запускаемые scripts
Rule, AGENTS.md, CLAUDE.md	Постоянная, файловая или условная инструкция	«Не менять generated files»	Модель может интерпретировать конфликт; это не ACL
IDE extension	Расширение редактора или клиентская поверхность	Регистрация server через extension API	Код extension, publisher, auto-update, host permissions

У OpenAI plugin может объединять skills, connectors и MCP-backed tools. У Claude Code plugin также упаковывает agents, hooks, LSP servers и monitors. Cursor поддерживает переносимые Agent Plugins с skills и MCP, а расширенный Cursor Plugin добавляет rules, agents, commands, hooks и variables. Antigravity называет plugin namespaced bundle из skills, rules, MCP и hooks.

Как выглядит путь одного вызова

Упрощенная архитектура отделяет инструкции от исполняемых возможностей:

Запрос пользователя
       │
       ▼
Host: ChatGPT/Codex, Claude Code, Cursor или Antigravity
       │
       ├── persistent context: rules / AGENTS.md / CLAUDE.md
       ├── on-demand workflow: skill
       └── каталог возможностей
             ├── native tools
             └── MCP tools: server-id + tool name + description + schemas
                         │
                         ▼
                 выбор модели или явный вызов
                         │
                         ▼
       policy gate: enabled? allow/deny? approval? sandbox/network?
                         │
             ┌───────────┴───────────┐
             ▼                       ▼
       local stdio              remote HTTP
       child process        OAuth / bearer / headers
             │                       │
             └───────────┬───────────┘
                         ▼
              server-side auth и ACL
                         │
                         ▼
              API / база / файловая система
                         │
                         ▼
       result → schema check → журнал → ответ модели

Модель обычно влияет на выбор tool и аргументы. Host применяет конфигурацию и approval policy. MCP server обязан повторно проверить аргументы, identity, tenant и разрешение на действие. Если один слой считает вызов безопасным, остальные все равно сохраняют свою ответственность.

Вторая схема показывает, где чаще всего возникает ошибка:

DISCOVER → DESCRIBE → SELECT → AUTHORIZE → EXECUTE → VALIDATE → OBSERVE
   scope     metadata    model      host +      transport    schema       logs
   paths     schemas     or user    backend     + auth       + meaning    + audit

Матрица конфигурации и подключения

Одна торговая марка может включать несколько surfaces. Особенно важно не объединять в одну строку ChatGPT web, локальный Codex host и Codex IDE extension: наборы plugins и local MCP у них различаются.

Продукт	Config и scope	Transport и auth	Enable/disable и lifecycle	Логи и диагностика
ChatGPT/Codex	ChatGPT web получает remote tools через installed plugins и не читает local Codex config. ChatGPT desktop, Codex CLI и IDE extension одного host делят ~/.codex/config.toml; trusted project может добавить .codex/config.toml. Plugin-provided server управляется в plugins.<plugin>.mcp_servers	Local host: stdio и Streamable HTTP. HTTP: bearer env, OAuth, CIMD/DCR, env/static headers и local header helper; для доверенных first-party origins возможна ChatGPT session auth. Hosted plugin capabilities могут отличаться	enabled, required, enabled_tools, disabled_tools; deny применяется после allow. Есть startup/tool timeouts и optional startup grace. В Codex CLI после установки plugin нужно начать новую session; Codex IDE extension plugins не поддерживает	/mcp, список server status, server-side logs и tool-call transcript. Единый публичный MCP audit schema и точный local log path в основных страницах не определены
Claude Code	Local и user definitions хранятся в ~/.claude.json, shared project definition — в .mcp.json. Plugin и claude.ai connectors добавляют еще два источника	Remote HTTP рекомендован; также есть SSE, stdio и WebSocket. HTTP поддерживает OAuth и headers; dynamic header helper исполняется с отдельными trust/secret rules	Server можно отключить без удаления. Plugin MCP стартует при enable; после изменения plugins нужен /reload-plugins. Transient first-connect errors повторяются до трех раз, auth/not-found требуют исправления. Долгий call может стать background task	/mcp, claude mcp list, claude mcp get, status details и connection errors. Нужно отдельно журналировать actor/tenant/args/result, если этого требует аудит
Cursor	Project config — .cursor/mcp.json, global — ~/.cursor/mcp.json; team distribution идет через dashboard/marketplace. Plugins ставятся в project или user scope	stdio, SSE, Streamable HTTP. OAuth, static OAuth client, headers и env; envFile только для stdio. Есть ${workspaceFolder}, ${userHome} и OS path interpolation	Toggle в Customize; disabled server не попадает в chat. Ошибка одного server изолирована. Team allowlist и distribution — разные настройки	Output → MCP Logs показывает initialization, tool calls и errors. В chat видны expandable arguments/results
Antigravity	Global MCP — ~/.gemini/config/mcp_config.json, workspace — .agents/mcp_config.json. Workspace plugins — .agents/plugins или _agents/plugins, global IDE plugins — ~/.gemini/config/plugins; CLI использует собственный installation path	stdio и remote Streamable HTTP/SSE; отдельные Antigravity surfaces упоминают WebSocket и SDK connections. Remote field называется serverUrl. Auth: Google ADC, OAuth/DCR или manual client, custom headers	Store и Settings дают install, enable/disable и refresh; config поддерживает disabled и disabledTools. Retry/timeout defaults публично описаны неполно	CLI /mcp показывает live status и real-time connection logs. Формат IDE audit export не установлен

Матрица выбора, namespaces и approvals

Продукт	Как появляется выбор	Namespaces и дубли	Precedence	Approvals	Что остается неизвестным
ChatGPT/Codex	Tool metadata задает intended и disallowed scenarios; skill активируется явно или по совпадению description	Server имеет config key, tool — собственное name. Публичное полное правило cross-server callable names не описано	disabled_tools после enabled_tools; explicit bearer/OAuth выше helper header. Точная duplicate precedence user/project server definitions не установлена	Per-server auto, prompt, writes, approve и per-tool override. Общие permissions/sandbox ограничивают local actions отдельно	Внутренний ranker, tie-break одинаковых tools, product-level schema deferral и единый audit contract
Claude Code	Tool search по умолчанию оставляет на старте names и server instructions, затем подгружает definitions. Skill вызывается /name или моделью	Manually configured tools используют server-qualified form; plugin tool получает mcp__plugin_<plugin>_<server>__<tool>. Plugin skills — /plugin:skill	Local > Project > User > plugin > claude.ai connector; server entry берется целиком. Skill precedence опубликован отдельно	Workspace trust для project .mcp.json; permission allow/ask/deny и managed policies. allowed-tools skill не отменяет основной permission flow	Поведение зависит от модели и endpoint: proxy, старые cloud deployments и alwaysLoad могут заменить lazy loading на upfront
Cursor	Agent видит Available Tools и может выбрать релевантный tool; пользователь может назвать tool явно. Skills — model decision или /skill	Полный cross-server namespace и tie-break в основной MCP-документации не опубликованы	Для rules: Team > Project > User с merge. Marketplace plugin с тем же именем выше local copy. Duplicate precedence project/global MCP не подтверждена в основной странице	Default approval; MCP следует Run Modes. В Auto-review allowlisted tools выполняются сразу, остальные оценивает classifier	Schema deferral/tool search, retry/timeouts и duplicate tool resolution
Antigravity	Installed tools автоматически доступны editor; skill проходит discovery по name/description и загружает полный SKILL.md при активации	Plugins namespaced. Exact callable MCP namespace и конфликт одинаковых skill/tool names не опубликованы	Permissions: Deny > Ask > Allow. Precedence global/workspace MCP definitions не установлена	mcp(server/tool), mcp(server/*), mcp(*); unconfigured MCP default Ask	MCP lazy loading, duplicate resolution, retry/timeouts, token-file protection и IDE audit fields

Коллизии имен: почему дваsearch — не мелочь

MCP specification 2026-07-28 требует уникальности tool name только внутри одного server. Два независимых сервера имеют право публиковать search. Агрегирующий client должен развести коллизию, например server prefix, причем serverInfo.name тоже не гарантированно уникален.

Для собственной платформы безопасное имя состоит из стабильного владельца, домена и действия:

github.issues.search
docs.openapi.search
crm.contacts.search

Даже если host позже преобразует его в mcp__server__tool, семантика остается различимой. Названия search, read, list и run без домена увеличивают decision surface и затрудняют policy/log analysis.

Коллизия проверяется отдельно от качества обычного prompt:

1. Подключите в тестовой среде два безвредных server с одинаковым bare name search.
2. Дайте каждому взаимоисключающее description: кодовые репозитории и продуктовая документация.
3. Выполните direct prompts, indirect prompts и negative prompts.
4. Запишите фактический callable name, выбранный server, arguments и approval.
5. Повторите тест после перестановки scopes и disable одного server.

Если официальный client не раскрывает tie-break, конфигурация не должна зависеть от предполагаемого порядка. Переименуйте tool или server key и закрепите точный namespace в policies.

Model-driven selection без мифов о внутреннем роутере

Опубликованные документы показывают только входы в решение: name, description, input schema, иногда output schema, server instructions, skill description, user prompt и доступный tool catalog. Этого достаточно для проектирования, но недостаточно для заявления «модель всегда выберет X раньше Y».

Качество selection измеряют golden prompt set:

Набор	Пример	Ожидаемый результат
Direct	«Найди issue через GitHub MCP»	Вызван точный GitHub search tool
Indirect	«Есть ли уже задача про утечку токена?»	Выбран issue search, если его description покрывает intent
Negative	«Объясни, что такое OAuth»	Внешний mutation/search не нужен, если ответа хватает в контексте
Ambiguous	«Найди документацию и связанную задачу»	Два узких reads или уточнение, но не случайный write tool
Conflict	«Найди search» при двух одноименных tools	Явная disambiguation либо подтвержденный namespace behavior

Меняйте один metadata field за итерацию. Записывайте precision — долю корректных вызовов среди сделанных — и recall — долю нужных вызовов среди prompts, где они ожидались. Положительный пример без negative set часто маскирует чрезмерно агрессивное включение tool.

Lazy loading, context cost и производительность

Полный каталог из сотен schemas может занять значительную часть контекста до первого полезного вызова. Но уменьшать проблему до числа servers тоже неверно: один database tool с огромным schema или result способен стоить больше десятка коротких read-only tools.

Claude Code наиболее явно документирует MCP Tool Search: на старте модель получает tool names и server instructions, а definitions подгружаются по потребности. alwaysLoad оставляет конкретный server eager. Поведение зависит от совместимости модели и endpoint; некоторые proxy и cloud deployments используют upfront loading. Читать полный обзор сервиса Claude Code

OpenAI и Antigravity применяют progressive disclosure к skills: сначала name/description, затем полный SKILL.md. Это не доказывает такой же механизм для MCP schemas. Cursor сообщает, что disabled server не загружается и не появляется в chat, но не публикует эквивалентный алгоритм MCP Tool Search. Эти клетки матрицы остаются unknown до live measurement. Читать полный обзор сервиса Cursor

Измеряйте четыре величины раздельно:

Метрика	Что показывает	Как проверить
Cold start	Стоимость запуска и discovery	Время от старта клиента до готовности catalog
Context footprint	Цена names, instructions и schemas	Context diagnostic до первого call и после discovery
First-call latency	Стоимость lazy lookup + connection + auth	Первый одинаковый read после чистой session
Result load	Размер данных, которые вернулись модели	Tokens/bytes, truncation, persisted file и parse time

Оптимизация идет в таком порядке: отключить нерелевантные servers; сузить tool allowlist; развести пересекающиеся capabilities; сократить descriptions без потери условий; ограничить result size; добавить pagination/filter; только затем менять timeout или отключать lazy discovery.

Approval, sandbox и authorization нельзя объединять в один флажок

Безопасность MCP состоит из независимых ворот:

Ворота	Что контролируют	Чего не гарантируют
Publisher/install trust	Можно ли вообще загрузить package/server	Безопасность следующего update и корректность backend ACL
Server enablement	Попадет ли server в каталог	Право отдельного пользователя читать конкретные records
Tool allow/deny	Какие tools доступны	Безвредность аргументов и результатов разрешенного tool
Human approval	Можно ли выполнить текущий call	Tenant isolation и отсутствие race/replay на server
Local sandbox/network	Доступ native command или stdio process к машине	Ограничения remote MCP service
MCP server auth	Кто вызывает endpoint	Разрешение downstream API и row-level access
Downstream ACL	Какие данные/действия доступны identity	Корректность выбора модели и consent UI

Правило «все write tools спрашивают» полезно, но не защищает от read tool, который выгружает private data, и не исправляет server, принимающий tenant_id из model argument. Rules и skills могут напоминать модели о процедуре; надежный запрет должен жить в host policy и backend authorization.

Prompt injection и tool poisoning

У атаки есть несколько входов:

• внешняя страница, письмо или документ содержит instruction, которую модель принимает за команду;
• вредоносный текст спрятан в tool description, server instructions, resource или prompt;
• plugin/skill включает script или hook с неожиданным действием;
• benign server после update меняет metadata или behavior — rug pull;
• один server пытается повлиять на использование tools другого server — cross-server shadowing.

Особенно опасна композиция из трех возможностей: читать private data, обрабатывать untrusted content и отправлять данные наружу. Разделите эти capabilities по servers, accounts или sessions. External-write tool должен получать минимум данных и отдельное approval. Метаданные и tool annotations нельзя считать доверенными только потому, что они синтаксически валидны.

Защита строится слоями:

• фиксируйте publisher, source, version и hash package/tool metadata;
• повторно проверяйте permissions после update descriptions, schemas или endpoint;
• показывайте пользователю server, tool, arguments и ожидаемый внешний эффект;
• применяйте allowlist destinations и restricted API scopes;
• валидируйте inputs на server независимо от модели;
• маркируйте external content как data и не позволяйте ему расширять права;
• журналируйте correlation ID, actor, tenant, tool, sanitized arguments, result status и latency;
• подтверждайте irreversible operations человеком.

Output schemas и недоверенные hints

Хороший tool возвращает не длинный рассказ, а короткий machine-readable result. outputSchema помогает проверить structuredContent, стабилизирует интеграцию и упрощает обработку ошибок. При этом schema описывает форму, но не доказывает истинность данных.

Минимальный contract для mutation полезно сделать таким:

{
  "ok": true,
  "operation_id": "opaque-id",
  "resource_id": "opaque-id",
  "status": "created",
  "retryable": false
}

Server должен валидировать input и формировать result по schema; client — проверять result, если поддерживает такую проверку. readOnlyHint, destructiveHint, idempotentHint и openWorldHint улучшают UX и approvals, но остаются hints от server. Компрометированный server может назвать mutation чтением.

Для retries особенно важны idempotency key и стабильный operation ID. Повтор create_invoice после network timeout без идемпотентности способен создать два счета, даже если client честно «повторил неудачный вызов».

Secrets и multi-tenant boundaries

Не храните API key, bearer token или client secret в version-controlled mcp.json, config.toml, plugin manifest, skill или rule. В конфиге должно оставаться только имя environment variable, ссылка на credential helper или OAuth metadata. Логи обязаны маскировать headers, query parameters, prompt fragments с PII и tool results с private data.

Для remote multi-user MCP одного OAuth недостаточно. Нужны:

• access token с audience/resource binding именно к MCP server;
• отдельная downstream identity или token exchange, без passthrough входящего token;
• tenant из проверенной identity, а не из свободного tool argument;
• row-level authorization на каждом call;
• cache key с user/tenant/scope и запрет shared private tools/list/result cache;
• привязка long-running task и state handle к actor/tenant;
• logout, revocation и account switch tests;
• аудит, в котором видны subject, tenant, scopes и policy decision.

OAuth consent пользователя не предотвращает cross-tenant leak. Он подтверждает доступ клиента, а изоляцию записей реализует server.

stdio или Streamable HTTP

Новая стабильная ревизия MCP transport 2026-07-28 сохраняет два стандартных binding: stdio и Streamable HTTP. Старые clients могут поддерживать более ранние revisions, SSE или собственные extensions, поэтому compatibility проверяют через protocol negotiation и feature tests.

Критерий	stdio	Streamable HTTP
Где работает	Child process рядом с client	Независимый local или remote service
Для кого удобен	Один разработчик, local files, private prototype	Команда, centralized auth, managed deployment, несколько clients
Secrets	Environment/credential store процесса	OAuth, bearer/custom headers, server-side secrets
Lifecycle	Client запускает и завершает process	Отдельный health, deploy, scaling и observability
Главный риск	PATH/cwd/env, arbitrary local code, stdout protocol pollution	Auth, tenant isolation, DNS/network exposure, retry/replay
Переносимость	Команда и path зависят от ОС/runtime	Endpoint переносимее, но OAuth callbacks и client fields различаются

SSE как отдельный legacy transport все еще перечисляется в Cursor, Claude Code и Antigravity. Это не делает старый config универсальным: Codex host ориентирован на stdio и Streamable HTTP, а Antigravity требует serverUrl для remote connection.

Windows, WSL и container paths

На Windows один проект может одновременно существовать в трех пространствах имен:

Windows host:    C:\Users\me\project
WSL process:     /mnt/c/Users/me/project
Container:       /workspace

Сначала установите, где живет client и где он запускает stdio. Затем проверяйте config home, executable, cwd, env и mounted data. Графический client на Windows не обязан читать ~/.cursor или ~/.claude внутри WSL. WSL client не обязан видеть Windows PATH. Container localhost указывает на сам container, а не на Windows host.

Проверка	Windows native	WSL	Container
Config home	%USERPROFILE% конкретного client	Linux $HOME процесса	Home внутри image/volume
Executable	.exe, PowerShell/cmd rules	Linux binary и shell profile	Binary должен быть в image
Project path	C:\...	/mnt/c/... или Linux filesystem	Mounted path, например /workspace
Loopback server	127.0.0.1 host	Может потребоваться WSL-host routing	localhost только container; нужен service name или host gateway
OAuth callback	Проверить Windows firewall и выбранный port	Проверить browser→WSL listener	Обычно callback принимает host/client, не app container
Docker socket/files	Windows Docker Desktop rules	WSL integration и permissions	Явные mounts и минимальные capabilities

Не переносите абсолютные paths между средами. Используйте client-supported variables, per-platform adapters или wrapper command. В team manifest храните logical resource project-root/tools/server, а platform-specific generator подставляет реальный путь.

Переносимый manifest как source of truth

Один и тот же mcp.json нельзя без проверки копировать между четырьмя продуктами: различаются remote field names, scopes, auth objects, plugin manifests и approval controls. Решение — vendor-neutral policy manifest, из которого генерируются client adapters.

Это проектный пример, а не готовый config какого-либо клиента:

schemaVersion: agent-routing/v1
integrationId: acme.issue-search
owner: platform-team
source:
  repository: https://example.com/acme/issue-mcp
  version: 2.3.1
  digest: sha256:REPLACE_WITH_PINNED_DIGEST

capability:
  purpose: Search issues in the current tenant
  dataClass: internal
  tools:
    allow: [issues.search, issues.get]
    deny: [issues.delete, admin.*]

transports:
  preferred: streamable-http
  http:
    endpointEnv: ACME_MCP_URL
    auth: oauth
    scopes: [issues.read]
  stdio:
    commandByPlatform:
      windows: [node.exe, tools/issue-mcp/server.js]
      linux: [node, tools/issue-mcp/server.js]
    envNames: [ACME_MCP_TOKEN]

policy:
  defaultApproval: prompt
  writesApproval: always
  startupTimeoutSeconds: 10
  toolTimeoutSeconds: 45
  maxResultBytes: 200000
  requireOutputSchema: true

isolation:
  tenantFrom: verified-token
  cachePartition: [tenant, subject, scopes]
  allowNetwork: [api.example.com]

observability:
  log: [correlationId, subjectId, tenantId, tool, latencyMs, status]
  redact: [authorization, cookies, token, secret, pii]

Adapter для Codex создает TOML, для Claude Code — нужный scope в .mcp.json или ~/.claude.json, для Cursor — .cursor/mcp.json, для Antigravity — mcp_config.json с serverUrl. Generator не должен записывать secret values: только env names, credential references и public OAuth metadata.

Для переносимых skills подходят Agent Skills, а для bundles skills+MCP — Agent Plugins. Cursor прямо поддерживает оба направления; другие clients могут добавлять свои manifest fields. Переносимость означает общий смысл и source files, а не побайтово одинаковую установку.

Безопасный test plan без рабочей конфигурации

Тестируйте в disposable account, пустом tenant и isolated repository. Внешние writes замените mock endpoint или явно созданными test records.

1. Inventory. Зафиксируйте client surface/version, config sources, plugins, extensions, servers и exact callable tools. Ничего не вызывайте.
2. Provenance. Проверьте publisher, repository, pinned version/digest, dependencies, scripts, hooks и update channel.
3. Discovery. Запустите client с одним read-only server и убедитесь, что видны ожидаемые tools, schemas и source scope.
4. Collision. Добавьте второй mock server с тем же bare search; проверьте namespace и policy matching.
5. Selection. Прогоните direct, indirect, negative, ambiguous и conflict prompts несколько раз.
6. Approval. Для read, write, destructive и external-write tools проверьте default и per-tool behavior. Подложите ложный readOnlyHint и убедитесь, что backend не доверяет ему.
7. Injection. Поместите harmless canary instruction в tool description и external document. Тест считается пройденным, если canary не расширяет права и не уходит в другой server.
8. Auth. Проверьте expired token, 401, 403 insufficient scope, revoke, logout и account switch.
9. Tenant isolation. Создайте tenants A/B; попытка получить B из session A должна дать deny независимо от model arguments и cache.
10. Lifecycle. Проверьте slow startup, crash, reconnect, catalog change, update, disable, uninstall и удаление credentials/processes.
11. Retry. Вызовите timeout до и после server commit point. Mutation не должна дублироваться благодаря idempotency key.
12. Result limits. Верните malformed schema, 100 KB, 1 MB и paginated output; зафиксируйте validation, truncation и context impact.
13. Platform matrix. Повторите минимальный smoke test на Windows native, WSL и container с явной картой paths/env/loopback.
14. Audit. Убедитесь, что logs содержат actor/tenant/tool/status/latency, но не token, PII и полный private result.

Troubleshooting: от симптома к слою

Симптом	Сначала проверить	Затем проверить
Server не виден	Active surface, global/project path, plugin enabled, restart/reload	Workspace trust, admin allowlist, syntax и duplicate scope
Server виден, tool нет	Tool allow/deny, disabledTools, schema validity, auth-dependent tools/list	Lazy discovery, cached catalog, protocol version и list-changed support
Выбирается не тот tool	Names/descriptions, одинаковые verbs, negative prompts	Namespace collision, scope override и stale metadata cache
Approval не появляется	Run/permission mode, allowlist, per-tool override	Tool annotations, headless/non-interactive differences и backend audit
OAuth зациклился	Exact endpoint, callback, issuer/audience, client registration	Stored token/client, clock, scopes, proxy headers и account switch
stdio не стартует	Exact executable, -- separator где нужен, cwd, env, stdout cleanliness	Client process OS, PATH, WSL/container mounts и startup timeout
Работает на Windows, не работает в WSL	Какой client читает какой home/config	Linux path, env inheritance, loopback и Docker integration
Медленно до первого call	Число active definitions, eager/lazy mode, slow optional servers	Duplicate tools, long server instructions и discovery cache
Медленно после call	Result bytes/tokens, pagination, output schema, embedded files	Network/API latency, retry и model parsing cost
Plugin обновлен, поведение старое	Session/reload requirement, marketplace/local precedence	Pinned version, cache, old process и unchanged metadata hash
Один server сломал весь запрос	Invalid tool schema или global request catalog	Isolate server, disable broken tool и проверить client validation

Не начинайте с увеличения timeout. Сначала определите, где зависание: process startup, network connect, OAuth, tool execution, result serialization или model continuation.

Как выбрать подход для команды

Если агенту нужны только повторяемые инструкции по уже доступным файлам и native tools, начните со skill. Если правило должно постоянно направлять работу в конкретном repository, используйте project rule, AGENTS.md или CLAUDE.md, но продублируйте критические запреты детерминированными controls.

MCP нужен, когда агент должен сам получить live data или выполнить внешнее действие. Для одного разработчика и local data уместен узкий stdio server. Для команды и нескольких clients удобнее remote Streamable HTTP с per-user OAuth, tenant isolation, health checks и centralized audit.

Plugin полезен, когда нужно распространять проверенный комплект: skill, MCP connection, hooks и дополнительные компоненты. Перед установкой plugin проверяйте весь package, потому что инструкция, server, hook и extension имеют разные права и разные способы обновления.

Вывод

Качественный роутинг MCP строится не вокруг бренда клиента, а вокруг явных контрактов. Стабильные server/tool identifiers снижают коллизии; metadata и golden prompts улучшают model selection; allowlists и approvals ограничивают host; OAuth и backend ACL защищают пользователя и tenant; schemas, timeouts, idempotency и logs делают вызовы проверяемыми.

Claude Code наиболее подробно раскрывает precedence и lazy MCP Tool Search. OpenAI дает гранулярные per-server/per-tool policies и четко разделяет hosted plugins и local Codex host. Cursor объединяет plugins, skills, rules и MCP в Customize и показывает MCP Logs. Antigravity публикует точные workspace/global paths, serverUrl, Google/OAuth auth и единую permission grammar. Там, где cross-server collision, MCP deferral или retry semantics не опубликованы, безопасный ответ — unknown плюс воспроизводимый test, а не догадка о внутреннем роутере.