Erik Caldwell
Connect on LinkedIn
Menu

The Topic Catalog · 3

MCP & Agent Interoperability

Last updated · 8 min read

3.1 Model Context Protocol (MCP): Architecture & Enterprise Adoption

Priority: Must Understand

Executive Definition: MCP is an open protocol, originally released by Anthropic in late 2024, that standardizes how AI applications connect to external data sources and tools: described by its own documentation as "a USB-C port for AI applications." It defines a host/client/server architecture: an AI application (host) runs clients that each connect to one MCP server, which exposes tools, data ("resources"), and reusable prompts in a standard format any compliant client can consume.

Why It Matters: MCP is rapidly becoming the default way enterprises connect internal systems (databases, ticketing, Customer Relationship Management (CRM), internal APIs) to AI agents instead of building bespoke integrations per vendor per tool: reducing integration cost, but also creating a new internal surface (every MCP server you stand up) that needs the same access control and lifecycle discipline as any internal API.

What I Need to Understand:

  • MCP's architecture is host → client → server: your AI application is the host, it maintains one client connection per external system, and each MCP server exposes that system's tools/data in a standard schema: this is what lets "build once, integrate everywhere" work across Claude, ChatGPT, VS Code, and other MCP-compliant clients
  • As of December 2025, Anthropic donated MCP's governance to the newly formed Agentic AI Foundation (AAIF), a Linux Foundation directed fund co-founded by Anthropic, Block, and OpenAI, with Google, Microsoft, AWS, Cloudflare, and Bloomberg also participating: this is a genuine multi-vendor governance shift, not a single-vendor project anymore
  • MCP is still evolving quickly: the protocol's own 2026 roadmap lists transport scalability, an improved task/retry model, formal contributor governance, and enterprise auth (SSO-integrated) as still-in-progress priorities, not finished features: treat "enterprise-ready MCP" claims from vendors with that in mind
  • For your organization, MCP adoption practically means: which internal systems get an MCP server, who can build/approve one, and how you prevent an uncontrolled sprawl of servers each with their own credentials and access scope (see the MCP Security entry)
  • Despite fast momentum (Linux Foundation cites MCP among projects with extremely high install/download counts), MCP is roughly two years old as of this writing: it has real vendor commitment but not the multi-decade track record of protocols like HTTP or OAuth, and its authorization and enterprise-governance layers are explicitly still being built

Questions I Should Be Able to Ask My Team:

  1. Which internal systems currently have an MCP server exposed, who approved each one, and is there a central inventory, or did this happen organically without a registry?
  2. What authentication/authorization does each MCP server enforce, and is it consistent, or does each server implementer choose its own?
  3. If MCP's governance or spec shifts meaningfully under the new Linux Foundation structure, what's our exposure: how many internal systems and vendor integrations depend on the current protocol version?

Technologies / Standards / Companies to Know: Model Context Protocol (modelcontextprotocol.io), Agentic AI Foundation / Linux Foundation, Anthropic, OpenAI, Block (goose), Microsoft, AWS Bedrock AgentCore, Google

Recommended Learning:

Time Investment: 2-3 hours

3.2 MCP Security & Governance (internal marketplaces/catalogs, authorization, malicious servers)

Priority: Must Understand

Executive Definition: Because MCP servers can be published by anyone and consumed by an AI agent that then acts on the results, MCP introduces a distinct attack surface: a malicious or compromised server can return tool results containing hidden instructions that the underlying model treats as trusted context ("tool poisoning"), potentially causing the agent to leak data or invoke other tools it shouldn't. Enterprise governance in response centers on internal MCP registries/catalogs (a vetted, approved list of servers: analogous to an app store), strict authorization scoping, and treating every tool response as untrusted input, not just every user input.

Why It Matters: This is the same class of risk as supply-chain attacks in traditional software (a compromised dependency), except the "code" here is natural-language instructions embedded in data the model reads: a category that's genuinely harder to filter than a code scanner catches, and one your security team may not yet have tooling for. Getting ahead of this with an internal approval process is materially cheaper than remediating after an incident.

