agent-interop

Agent interop — the protocols an agent speaks outside its own process

agent-orchestrator builds the loop. agent-evals proves it behaves. This skill covers everything the loop reaches that is not in its process: a tool server, a peer agent, a registry, and the gateway between them.

Triggers

"MCP client", "agent interoperability", "server.json", "agentgateway", "tool federation", "интероперабельность агентов", "реестр MCP", "delegation token", "токен делегирования".

Rule zero — a protocol claim without a date is a guess

Every one of these specifications moved in the twelve months before 2026-08-13 — the date every reference below was read — and each moved in a way that silently breaks code written against the previous revision. Concretely, and each one measured on that date against the live specification rather than recalled:

• MCP replaced the initialize handshake with server/discover and made the protocol

stateless; a client that opens with initialize is speaking a revision that is on its way out.

• MCP deprecated `sampling`, `roots` and `logging` — three things an older model will

reach for first, because for a year they were the interesting part of the client side.

• A2A renamed its wire surface between v0.x and v1.0, and SDKs and blog posts still

documented v0.3 as of 2026-08-13.

• agentgateway deprecated `binds` in favour of gateways — while its own overview page

still introduced binds as a core concept as of 2026-08-13.

So: every reference in this skill opens with a `Spec pinned:` line, and This pack's repository validator fails the build without one. That is a mechanical check, not an aspiration — the class of error it prevents is the one where prose reads as current because nothing on the page says otherwise.

Before you write wire-level code, fetch the spec. These references tell you what to look for and what changed; they are not a substitute for the document. Read the pinned revision, then check whether a newer one exists. Every entry in the link map below is fetchable.

Which protocol answers which question

The one-line rule between the two big ones. MCP connects a model to a capability you control the shape of; A2A connects you to a peer whose insides you deliberately cannot see. The official framing is exact and worth keeping: "A2A is about agents partnering on tasks, while MCP is more about agents using capabilities." Real systems run both — an A2A server whose internals speak MCP — and that is the recommended architecture, not a compromise.

The dispatch criterion is WHAT the other side is, not how long it runs. MCP = a CAPABILITY / tool you control the shape of; A2A = an AUTONOMOUS PEER whose outcome you delegate and whose insides you cannot see. Duration is a SECOND question, and it is about a Tasks CAPABILITY, not a protocol. A long-running FIXED job you own — a ten-minute export, a batch transform — is MCP with the Tasks extension (a durable handle: poll, supply input mid-flight, retrieve later; see references/mcp.md), NOT A2A. So decide by the routing set, and never by the word long-running:

• long-running FIXED export → **MCP Tasks, when the client/SDK negotiates that

extension**;

• autonomous outsourced negotiation → A2A (you delegate the outcome, not

the steps);

• Tasks unsupported by the reached client/SDK → an explicit fallback

(chunk the job, a job id the caller polls with a plain tools/call, or a webhook) — reaching for A2A because Tasks is absent is picking a protocol to dodge a missing extension.

Check the client's ACTUALLY-negotiated extensions before building on Tasks; inventing a task lifecycle on top of tools/call when Tasks IS available is re-implementing the extension, and reaching for A2A when Tasks is merely unsupported is the mis-route this audit closes. Publishing an agent card for something that is one HTTP call with a JSON schema is still the MCP direction.

References

Each file opens with its own Load this when line and its revision stamp. This table is an index; the trigger lives in the file, so the two cannot drift apart.

Boundaries — what this skill is not

Against `make-skill`. make-skill owns the skill author's view: whether a job wants a skill or a server at all, declaring a server dependency in compatibility, and the fact that tool names differ per host (mcp__<server>__<tool> in Claude Code, mcp__plugin_<plugin>_<server>__<tool> for a plugin's own server). This skill owns the wire. If the question is "what does the protocol say", it is here; if it is "how does my skill declare that it needs one", it is there. The protocol is described in exactly one of the two places, and this is it.

Against the Fabric adapter and Observatory skills. Where an agent or service must join a Fabric estate, the HOW is theirs: fabric-agent-adapter:creating-fabric-agents, fabric-agent-adapter:adapting-projects-to-fabric and fabric-agent-adapter:building-fabric-services (the descriptor, the hub, fabric-service/0.1); credentials an agent uses go through observatory-log:handling-secrets (named vault slots, never a value). This skill keeps the protocol they speak — MCP, A2A, the gateway, delegation — and points to them rather than restating them.

Against `agent-orchestrator`. That skill routes between model providers and manages the loop's own context. This one routes between processes. They meet at exactly one point: an orchestrator that federates many MCP servers is subject to references/mcp-scale.md, and one that fronts them with a proxy is subject to references/gateway.md.

Against `agent-orchestrator/references/governance.md`. That file decides whether a boundary may be crossed and what an audit row must carry to prove a control was applied. This skill describes how the crossing is spoken. Permission there, protocol here.

Not covered at all: designing the tool set of one server (what tools, what schemas, what descriptions — that is a design problem, and Anthropic's mcp-server-dev plugin is built for it); prompt wording; a single LLM call in a script.

The neighbourhood — one verdict each

Named so an agent stops guessing, with the verdict stated rather than implied. Verdicts as of 2026-08-13, the day this skill's references were pinned — this ground moves, so re-verify anything marked watch before building on it.

The link map — where to go and read

Nothing here is summarised well enough to build against. These are the documents.

Fetch the `llms.txt` first when you are an agent. Both modelcontextprotocol.io and agentgateway.dev publish one, and both are versioned per docs release — which is how you find the page that exists rather than the page you remember.

Checklist — shipping anything that speaks these protocols

• [ ] The revision you build against is written down — in compatibility, a constant, or a README line
• [ ] You read the deprecation register before using a client feature
• [ ] Version mismatch has a handled path, not a crash
• [ ] Tool output is treated as untrusted input, including output from your own servers
• [ ] Nothing secret is requested through an elicitation form — that is URL mode's job
• [ ] Long-running work uses a durable handle rather than a held connection
• [ ] If you federate: name collisions are resolved deliberately, not by load order
• [ ] If you publish: the namespace is one you can prove you own
• [ ] Authorization is enforced per hop, not only at the entrance