MCP and A2A

1. Introduction

The subject of this paper is a regulated financial institution — a bank, an insurer or an asset manager — in the EU, the UK or Switzerland that is building more than a handful of AI applications and agents. I use the term AI factory for the organisational and technical capability that delivers AI applications repeatedly from shared, governed parts.

Integration is where that repetition usually fails. Every application that needs the data warehouse, the document store or the policy administration system has historically had its own connector, so M applications and N systems produce up to M×N integrations to build, secure and maintain. The same thing is now happening one level up. Teams build agents on different frameworks, and each agent becomes an island that others cannot find, call or supervise.

Two protocols address these two problems. MCP lets an application implement one client and a system expose one server, so that the count falls towards M+N. A2A lets an agent publish what it can do and accept work over a common format while keeping its internals private. For a factory the attraction is plain: a protocol is the point at which one project’s integration work can become something every later project uses.

My thesis is that the protocols permit that outcome and do not deliver it. They define interfaces. They do not say who may call what, who owns a server, which version is current, or what happens to a credential on its way to a system of record. A firm that adopts the protocols without supplying those answers gets M+N in the diagram and sprawl in the estate.

What is evidence and what is proposal. Section 2 is evidence: each statement about a protocol or a platform is taken from the specification or documentation page cited, opened on 10 November 2026. Sections 3 to 8 are my design proposal, with Section 7 a narrow regulatory orientation. Where a number or a duration would have been a guess, I have left it out and said so.

Versions verified against. MCP: specification revision 2026-07-28, the revision served at the specification’s “latest” address on the access date; the previous revision is 2025-11-25 [1][5]. A2A: specification version 1.0.0, shown as the latest released version; the previous version is 0.3.0 [15]. Both protocols changed materially in 2026. A reader who learned either from an earlier version should re-read Section 2.

Terms. A system of record is the authoritative system for a class of business data. A delivery team is the team that builds an application or agent for a business purpose; the platform team builds what delivery teams share. Inner source means running a shared internal codebase the way an open-source project is run: one owner, contributions from anyone by reviewed pull request. Layer names (L3, L4, the X plane) are those of AI Reference Architectures and Design Patterns: A Taxonomy for a Reuse-Driven AI Factory (Working Paper 01) and are restated where used.

2. The two protocols in brief

This section is evidence. It is deliberately short. It covers what a CIO needs in order to follow the design argument and to recognise an out-of-date description when a supplier presents one.

2.1 MCP, as of revision 2026-07-28

MCP connects hosts (the AI application), clients (one connector per server, inside the host) and servers, using JSON-RPC 2.0 messages. A server offers tools the model can ask to have executed, resources that supply data, and prompts that are reusable templates [1]. Clients list them at run time [10]. The standard transports are stdio, for a local subprocess, and Streamable HTTP, for a remote server that typically serves many clients [7][10].

This revision changed four things that the later design depends on.

• The protocol is stateless. The initialize handshake and protocol-level sessions are gone. Every request carries its protocol version and the client’s capabilities in its _meta field, and a server accepts the request or returns an error listing the versions it supports. There is no negotiation handshake [2][3][5].
• Discovery is a request. Servers must implement server/discover; clients may call it. Its result, like list results, can be cached under ttlMs and cacheScope fields [4][5].
• Servers no longer send requests to clients. A server that needs the user in the middle of a call returns a result marked input_required, and the client retries with the answer. Elicitation, a request for user input or confirmation, is the one client feature not deprecated. Change notifications are opt-in through a subscriptions/listen request [1][5].
• Roots, Sampling and Logging are deprecated. They still work, and they become eligible for removal in the first revision released on or after 28 July 2027 [5][6].

Long-running work moved to an optional Tasks extension: a server may return a durable handle that the client polls, answers and can cancel. Both sides must opt in, and the project notes that host support varies [5][11]. Authorisation is optional. Over HTTP it follows the OAuth 2.1 draft, and a server “MUST validate that access tokens were issued specifically for them as the intended audience” [8]. Section 6 returns to this.

2.2 A2A, as of version 1.0

