Agent Skills vs MCP: інструкції чи runtime-інтеграція для AI-агента

Agent Skill — це переносима папка з обов'язковим SKILL.md та опційними scripts, references і assets. Назва й description допомагають клієнту знайти релевантний skill, а повні інструкції та допоміжні файли завантажуються за потреби. Обирайте Skill, коли треба кодувати повторюваний метод: як провести review, які перевірки виконати, які артефакти створити й коли зупинитися.

MCP — протокол між AI-host і server, який робить доступними runtime primitives на кшталт tools, resources і prompts. Обирайте MCP, коли агенту треба виявити або викликати зовнішню capability, прочитати актуальні дані чи працювати через окремо розгорнуту інтеграцію. У production ці шари часто доповнюють один одного: Skill описує процедуру, а MCP надає дозволені операції та дані.

• Повторювана інструкція, checklist або шаблон → Agent Skill.
• Зовнішній tool, live data чи незалежний connector → MCP.
• Процедура з інтеграцією → Skill посилається на дозволений MCP tool.
• Business authority → окрема policy й server-side authorization, не Skill і не MCP самі по собі.

Skill format визначає packaging і progressive disclosure контексту, але не стандартизує model API, мережевий transport, authentication, sandbox або tool-call lifecycle. MCP стандартизує взаємодію host-server і capability discovery, але не пояснює доменний процес цілком і не гарантує, що модель обере правильний tool. Скрипт усередині skill і tool на MCP server можуть виконувати схожу команду, проте мають різні deployment, trust і audit boundaries.

Розкладіть систему на чотири контракти: instruction contract каже, як виконувати задачу; capability contract описує input, output і помилки операції; execution contract визначає sandbox, network, timeout та idempotency; authority contract вирішує, хто може діяти над яким object. Skill переважно володіє першим, MCP — інтерфейсом другого, а application і target system мусять володіти останніми двома.

Agent Skills спочатку відкривають короткі metadata, потім SKILL.md і лише після посилання — конкретні references або scripts. Така поетапність зменшує початковий context footprint. Google також описує skills як спосіб не завантажувати великий каталог tool descriptions одразу. Але погана description може не активувати потрібний skill або активувати його для чужої задачі, а суперечливі інструкції можуть погіршити результат.

MCP discovery теж можна звужувати за stage, role і task. Не публікуйте сотні майже однакових tools тільки тому, що protocol це дозволяє. На discovery кроці дайте read-only search, після вибору record — вузьке читання, а write capability відкрийте лише після policy check. Вимірюйте correct activation, correct-tool selection, зайві завантаження, token cost і verified outcome, а не лише розмір каталогу.

Community або vendor skill може містити команди, scripts, посилання й приховані припущення про credentials. MCP server може змінити tool description, schema, returned content або effective side effect без зміни agent prompt. Перед допуском зафіксуйте source, owner, license, reviewed commit або digest, supported clients, requested tools, network destinations, data classes, secrets path і expiry. Не встановлюйте пакет лише за популярністю каталогу.

Застосуйте окремі trust tiers: unreviewed skills працюють без execution або лише в disposable sandbox; reviewed read-only skills отримують мінімальні sources; side-effecting workflow потребує pinned dependency, egress policy, secret isolation, human approval і postcondition. Текст із web, email, document чи tool result не може переписати allowlist або запросити нові credentials. MCP connection і allowed-tools hint у metadata не є доказом authorization.

Відкритий формат робить skill придатним до перенесення між сумісними clients, але clients можуть відрізнятися discovery paths, supported metadata, tool naming, sandbox, filesystem, shell, approval UX і context compaction. Створіть portability manifest: skill digest, required files, optional assets, expected tools, environment assumptions, forbidden effects, fixtures і supported client/version. Unknown capability має спричинити явну відмову або documented fallback.

Запустіть той самий eval corpus щонайменше у двох цільових harnesses: позитивний trigger, близький негативний trigger, missing reference, unavailable MCP server, malicious document instruction, schema drift і timeout після можливої дії. Порівняйте не стиль відповіді, а terminal artifact, trajectory, tool arguments, policy decisions і authoritative final state. Однаковий SKILL.md без однакових outcomes є синтаксичною, а не операційною переносимістю.

Безпечний composite flow починається з task contract. Client активує versioned Skill, читає лише потрібні references і формує candidate plan. Policy layer перевіряє actor, data class, stage та risk tier і публікує мінімальний MCP allowlist. MCP server валідовує typed arguments та автентифікує workload, а target adapter повторно авторизує object/action, виконує idempotent operation і повертає receipt з authoritative state.

Не ховайте business rules тільки в SKILL.md: модель може пропустити або неправильно інтерпретувати текст. Не дублюйте їх у кожному MCP connector: центральний domain service має лишатися source of truth. Skill може пояснювати порядок і escalation, MCP schema — допустиму форму запиту, policy engine — дозвіл, domain API — інваріанти. Такий поділ дозволяє оновити процедуру без непомітного розширення прав.

• Discover → metadata й task match.
• Load → pinned SKILL.md та потрібні references.
• Authorize → stage-specific capability allowlist.
• Execute → MCP call через typed adapter та least privilege.
• Verify → system-of-record postcondition, trace і human acceptance.

Eval set має три осі. Instruction axis перевіряє trigger precision, constraint retention і якість артефакту. Integration axis перевіряє tool selection, arguments, schema/version drift, unavailable server і oversized result. Authority axis перевіряє denied object, revoked identity, prompt injection, duplicate request, partial write та approval bypass. Golden final answer без trajectory evidence не доводить безпечний workflow.

