MCP and skills
После главы вы сможете объяснить, что MCP стандартизирует transport/discovery, а skills — instructional abstraction; ни то ни другое само по себе не создаёт agent loop, policy или durability.
Механика сверена с MCP specification 2026-07-28 2026-08-30. Эта ревизия имеет stateless, self-contained requests и per-request capability negotiation. Старые материалы 2025-06-18 описывали stateful sessions и не должны применяться к новой ревизии без version pin.
Архитектура
- Host инициирует соединения, объединяет capabilities и отвечает за user/security boundary.
- Client — connector внутри host для конкретного server.
- Server предоставляет контекст и capabilities.
MCP не означает, что server «становится агентом». Он может быть простым adapter над API. Control loop остаётся в host/runtime, если только явно не спроектирована другая система.
Основные primitives
| Primitive | Смысл | Кто обычно инициирует использование |
|---|---|---|
| Tool | Выполнимая функция | Модель через host policy |
| Resource | Адресуемые данные/контекст | Приложение или пользователь |
| Prompt | Шаблон сообщений/workflow | Пользователь/приложение |
| Elicitation | Server просит дополнительный input | Server через client/host |
Последняя версия также определяет opt-in extensions, среди которых Tasks для long-running operations, Skills over MCP и MCP Apps. Extension требует явной поддержки обеих сторон; нельзя считать его частью core только потому, что один SDK реализует feature.
Источник: MCP specification 2026-07-28.
Что происходит при tool call
Концептуально MCP-вызов следует тому же пути, что локальный tool:
model proposes call
→ host resolves server/capability
→ validates schema
→ checks identity, policy and approval
→ client sends protocol request
→ server performs operation
→ host records outcome/event
→ observation returns to model
MCP заменяет custom wire integration. Он не заменяет validation, tenant isolation, idempotency, commit-time authorization и evals.
Stateless core, stateful application
В ревизии 2026-07-28 protocol request самодостаточен. Если server нужно продолжить долгую операцию, он возвращает явный handle/task, а caller передаёт его дальше. Это лучше скрытого session state для routing и replay, но application state всё равно существует:
- user/thread/run IDs;
- domain transaction;
- task handle;
- approvals;
- idempotency operation;
- audit events.
Не переносите старое правило «client держит 1:1 stateful session» на новую спецификацию.
Skills — три разных значения
Слово skill перегружено:
- Локальная instructional package: файл/папка с инструкциями, examples и scripts, которую runtime лениво догружает.
- Product feature: конкретный provider может иметь собственный формат skills.
- Skills over MCP: optional extension текущей MCP specification.
В исходном примере пользователя skill — первый вариант: system prompt содержит короткий каталог, а полный файл читается только при совпадении задачи.
initial context: name + description + trigger
selected: full instructions
needed only: referenced examples/scripts
Progressive disclosure экономит context, но создаёт новые failure modes: неверный routing, stale skill, conflicting instructions, чтение непроверенного файла как authority.
Skill, prompt, resource или tool?
| Нужен объект | Выберите | Почему |
|---|---|---|
| Инструкция «как выполнить процесс» | Skill/prompt | Управляет способом работы |
| Текущий документ/record | Resource | Это данные |
| Изменение среды | Tool | Это capability/effect |
| Долгая операция с handle | Task extension/domain job | Нужен lifecycle |
Skill не должен содержать secret или сам давать capability. Tool availability и credentials задаёт host.
Trust boundary
Naive host принимает tool description от неизвестного server как системную инструкцию. Это tool poisoning.
Mitigations:
- registry/allow-list доверенных servers;
- pin version/hash и review manifest;
- показывать provenance;
- минимальные credentials per server;
- validate destination/arguments в host;
- approval на реальный effect, а не абстрактное название;
- network egress allow-list;
- не передавать одному server данные другого без policy.
Спецификация задаёт protocol mechanics, но enforcement остаётся у implementer/host.
Варианты интеграции
| Решение | Выигрыш | Цена | Когда плохой выбор |
|---|---|---|---|
| Прямой SDK/API adapter | Мало слоёв, полный контроль | Каждая интеграция своя | Много interchangeable hosts |
| MCP server | Interoperability/discovery | Protocol/security surface | Один внутренний вызов |
| API gateway + MCP facade | Централизованные auth/limits | Ещё один operational слой | Малый prototype |
| Local skill catalog | Дешёвый lazy context | Нет общей wire semantics | Нужно shared remote discovery |
Helios и реальный аналог
Helios logistics server отдаёт get_order, policy server — cargo resources, finance server — approval-gated tools. Host не передаёт seller description finance server и не позволяет description изменить destination. Реальный аналог — IDE/support agent, подключающий CRM, issue tracker и payment API.
Лаборатория
Локальный ToolRegistry служит transport-independent contract. Запустите:
npm run test:course:pattern -- "unknown tool|schema-invalid"
Спроектируйте MCP mapping для get_order: server capability, JSON Schema, tenant identity, error mapping, timeout и host policy. Поведение domain adapter не должно измениться при замене локального вызова на MCP.
Self-check
- Где живёт loop: host или server?
- Какая версия specification реализована?
- Что относится к core, а что extension?
- Кто авторизует tool прямо перед effect?
- Может ли server увидеть данные другого server?
- Skill загружает инструкцию или выдаёт capability?
- Как long-running handle переживает restart?
Primary sources
Проверено 2026-08-30:
- MCP specification 2026-07-28
- MCP 2026-07-28 release notes
- MCP TypeScript SDK v2 docs — implementation example, не specification