A2A lets independent agents collaborate on what they declare and exchange, without access to each other’s internal state, memory or tools [15]. The project says plainly that it is not an agent development kit and not a sub-agent or tool-call protocol [16].

An agent publishes an Agent Card: a manifest of its interfaces, skills and security schemes, served at /.well-known/agent-card.json and optionally signed. Work is a Task with a lifecycle. Its states include working, completed, failed, canceled and rejected, and two interrupted states, input required and authentication required. Turns are Messages, outputs are Artifacts, and both are built from Parts, each holding exactly one of text, raw, url or data [15][17]. An agent answers a message directly or with a task, and the client then polls, holds a stream open or registers a webhook [15][17].

Version 1.0 separates this data model from abstract operations (SendMessage, GetTask, CancelTask and others) and from three protocol bindings: JSON-RPC, gRPC and HTTP+JSON [15]. A description of A2A as JSON-RPC over HTTP only, or one that uses method names of the form message/send, is of an earlier version. One page of the project’s own documentation still gives JSON-RPC as the payload format for all requests [17], and at least one vendor tutorial still uses the older method names [29]. Production deployments must encrypt transport, and a client authenticates under a scheme the card declares, from API key to OAuth 2.0 and mutual TLS [15].

2.3 Side by side

The A2A project puts the relationship in two sentences: MCP is vertical and deepens a single agent; A2A is horizontal and connects agents across a boundary [18].

Governance. Both protocols now sit in the Linux Foundation’s Agentic AI Foundation, by different routes. MCP was contributed by Anthropic as a founding project when the foundation was announced on 9 December 2025 [14]; its maintainers are individuals with no company seats, and its lead maintainers hold final authority [13]. A2A was developed by Google, donated to the Linux Foundation, and is maintained by a Technical Steering Committee with representatives from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow [16]. It had more than 150 supporting organisations by 9 April 2026 [21], and on 27 August 2026 announced its acceptance as a growth-stage project of the foundation [19][20]. Both are Apache 2.0 licensed [13][16]. Neither is one vendor’s property, and the two are not governed alike.

2.4 What the protocols do not give you

The MCP specification lists its security principles — user consent, data privacy, tool safety — and then states that “MCP itself cannot enforce these security principles at the protocol level” [1]. It adds that the client and server names exchanged in each request are self-reported and should not be relied on for security decisions [2]. Authorisation is optional [8].

An independent reading reaches the same place by another road. Kang and Diponegoro tested the specifications of five agent interoperability protocols, MCP and A2A among them, against six governance capabilities: membership, deliberation, voting, dissent preservation, human escalation, and audit and replay. They report that no protocol covers the full set and conclude that governance “constitutes a missing architectural layer above current interoperability standards” [23]. Their subject is the governance of agent communities, which is narrower than enterprise control. The consequence for an enterprise is the same. Identity that can be trusted, authorisation per caller and per tool, ownership, versioning policy and an audit record have to be supplied around the protocols. Sections 4 to 6 propose where.

2.5 Platform support, as of November 2026

Each of the three large cloud providers documents support for both protocols, and each has limits worth knowing. I report only what the pages cited say.

Microsoft. Foundry Agent Service connects agents to remote MCP servers on public or private endpoints [27] and offers a toolbox that places a curated set of tools behind one MCP-compatible endpoint with central authentication and versioning [26]. An agent can call a remote A2A agent [25] and can be exposed as one. On the incoming side the documentation is candid: A2A version 1.0 is generally available and 0.3 is in preview; for 1.0 only the JSON-RPC binding is supported; only text is supported; streaming is not; and a request that names no version is served 0.3 by default [24]. Microsoft’s recommended way to add an A2A agent is through a toolbox, which presents it on an MCP endpoint [25]. That is the pattern Section 3 warns about, and I would ask Microsoft what becomes of the task lifecycle on that route before adopting it; the pages I opened do not say. The MCP page I opened does not state which MCP revision the service implements, and it links long-running task support, in preview, to the 2025-11-25 revision [27].