Rollout: local lint і static review; isolated replay без credentials; sandbox із fake MCP server; read-only canary; shadow decision; bounded write з approval; поступове розширення. Promotion gate фіксує skill digest, server/schema version, model/harness, policy version, eval result і rollback owner. Після зміни будь-якого компонента запускайте affected slices, а не припускайте, що Markdown залишив поведінку незмінною.

Registry entry для production skill містить owner, mission, consumers, source, digest/version, dependencies, MCP servers/tools, data classes, authority tier, eval suite, last review, status і retirement date. Для MCP додайте server identity, transport, auth method, schemas, deployment owner, SLO та incident contact. Логуйте activation decision, loaded file references, tool name/schema version, policy verdict, redacted arguments, result status і receipt reference без копіювання secrets або зайвих personal data.

Rollback skill повертає known-good digest або вимикає discovery entry. Rollback MCP вимикає конкретний tool/server route, rotates credentials за потреби й повертає попередню schema/deployment. Уже виконані effects не зникають: reconciliation знаходить unknown або partial operations і відновлює domain state через компенсацію чи manual queue. Emergency kill switch має працювати незалежно від здатності моделі прочитати нову інструкцію.

У composite workflow немає однієї версії. Skill має content digest або immutable release і, на hosted surface, окремий default-version pointer. MCP session домовляється про protocol version та capabilities під час initialization, а конкретний server deployment володіє schemas і поведінкою tools. Оновлення default Skill version не перевідкриває вже активну MCP session; restart server не доводить, що агент завантажив нові інструкції. Тому label `v3` без координат обох шарів непридатний для incident review.

Зберігайте composite release tuple: `skillId`, content digest, selected/default version, client і model/harness revision, MCP protocol version, server identity та deployment, negotiated capabilities, tool-list fingerprint і policy revision. Додайте час resolution: default pointer може змінитися між плануванням і виконанням. Для відтворення потрібна фактично resolved version, а не лише те, що було latest під час розслідування.

Compatibility matrix має перевіряти щонайменше `known skill + known server`, `new skill + known server`, `known skill + new server` і `new skill + new server`. Це відокремлює instruction regression від integration regression. Якщо змінюються обидві осі одночасно, невдалий golden outcome не показує власника дефекту, а rollback одного шару може залишити несумісну пару.

• Skill coordinate → immutable content digest і фактично resolved version.
• Client coordinate → harness, model і activation policy revision.
• MCP coordinate → protocol, server deployment, capabilities і tool-list fingerprint.
• Authority coordinate → identity, policy revision, approval scope та expiry.
• Outcome coordinate → receipt, authoritative state і reconciliation verdict.

Agent Skills specification дозволяє optional `allowed-tools`, але позначає поле experimental і попереджає, що підтримка різниться між implementations. Сприймайте його як portability hint, а не grant. Фактичний набір формується перетином client support, MCP-negotiated capabilities, поточного tool catalog, workspace або user entitlement, authenticated scopes, application policy, object-level authorization і stage gate. Інструкція може просити tool, якого session не negotiated; catalog може показати tool, який actor не має права застосувати до цього object.

Перед side effect побудуйте redacted effective-capability snapshot: requested operation, discovered tool і schema version, negotiated support, effective identity, granted scopes, object/stage policy, confirmation requirement та expiry. Результат `deny` або `unavailable` має бути нормальним terminal state з fallback, а не приводом шукати ширший tool, інший MCP server чи credential. Не копіюйте access token або sensitive arguments у trace.

Окремо тестуйте list drift. MCP capability negotiation може повідомити підтримку `tools` і `listChanged`, але це не означає, що конкретна назва та schema стабільні всю session. Після list-change notification або reconnect invalidate cached selection, порівняйте fingerprint, повторіть policy binding і не replay-те старі arguments автоматично. Для read-only report допустимий graceful degradation; для write зміна catalog після approval анулює approval envelope.

Release Skill і MCP server розділяйте. Спочатку зафіксуйте baseline tuple та replay corpus, потім змініть одну вісь і запустіть contract, denial та recovery fixtures. Для Skill update перевірте activation precision, loaded references, artifact і tool trajectory зі старим server. Для MCP update залиште known-good Skill та перевірте initialization, capability negotiation, schema diff, auth failures, timeout і postcondition. Лише після двох canary переходьте до combined tuple.

In-flight sessions не переводьте мовчки на новий tuple. Позначте їх resolved coordinates, дайте read-only run завершитися або drain, а approval для pending write прив'яжіть до exact tool schema і policy revision. Якщо reconnect домовився про інший protocol чи catalog, створіть новий plan та approval. Default-version pointer і server traffic shift змінюйте окремими audited кроками з owner, window, acceptance gate та abort threshold.

Rollback proof складається з трьох частин: pointer або discovery повернуто на known-good Skill; нові MCP sessions бачать known-good deployment і expected capabilities; усі unknown/partial external effects reconciled у system of record. Вимкнення Skill не закриває вже відкриту server session, а rollback server не скасовує виконану дію. Після incident додайте мінімізований fixture до permanent corpus і зафіксуйте, яка coordinate та контроль не спрацювали.

• Baseline → freeze composite tuple, fixtures і authoritative expected state.
• Canary A → new Skill against known-good MCP deployment.
• Canary B → known-good Skill against new MCP deployment.
• Promote → combined tuple only after denial and recovery slices pass.
• Rollback → restore discovery plus server path, then reconcile effects.