What I Need to Understand:

  • "Tool poisoning" works because there's a trust gap between connect-time (when a human reviews a tool's stated description) and runtime (when the tool actually executes and returns data): a server can describe itself innocently and only inject malicious instructions in its live responses, per OWASP's documentation of the pattern
  • Mitigations cluster into: requiring structured/fixed-schema tool outputs instead of free text, isolating high-privilege tools from any server sourced externally, enforcing access control at the tool/server layer (not relying on the model's system prompt as a security boundary), and allowlisting only pre-approved servers
  • Enterprises are converging on internal MCP registries/marketplaces (a curated, security-reviewed catalog of approved servers) as the practical governance unit: the same pattern as internal app stores or approved-vendor lists, now applied to agent tools
  • The MCP authorization specification (OAuth 2.1-based) defines how clients and servers should authenticate, but implementation is inconsistent across the ecosystem today: verifying a given server actually implements it correctly is a real due-diligence step, not a checkbox
  • This is one of the fastest-moving and least standardized parts of the whole domain: expect the tooling (scanners, registries, policy engines) here to change significantly within 12-18 months, and design your governance process to be tool-agnostic

Questions I Should Be Able to Ask My Team:

  1. Do we have an approved internal registry of MCP servers, or can any team or individual connect an agent to an arbitrary external MCP server today?
  2. How do we defend against tool poisoning specifically: do we treat tool call responses as untrusted content requiring the same scrutiny as user input, or only screen the tool's stated description at connection time?
  3. For any MCP server handling sensitive data, does it correctly implement the MCP authorization spec, and who verified that rather than took the vendor's word for it?

Technologies / Standards / Companies to Know: OWASP (MCP Tool Poisoning documentation), MCP Authorization spec, Invariant Labs, Kong/JFrog/other MCP registry vendors, Amazon Bedrock AgentCore Gateway

Recommended Learning:

Time Investment: 2-3 hours

3.3 Agent2Agent (A2A) Protocol & the Interoperability Landscape

Priority: Monitor

Executive Definition: A2A is an open protocol, originally developed by Google and now governed by the Linux Foundation, for letting independent AI agents (potentially built by different vendors, on different frameworks) discover each other's capabilities and communicate to delegate and coordinate tasks. It is explicitly complementary to MCP rather than competing with it: MCP standardizes how one agent connects to tools and data; A2A standardizes how separate agents talk to each other, using structured "Agent Cards" for capability discovery and cryptographic identity verification.

Why It Matters: This matters if your roadmap includes agents built by different vendors or business units needing to hand off work to each other (e.g., your internal procurement agent negotiating with a supplier's agent); for most mid-size enterprises this is still nearer to the adoption curve's early stages than MCP, and should be tracked rather than committed to as core infrastructure today.

What I Need to Understand:

  • A2A reached a 1.0 stable specification and, per Linux Foundation reporting, surpassed 150 supporting organizations and shipped SDKs in five languages, with integration into Azure AI Foundry, Amazon Bedrock AgentCore, and Google's platforms within roughly a year of its Linux Foundation donation
  • The stated division of labor is: MCP = agent-to-tool/data, A2A = agent-to-agent: in practice, a single system may use both simultaneously, MCP internally within one agent and A2A to talk to external or partner agents
  • A2A is younger and has a narrower proven production footprint than MCP; adoption numbers reflect organizational support/SDK availability, which is a different (and weaker) signal than deep production usage at scale: treat vendor and press framing of "adoption" with that distinction in mind
  • There is genuine, open disagreement in the field about whether a distinct inter-agent protocol is durably necessary long-term, versus agent-to-agent communication converging back onto MCP or HTTP/API-based patterns as the ecosystem matures: this is contested and unresolved, not settled
  • Related but distinct efforts exist in this same "agent interoperability" space (e.g., Agent Payments Protocol for agent-initiated transactions): the standards landscape here is still actively consolidating, not finished

Questions I Should Be Able to Ask My Team:

  1. Do we have an actual near-term use case requiring agent-to-agent communication across organizational or vendor boundaries, or is A2A adoption being proposed speculatively?
  2. If we adopt A2A now, what's our exposure if the standard doesn't consolidate the way current momentum suggests: how much of our integration work would need to be redone?
  3. Where does our use of MCP end and A2A begin in this design, and is that boundary actually necessary, or could the same coordination be done with MCP alone?

Technologies / Standards / Companies to Know: Agent2Agent (A2A) Protocol, Linux Foundation / Agentic AI Foundation, Google, Microsoft Azure AI Foundry, Amazon Bedrock AgentCore, Agent Payments Protocol (AP2)

Recommended Learning:

Time Investment: 1 hour