AWS. Amazon Bedrock AgentCore Gateway converts APIs and Lambda functions into MCP tools, fronts other agents through passthrough targets including A2A traffic, and handles inbound and outbound authentication [28]. AgentCore Runtime hosts MCP servers and A2A servers; for A2A it passes JSON-RPC payloads through and serves Agent Cards at the standard path [29]. The release notes record support for MCP revision 2026-07-28 in the Runtime in November 2026 and for the MCP Tasks extension in the Gateway in October 2026, and general availability of a separate agent registry in August 2026 [30]. The Runtime’s A2A tutorial, as opened, still uses an SDK of the 0.3 line and the older method names, and does not state support for version 1.0 [29].

Google Cloud. The Agent Gateway of Gemini Enterprise Agent Platform governs MCP tool calls and A2A delegation for agents running on that platform; support for agents on GKE, Cloud Run and other clouds is marked as coming soon [31]. The platform’s managed runtime orchestrates agents and tools that use MCP and A2A but, in Google’s words, “doesn’t support the hosting of custom MCP servers”, which are deployed on Cloud Run or GKE [32]. An Agent Registry covers agents and MCP servers [33].

Three observations. All three providers have converged on the same four components this paper proposes, which is some comfort that the design is not eccentric. None of the three supports both protocols completely at their current versions. And the vendor’s registry and gateway govern what runs on that vendor’s platform, so a firm with agents in more than one place still needs its own catalogue above them. I have not verified agent frameworks outside these three platforms and make no claim about them.

3. Tool or agent: a design heuristic

From here the paper is the author’s proposal.

The first design decision for any capability a team wants to share is which protocol it belongs behind. The heuristic I use is short.

If the counterpart executes a well-defined function and returns, wrap it as an MCP server. If it reasons, plans, holds state across turns, or may come back with questions, expose it as an A2A agent.

A balance lookup, a document search, a sanctions-list check and a ledger posting are tools. A claims-triage agent that may ask for a missing document, a research agent that works for twenty minutes and returns a report, and a reconciliation agent that negotiates exceptions with another department’s agent are agents.

An agent can be surfaced as an MCP tool, and doing so flattens its task lifecycle. The temptation is real, because an orchestrator that already speaks MCP needs nothing new to call it. What is lost depends on how it is done.

• As a plain tool call, the delegation becomes one request and one result. A clarifying question has nowhere to go, long-running work has no handle, and the caller’s record shows a function call where a delegation took place.
• With MCP’s Tasks extension, part of this is recovered: there is a durable handle, and a task can pause for input [11]. It is still not the same thing. The pause is an elicitation addressed to the user through the client, not a turn in a conversation between two agents. There is no Agent Card to say what the agent is and what skills it offers, no context that groups related tasks, no artefacts as distinct outputs, and no states for “rejected” or “authentication required”. Both sides must have opted in to the extension, and support is uneven (Section 2.5).

The A2A project draws the same line from its side: presenting an agent’s skills in tool form “works best when the skills are well-defined and can be called in a tool-like, stateless way” [18]. I would put it as a rule of evidence. If the record of an interaction must show that work was delegated to something that exercised judgement, the interaction belongs on A2A, because that is where the task, its states and its outputs are first-class and can be logged as such.

Three clarifications keep the heuristic honest.

1. It is a default, not a law. A capability that reasons internally but always returns in one step with a bounded answer, such as a classifier, can sit behind MCP without loss.
2. It runs in one direction only. Wrapping a deterministic function as an A2A agent adds a lifecycle nobody needs and a second place to authorise.
3. It should be recorded. The choice goes in the design record for the capability, with the reason, so that a later reviewer can see whether the flattening was a decision or an accident.

4. Four platform products

In the layer model of Working Paper 01, agents and their orchestration live in L3 (reasoning and orchestration); tools, MCP servers, A2A endpoints and the connectors to enterprise systems live in L4 (integration and interoperability); and identity, policy, logging and audit evidence belong to the X plane (trust and operations), which crosses every layer. The source material for this paper drew the same ground as a five-layer stack with separate agent and orchestration layers. I have folded those into L3 so that the series uses one model. Nothing in the argument depends on the difference.

My proposal is that MCP and A2A are platform capabilities and not project deliverables. Delivery teams build and own agents in L3. The platform team owns four products in L4, and those products are where the X-plane controls are enforced on protocol traffic.

