18 MCP and A2A: Transport and Delegation Boundaries
Part V · Open ecosystem and validation
Architecture baseline: MCP 2025-11-25 · A2A 1.0.0 · source review 2026-10-07 · no reference implementation claim
An MCP server exposes contextual capabilities. An A2A participant accepts delegated work. Both cross a trust boundary, but they do not have the same lifecycle, authority, identity, cancellation, or evidence obligations—and neither is a packaged skill.
Capability transport invokes or reads a bounded remote capability under a host-owned task. Delegation asks another agent to own some task progression. A skill remains non-executable procedure inside the current agent. Similar JSON does not collapse these responsibilities.
18.1 Four boundaries, not one “agent stack”
current application
|-- local tool port ----> compiled local executor
|-- MCP client ---------> authorized MCP server/session
|-- A2A client ---------> remote agent task/artifact lifecycle
`-- skill loader -------> reviewed non-executable procedure| Boundary | Primary unit | Lifecycle owner | Typical result | Authority question |
|---|---|---|---|---|
| Local tool | Correlated call | Current application | Typed result | May this executor run now? |
| MCP | Resource/prompt/tool operation | Host plus negotiated client/server session | Protocol content/result | May this server and capability receive this context? |
| A2A | Message/task | Delegating application plus remote agent | Status, messages, artifacts | May this agent own and advance this delegated work? |
| Skill | Reviewed text/resource | Current application | Non-executable guidance | May this procedure enter context? |
The reference implements local tools and one static skill package. It does not implement MCP or A2A. This chapter specifies the admission boundary required before a future implementation can claim compatibility.
18.2 MCP’s purpose and lifecycle
MCP defines host, client, and server roles over a structured protocol, with initialization/version agreement and capability negotiation before ordinary operation (“Model Context Protocol Specification 2025-11-25,” n.d.; “Model Context Protocol 2025-11-25,” n.d.). Depending on negotiated capabilities, a server can expose tools, resources, prompts, and related lifecycle notifications.
A safe host lifecycle is broader than “connect and list tools”:
trusted configuration selects destination/credential
→ transport connection
→ initialize and negotiate protocol/capabilities
→ authorize advertised operations against local policy
→ expose an admitted projection to the coordinator/user
→ invoke/read under per-operation limits
→ validate results and notifications
→ close, cancel, or reconcile session stateInitialization can establish protocol compatibility and peer-advertised features. It cannot decide whether the peer is trusted, which tenant may use it, which data may be released, or whether advertised tools are semantically suitable.
18.2.1 Discovery is inventory, not permission
An MCP tools/list or resources/list response describes what the server advertises. The host still owns:
- destination and server identity;
- credential and tenant binding;
- admitted capability names and versions;
- schema and result-size profile;
- model visibility;
- per-call authorization and approval;
- released context and source classes;
- rate, deadline, and concurrency budgets; and
- retention and audit policy.
The model cannot add an MCP server by emitting a URL, package, command, or configuration object. Retrieved content cannot request a new server. A capability newly appearing after a list-change notification remains unapproved until local policy admits it.
18.2.2 Tools, resources, and prompts remain distinct
MCP tool invocation can fit behind the application’s generic tool port, but remote execution adds destination, credential, session, transport, and provenance fields. MCP resources expose content or references under server-defined identity; they are not automatically trusted evidence. MCP prompts are reusable server-provided templates; loading one cannot grant tool authority or become a higher-priority instruction by virtue of transport.
A host should project only the minimum semantics needed by the coordinator. It must not flatten all server content into undifferentiated prompt text or represent every resource as a local file.
18.3 MCP admission record
A production admission record binds:
- reviewed server identity and deployment alias;
- transport class and trusted endpoint selected outside model content;
- credential owner, scope, expiry, and recipient;
- negotiated protocol revision and capability set;
- admitted tools/resources/prompts and schema digests;
- principal, tenant, purpose, and data-release classes;
- argument, result, pagination, subscription, and notification limits;
- cancellation, timeout, reconnect, and unknown-effect behavior;
- safe diagnostics and telemetry labels; and
- result/provenance validation policy.
A model-facing name should map to this record, not to a caller-provided endpoint. Schema changes invalidate prior admission evidence. Protocol negotiation is necessary but cannot substitute for that record.
18.4 A2A’s purpose and lifecycle
A2A represents interaction with another agent through discoverable capabilities, messages, tasks, statuses, and artifacts (“Agent2Agent Protocol Specification 1.0.0,” n.d.). A delegated participant can plan within an admitted scope, request additional information, progress asynchronously, and return more than one artifact.
A safe delegation lifecycle includes:
trusted catalog selects remote agent
→ inspect/admit advertised capability
→ create local delegation intent
→ release minimum task context
→ correlate local and remote task identities
→ observe status/messages/artifacts
→ answer input requests under fresh policy
→ cancel, complete, fail, or reconcile
→ admit returned artifacts/evidence locallyThis is not just a slow tool call. A remote agent can own intermediate progression and maintain its own state. Flattening the exchange into one execute() result loses who owns the task, whether input is pending, which artifacts exist, and what cancellation means.
18.4.2 Remote artifacts need local admission
Returned A2A artifacts have remote identity and provenance. Before they enter local context, storage, tools, or publication, validate:
- expected task and remote agent identity;
- media type, size, count, and complete transfer;
- digest/signature when the contract provides one;
- parser profile and active-content policy;
- source/evidence labels;
- retention and deletion; and
- whether the artifact is an assertion, derivation, or verified result.
A polished remote presentation remains untrusted bytes. A remote citation is not automatically an admitted local source relation.
18.6 Identity and confused-deputy risk
Transport authentication can establish a peer or credential holder. It does not prove that a requested action is authorized for the current principal. Both integrations can become confused deputies when model or retrieved text selects a recipient, requests broader context, or induces a privileged downstream operation.
Controls include:
- static deployment aliases and authenticated discovery;
- tenant/principal-bound grants;
- separate least-privilege credentials;
- task-scoped released context;
- explicit data-recipient disclosure;
- no arbitrary headers, endpoints, packages, or commands;
- bounded server/agent redirects and reconnects;
- artifact/source admission on return; and
- audit records naming requester and recipient.
Prompt text, remote descriptions, and server-returned prompts never become grants.
18.7 Delegation boundaries
An A2A grant should state:
- remote agent identity and admitted capability revision;
- task purpose and allowed planning latitude;
- maximum released sources and fields;
- permitted tools/recipients, if the remote contract exposes them;
- cost, deadline, attempt, and artifact budgets;
- whether the agent may ask for more input;
- which statuses are terminal;
- cancellation and status-lookup semantics;
- artifact types and publication rules; and
- conditions for local acceptance.
The local application does not regain semantic control merely because it can cancel. It must evaluate remote output and preserve that the work was delegated.
18.8 Data recipients and disclosure
MCP and A2A introduce explicit recipients beyond the coordinator. A record should identify:
- peer organization/service class;
- deployment/region where relevant;
- credential owner;
- exact context released;
- subrecipient/tool behavior known to the contract;
- retention/storage mode;
- telemetry/export destinations; and
- returned content/artifacts.
If the remote agent can choose further providers, the delegation policy must decide whether that is permitted and how it is disclosed. “Uses A2A” is not an adequate recipient statement.
Minimize context. An MCP tool usually needs typed arguments, not the whole transcript. A delegated agent may need a structured task and selected evidence, not every attachment and prior message.
18.9 Cancellation, errors, and reconciliation
A local cancel can race with remote execution. The correct state may be:
- cancelled before admission;
- cancellation requested, remote status unknown;
- remote cancelled with verified terminal status;
- completed before cancellation;
- failed with no effect;
- failed after possible effect; or
- disconnected while a task/artifact remains active.
MCP effectful tools need correlated receipts and operation-specific status lookup. A2A tasks need remote task identity, status reconciliation, and artifact inventory. Local timeout cannot rewrite uncertainty as “nothing happened.”
Retries require a new local attempt identity unless the remote operation supplies a verified idempotency contract. Reconnecting a session is not permission to replay prior calls or recreate a task. A remote error message cannot set local retry count, fallback recipient, or approval.
Safe public errors use bounded categories. Protected diagnostics can retain reviewed peer/status identifiers under access and cardinality controls, never unrestricted remote bodies.
18.10 Protocol translation loss
Mapping MCP or A2A into the reference’s neutral model/tool items is lossy.
Potential MCP losses include:
- negotiated capability/version state;
- resource identity and subscription/update semantics;
- rich content blocks and annotations;
- server notifications;
- transport/session metadata;
- progress/cancellation details; and
- protocol-specific error data.
Potential A2A losses include:
- task versus message identity;
- nonterminal and input-required states;
- remote planning ownership;
- asynchronous status progression;
- multiple artifacts and parts;
- push/reconnect behavior; and
- remote provenance.
Do not hide those losses behind one generic tool result. Either extend the neutral contract with typed optional envelopes and tests, or keep a protocol-specific state plane adjacent to the portable spine.
An adapter must record unsupported fields and rejection behavior. Silent dropping can turn a pending task into apparent completion or detach an artifact from its owner.
18.11 Negotiated capability is not semantic portability
A peer can correctly advertise and execute a tool while producing unsuitable results. Two MCP servers with the same tool schema can differ in data, effects, freshness, latency, and policy. Two A2A agents advertising the same capability can differ in planning, recipients, evidence, and quality.
Therefore distinguish:
- protocol compatibility;
- peer identity and currently authorized capability;
- task-profile suitability;
- observed functional evidence; and
- semantic evaluation.
A shared schema proves none of the later rows by itself. Provider-neutral model interfaces follow the same rule.
18.12 Telemetry without payload export
Future spans should use fixed operation categories such as MCP initialize/list/call/read and A2A create/status/input/cancel/artifact-admit. Peer aliases must come from the reviewed catalog, not raw endpoints. Task IDs, URLs, arguments, resource bodies, messages, artifacts, credentials, and remote errors remain excluded by default.
Cross-service trace propagation is a separate grant. Do not forward internal trace/baggage headers to an arbitrary peer. If enabled, bind trust domain and tenant, constrain baggage, and document the new correlation recipient.
18.13 Evidence and conformance limits
Before claiming MCP or A2A support, implement and test:
- pinned protocol revision and strict message validation;
- trusted destination, identity, and credential binding;
- initialization/negotiation and unsupported-feature behavior;
- discovery changes and local re-admission;
- input/result/artifact size and content limits;
- cancellation, timeout, reconnect, and unknown-effect reconciliation;
- cross-tenant and confused-deputy tests;
- hostile remote content and malformed lifecycle transitions;
- translation-loss fixtures; and
- independently reproducible interoperability with a named peer/version.
Then report the claim precisely: implemented profile, tested operations, suite/interoperability result, failures, and exclusions. Protocol resemblance or one successful exchange is not formal conformance.
The current reference has none of those implementation results. This chapter is an evidence-gated architecture specification.
18.14 Failure modes
Discovery-as-permission. Every advertised tool becomes model-visible and executable. Project through local admission and policy.
Prompt transport as authority. A server prompt is inserted at system priority. Treat it as reviewed/untrusted procedure according to local policy.
Delegation flattened to call. Input-required or active status appears as completed output. Preserve task lifecycle.
Endpoint injection. Retrieved text supplies a server or agent URL. Use trusted catalogs only.
Cancellation laundering. Disconnect triggers duplicate task creation. Reconcile remote identity and status.
Artifact laundering. Remote files bypass local ingestion because the agent was trusted. Admit every returned artifact.
Shared schema equivalence. Two peers accept the same JSON, so outputs are assumed interchangeable. Evaluate task semantics separately.
18.15 Pattern summary
Problem: Open protocols can be mistaken for automatic trust, authority, or semantic interchangeability.
Pattern: Treat MCP as admitted capability transport and A2A as admitted delegation; preserve protocol lifecycle, peer identity, recipient, local policy, cancellation, artifacts, and translation loss.
Result: Future integrations can reuse portable application boundaries without collapsing remote sessions/tasks into local skills or generic model calls.
Cost: Catalogs, credentials, state planes, reconciliation, artifact admission, interoperability evidence, and task evaluation remain necessary.
18.16 Review questions
- Can model or retrieved text select a new MCP/A2A destination?
- Which principal authorized the exact capability or delegated task?
- What context crossed the boundary, and which subrecipients are allowed?
- Can cancellation leave an unknown remote effect, task, or artifact?
- Does local state preserve remote identity and nonterminal status?
- Which protocol fields are lost in the neutral projection?
- Which evidence establishes protocol behavior, and which separately establishes task suitability?
18.17 Chapter contract
- Scope: MCP capability transport and A2A delegation purpose, lifecycle, discovery, identity, recipients, cancellation, translation, and evidence.
- Canonical claims: discovery/negotiation does not grant authority; delegation is not a long-running local tool call; shared protocol shapes do not prove semantic portability.
- Migration inputs: standards material from the former open-agent-stack chapter; skill material remains in Chapter 9.
- Evidence gates: pinned protocol tests, trusted identity/destination binding, lifecycle/reconciliation, translation-loss fixtures, and reproducible interoperability.
- Demonstration slots: withheld until an implementation passes the gate.
- Source-claim ledger: MCP 2025-11-25 and A2A 1.0.0 architecture claims are distinguished from the reference’s unimplemented status.
- Exclusions: local tool authorization belongs to Chapter 8; skills belong to Chapter 9; telemetry belongs to Chapter 16; final Open Responses classification belongs to Chapter 19.