flowchart TD
    L5["L5 Experience & channels"] --> ORC
    subgraph L3["L3 Reasoning & orchestration — delivery teams"]
        ORC["Orchestrating agent"]
        DA["Domain agent"]
    end
    subgraph L4["L4 Integration & interoperability — platform team"]
        AGW["A2A gateway"]
        REG["A2A agent registry"]
        MGW["MCP gateway"]
        CAT["MCP server catalogue"]
        SRV["MCP servers, one per system"]
    end
    ORC -->|A2A| AGW
    AGW -->|A2A| DA
    AGW -.- REG
    ORC -->|MCP| MGW
    DA -->|MCP| MGW
    MGW -.- CAT
    MGW --> SRV
    SRV --> SYS[("Systems of record")]
    X["X Trust & operations plane<br/>identity · policy · logging · evidence"] -.-> AGW
    X -.-> MGW

Every agent has both roles: it reaches tools downward through the MCP gateway and reaches other agents sideways through the A2A gateway. Nothing reaches a server or an agent by any other path.

1. The MCP server catalogue. The governed list of MCP servers that wrap the firm’s systems. Each entry has an owner, a semantic version, a data classification, a published tool contract and a lifecycle state. The catalogue is the largest reuse lever in the design, because it is where a second team discovers that the first team’s work exists.

2. The MCP gateway. A policy enforcement point in front of the catalogued servers. It authenticates the calling agent, decides per caller and per tool whether the call is allowed, exchanges the caller’s token for one the target server will accept, applies rate limits, logs request and response, and inspects content against the data classification. Agents do not hold system-of-record credentials. The gateway maps agent identity to scoped access. Working Paper 01 calls this the tool gateway and distinguishes it from the AI gateway, which carries model calls. They can share infrastructure. They should not share a policy model, because a model call and a write to the ledger are different risks.

3. The A2A agent registry. The firm’s directory of Agent Cards. Publication is a release step: a card is listed only after the agent has passed evaluation and security review and has a named human owner. Agents discover each other through the registry and nowhere else. Where cards are signed, the registry is where signatures are checked.

4. The A2A gateway. The enforcement point for agent-to-agent traffic: mutual authentication, an audit trail keyed on task and context identifiers, a policy for which domains’ agents may delegate to which, and egress control for any agent outside the firm.

The stateless turn in MCP helps here. A gateway that sees a self-contained request, with the protocol version and method in headers it can read without parsing the body [3][5][7], can route, authorise and load-balance without session affinity. It also makes the gateway the natural owner of version policy: it knows which revisions each server accepts and can refuse a client that is too old or too new for the estate.

What this costs. The gateways are availability-critical and see sensitive content. They must be classified at the highest data class they carry, included in failure-mode analysis, and run as products with service levels. A gateway that is slower or less reliable than calling the system directly will be bypassed, and a bypassed gateway is worse than none because the firm believes it has control. I would not build the A2A pair until there are agents that genuinely need to delegate to each other; Section 8 sequences this.

Build or buy. Section 2.5 shows that each cloud provider now sells versions of all four. For agents that live entirely on one platform, the vendor’s components are a reasonable implementation. The firm should still own the model: the catalogue schema, the authorisation matrix and the release criteria should be the firm’s documents, implemented in a vendor’s product, so that a second platform or an exit does not mean starting again.

5. Reuse rules: wrap once and its siblings

Reuse does not follow from adopting a protocol. It follows from treating protocol assets as shared products with owners, contracts and contribution rules. Three rules do most of the work.

5.1 Wrap once, at the right layer

A system of record gets exactly one MCP server, owned by the team closest to the system and listed in the catalogue with a semantic version. A second wrapper for the same system is a contribution to the first, by inner-source pull request — never a fork.

The reasoning is the same as for any shared interface. The team closest to the system knows what its fields mean and what a write does. Two wrappers mean two authorisation models, two interpretations of the same field and two things to patch when the system changes. A consuming team that needs a tool the server lacks proposes it to the owner; if the owner is slow, the remedy is to fix the owner’s capacity, not to fork.

“At the right layer” means the server sits at L4, in front of the system, and exposes the system’s capabilities in business terms. It does not embed one consumer’s workflow. A tool called get_policy_summary_for_renewals_bot is a sign that a consumer’s logic has leaked into the wrapper.

Tool contracts follow the deprecation discipline of APIs. Additive changes are minor versions. A breaking change to a tool’s schema is a major version with a migration window, and both versions are served until the window closes. MCP’s own feature lifecycle, with its minimum twelve-month deprecation window [5], is a reasonable model to copy.

One caveat. Some systems are too large for a single server to be sensible; a core banking platform may warrant one server per bounded domain. The rule then applies per domain: one server, one owner, no forks.

5.2 Manifest-driven discoverability

Every repository that ships an MCP server or an A2A agent carries a machine-readable manifest: name, tools or skills, data classification, owner, and for agents the location of the card. The catalogue and the registry are built from these manifests by pipeline. Nobody maintains them by hand, which is the only way they stay true. It also makes the estate discoverable to agents, so that a coding agent asked to integrate with the document store finds the existing server before it writes a new one.

5.3 Composition before construction

A new use case is first written as a composition: which existing MCP servers, which existing agents, and what new domain logic. The delivery team builds only the difference. Cross-team workflows then need no shared codebase. A reporting agent built for one programme can be delegated to by an underwriting workflow in another, because the task interface is the integration point.

5.4 The reusable assets

On the economics. I expect the first project to carry the cost of the templates and the first catalogue entries, and later projects to spend progressively more of their effort on domain logic. I state that as a judgement. I have no measured data on where the crossover falls, and it will depend on how many systems the early projects happen to share. The measures that would test it are the share of a project’s integrations met from the catalogue and the elapsed time from request to first governed tool call.

6. Threat model

Both protocols were designed with security in mind, and both leave enforcement to the implementer (Section 2.4). The table sets out five threats and where the platform products answer them. It is my synthesis; the token-passthrough row rests on the MCP specification and is developed below.

6.1 Token passthrough

MCP’s security guidance defines token passthrough as “an anti-pattern where an MCP server accepts tokens from an MCP client without validating that the tokens were properly issued to the MCP server and passes them through to the downstream API” [9]. The specification forbids it: servers must validate that a token was issued for them as the intended audience and “MUST NOT accept or transit any other tokens” [8].

The reason it matters is the confused deputy. The downstream system honours a credential on the assumption that the party presenting it was entitled to. The MCP server in the middle has lent its position to a caller without checking the caller’s authority. The guidance lists the consequences: controls such as rate limiting and request validation are circumvented; the server cannot tell clients apart; the downstream system’s logs show the wrong identity; and a stolen token can be replayed through the server as a proxy [9]. For a regulated firm the second and third are the serious ones. An action on a system of record that cannot be attributed to a specific agent, acting for a specific person or purpose, is an audit finding waiting to be written.

The specification places the duty on each server. In an estate with dozens of servers written by different teams, I would not rely on every one of them getting it right. The design answer has three controls, and they work together.

1. The gateway mediates the token exchange. The agent presents its own token, issued for the gateway. The gateway authorises the call and obtains a short-lived downstream token whose audience is the one target server and whose scope is the one purpose. Where the agent acts for a person, the exchange carries both identities.
2. Every server validates the audience claim. A server refuses any token not issued for it, however valid the token otherwise looks. This is the specification’s own requirement [8]. The server template of Section 5.4 should implement it so that no team writes it twice, and the evaluation harness should test it with a wrong-audience token before a server is listed.
3. Agents never hold system-of-record credentials. The server reaches its system with its own credential. Nothing in an agent’s context, memory or configuration opens the system directly, so a compromised or manipulated agent has nothing to leak that works anywhere but at the gateway.

sequenceDiagram
    participant A as Agent
    participant G as MCP gateway
    participant I as Identity provider
    participant S as MCP server
    participant R as System of record
    A->>G: tools/call with the agent's token (audience = gateway)
    G->>G: Authorise caller, tool and data class, then log
    G->>I: Exchange for a short-lived token (audience = this server)
    I-->>G: Downstream token
    G->>S: tools/call with the downstream token
    S->>S: Validate audience, refuse anything else
    S->>R: Call with the server's own credential
    R-->>S: Result
    S-->>G: Result
    G-->>A: Result, after content inspection

The same discipline applies on the A2A side. A client agent authenticates to the remote agent with a credential issued for that agent, under a scheme its card declares [15]; it does not forward the token it was itself called with. The A2A gateway enforces this for traffic inside the firm and is the only route for traffic leaving it.

6.2 Accountability

Protocols make delegation cheap, so the line between what agents do and what people decide has to be drawn explicitly and enforced where the traffic flows. Three practices follow. Tool contracts separate tools that read from tools that act, and the gateway policy treats them differently. A2A tasks that lead to a consequential action route through a human approval step; A2A’s interrupted task states give the request somewhere to wait [15]. And accountability for an agent’s behaviour attaches to the named human owner who set its scope and guardrails, recorded in the registry entry, and never to the agent. Both protocols help in one respect: every action is an explicit message that can be logged and attributed. Whether it is logged and attributed is the firm’s doing.

7. Regulatory orientation

This section is architectural orientation as of November 2026, not legal advice. The article references were read on EUR-Lex on 10 November 2026.

I make three narrow points and no mapping table. An earlier draft of this material mapped each regulatory requirement to a platform component, and that overstated what the architecture does.

First, the catalogue and the registry are not the DORA register. Regulation (EU) 2022/2554 requires financial entities to keep a register of information on their contractual arrangements for ICT services provided by third-party service providers, and to identify and document their ICT assets and dependencies [34] (Article 28(3) for the register of information; Article 8(1) for the identification and documentation of ICT-supported functions and assets). A catalogue of MCP servers is an inventory of interfaces: what can be called, by whom, at which version, at which data class. It can feed the documentation of ICT assets and dependencies. It does not record contracts. Where an MCP server is operated by a supplier, or a partner’s agent is reached over A2A, there is an ICT service from a third party behind the interface, and in my reading that arrangement goes through the firm’s third-party risk process and into the register like any other. The catalogue’s contribution is that it tells the firm such an interface exists. Whether a given arrangement is in scope, and whether it supports a critical or important function, is for the firm’s risk and legal functions.

Second, the EU AI Act regulates AI systems, not protocols. The obligations in Regulation (EU) 2024/1689 on automatic logging and on human oversight apply to high-risk AI systems [35] (Articles 12 and 14, and the deployer’s duty to keep logs in Article 26(6)). Under the Regulation as amended in 2026, those obligations apply from 2 December 2027 for Annex III systems. An MCP gateway is not such a system. Where one of the firm’s agents is part of a system that is classified as high-risk, gateway logs and task records keyed on A2A task and context identifiers are useful raw material for the logging the regulation asks for, and approval steps at the gateway are one way to implement oversight. They are material, not compliance.

Third, the UK and Swiss regimes point the same way on inventory and third parties. For Swiss banks, FINMA Circular 2023/1, in force since 1 January 2024, requires one or more inventories of ICT assets and says that dependencies within the institution and interfaces to significant external service providers should be taken into account (margin no. 53) [36]. For UK firms, the PRA’s Supervisory Statement SS2/21 sets out expectations on outsourcing and third-party risk management [37]. I cite both as places to look, and I have not analysed either in depth.

Data protection questions raised by tool calls that carry personal data are treated in Data Classes, Processing Lanes and Controller/Processor Roles for AI (Working Paper 09) and are not repeated here.

8. Adoption in four phases

A phased introduction lets the platform assets accumulate while risk stays bounded. Each phase has an exit criterion. I give no durations: they depend on the firm’s size, on how many systems the first use cases share, and on how much of Section 4 is bought, and any figure I offered would be a guess.

Four practical points.

• The order matters. MCP comes before A2A because the tool estate is where reuse pays first and where the credential risk is. Starting with A2A, before there are well-governed tools for agents to use, produces agents that delegate to agents that have nothing safe to do.
• Skipping a phase has a known result. A firm that opens the catalogue before the gateway exists, or admits external agents before the internal gateway has been exercised, gets ungoverned sprawl with protocol names attached.
• Use the official SDKs in preference to hand-written protocol code. MCP lists TypeScript, Python, C#, Go, Rust and Ruby in its first tier, Java in its second, and Swift, PHP and Kotlin in its third, and warns that SDKs adopt new protocol revisions on their own schedules [12]. A2A lists Python, Go, Java, JavaScript, C#/.NET and Rust [22]. Check, per SDK, which protocol version it actually implements.
• Pin protocol versions deliberately. MCP dates its revisions and declares the version on every request [3]; A2A carries a version that clients select [15][24]. The gateways should own the supported-version policy for the estate, so that a protocol revision becomes a planned change and not a surprise. The deprecations in Section 2.1 are a case in point: a firm with servers that depend on Sampling or Roots has a dated migration to schedule.

Limitations

• The platform design is a proposal. The four products, the three reuse rules, the threat model and the phases are one author’s synthesis. None has been tested in a controlled comparison, and the claim that they compose into a workable operating model is argument.
• The protocol facts will date. Both protocols changed materially in 2026, and MCP has three features in a deprecation window that runs to at least 28 July 2027. Before relying on Section 2, re-check: the MCP specification’s current revision and its “Key Changes” and “Deprecated Features” pages [5][6]; the MCP authorisation specification [8]; the A2A specification’s latest released version and its list of protocol bindings [15]; and each project’s SDK page [12][22].
• The tool-or-agent heuristic is weaker than it was. MCP’s Tasks extension narrows the gap between a tool call and a delegated task. I have argued that a real difference remains, but the extension is young and I have not tested how hosts implement it. If MCP acquires agent description and context grouping, the heuristic will need revisiting.
• Regulatory statements are a technologist’s reading and not legal advice. Insurer and asset-manager equivalents of the UK and Swiss documents cited are not covered, and the PRA statement was confirmed only at the level of its title, dates and subject.
• Platform support was read from documentation, not tested. Section 2.5 reports what each vendor’s pages said on the access date. Vendor pages for the same product disagree with one another in places, product names are changing, and I did not deploy anything to confirm behaviour. Agent frameworks and platforms outside the three cloud providers were not examined.
• A2A’s specification was read in sections. The page is long, and the sections on authentication (Section 7 of the specification) and on Agent Card signature format were not read in full. The statements made here about security schemes, signing and transport security come from the sections that were.
• The economics are unmeasured. The statement that integration effort shifts to domain logic as the catalogue grows is a judgement with no data behind it.
• Gateways concentrate risk. The design puts availability and confidentiality risk in two components. The paper says they must be run as products and does not show how.
• Verification. The source checks for this version were carried out by an AI research agent working under my direction, which opened the pages listed below on 10 November 2026. That is machine-assisted verification, not peer review, and the paper has not yet had a legal or practitioner review.

References

All web sources were accessed on 10 November 2026.

1. Model Context Protocol. “Specification”, revision 2026-07-28 (overview: key details, features, security and trust and safety). https://modelcontextprotocol.io/specification/latest
2. Model Context Protocol. “Overview” (base protocol: messages, statelessness, _meta), specification revision 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28/basic
3. Model Context Protocol. “Versioning and Compatibility”, specification revision 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28/basic/versioning
4. Model Context Protocol. “Discovery” (server/discover), specification revision 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28/server/discover
5. Model Context Protocol. “Key Changes” (changes since revision 2025-11-25), specification revision 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28/changelog
6. Model Context Protocol. “Deprecated Features” (registry), specification revision 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28/deprecated
7. Model Context Protocol. “Overview” (transports), specification revision 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28/basic/transports
8. Model Context Protocol. “Authorization”, specification revision 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
9. Model Context Protocol. “Security Best Practices” (documentation). https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
10. Model Context Protocol. “Architecture overview” (documentation for revision 2026-07-28). https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture
11. Model Context Protocol. “Tasks” (extension overview). https://modelcontextprotocol.io/extensions/tasks/overview
12. Model Context Protocol. “SDKs”. https://modelcontextprotocol.io/docs/sdk
13. Model Context Protocol. “Governance and Stewardship”. https://modelcontextprotocol.io/community/governance
14. The Linux Foundation. “Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF)”. Press release, 9 December 2025. https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
15. A2A Project. “Agent2Agent (A2A) Protocol Specification”, version 1.0.0 (latest released version on the access date). https://a2a-protocol.org/latest/specification/
16. A2A Project. “A2A Protocol” (project home page). https://a2a-protocol.org/latest/
17. A2A Project. “Core Concepts” (documentation). https://a2a-protocol.org/latest/topics/key-concepts/
18. A2A Project. “A2A and MCP: Detailed Comparison” (documentation). https://a2a-protocol.org/latest/topics/a2a-and-mcp/
19. A2A Project. “A New Chapter for A2A: Joining the Agentic AI Foundation”. Blog, 27 August 2026. https://a2a-protocol.org/latest/blog/2026/08/27/a-new-chapter-for-a2a-joining-the-agentic-ai-foundation/
20. Agentic AI Foundation. “Projects”. https://aaif.io/projects/
21. The Linux Foundation. “A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms, and Sees Enterprise Production Use in First Year”. Press release, 9 April 2026. https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year
22. A2A Project. “A2A SDK” (documentation). https://a2a-protocol.org/latest/sdk/
23. Kang, R. and Diponegoro, Y. “Governance Gaps in Agent Interoperability Protocols: What MCP, A2A, and ACP Cannot Express”. arXiv:2606.31498v1, 30 June 2026. https://arxiv.org/abs/2606.31498
24. Microsoft Learn. “Enable incoming A2A on a Foundry agent”. Page dated 11 September 2026. https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/enable-agent-to-agent-endpoint
25. Microsoft Learn. “Connect to an A2A agent endpoint from Foundry Agent Service”. Page dated 28 October 2026. https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/tools/agent-to-agent
26. Microsoft Learn. “What is Toolbox in Microsoft Foundry?”. Page dated 26 October 2026. https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/toolbox-overview
27. Microsoft Learn. “Connect agents to MCP server endpoints”. Page dated 28 October 2026. https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/tools/model-context-protocol
28. Amazon Web Services. “Amazon Bedrock AgentCore Gateway: A secure AI gateway for agents, tools, and models”, Amazon Bedrock AgentCore Developer Guide. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html
29. Amazon Web Services. “Deploy A2A servers in AgentCore Runtime”, Amazon Bedrock AgentCore Developer Guide. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-a2a.html
30. Amazon Web Services. “Release notes for Amazon Bedrock AgentCore” (entries for August, October and November 2026). https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/release-notes.html
31. Google Cloud. “Agent Gateway overview”, Gemini Enterprise Agent Platform documentation. https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/agent-gateway-overview
32. Google Cloud. “Choose your agentic AI architecture components”, Cloud Architecture Center. https://docs.cloud.google.com/architecture/choose-agentic-ai-architecture-components
33. Google Cloud. “Agent Registry” (overview). https://docs.cloud.google.com/agent-registry/overview
34. Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (DORA). OJ L 333, 27.12.2022, p. 1. Articles 8 and 28(3). https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng Read in the Official Journal text on EUR-Lex, 10 November 2026.
35. Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). OJ L, 2024/1689, 12.7.2024. Articles 12, 14 and 26(6), as amended by Regulation (EU) 2026/1744. Consolidated text of 27 July 2026: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02024R1689-20260727 Read on EUR-Lex, 10 November 2026.
36. FINMA. Circular 2023/1, “Operational risks and resilience – banks”, 7 December 2022, in force 1 January 2024. Section on ICT operations, margin no. 53. https://www.finma.ch/en/~/media/finma/dokumente/dokumentencenter/myfinma/rundschreiben/finma-rs-2023-01-20221207.pdf
37. Prudential Regulation Authority. Supervisory Statement SS2/21, “Outsourcing and third party risk management”, first published 29 March 2021; current version published 15 November 2024, effective 31 December 2024. https://www.bankofengland.co.uk/prudential-regulation/publication/2021/march/outsourcing-and-third-party-risk-management-ss