MCP, A2A, Skills, Toolbox: Where Agent Protocols Are Converging

When AI agents first started multiplying, every vendor shipped their own integration approach. Anthropic’s Claude connected to tools one way. OpenAI’s assistants connected another way. If you wanted two agents to collaborate, you wrote glue code. If you wanted your agent to talk to a database, you wrote more glue code. The ecosystem was useful but incoherent.

That’s changing. Over the past year, a set of open protocols has emerged that is quietly resolving the integration chaos. They operate at different layers — tools, data, knowledge, and inter-agent communication — and once you see the stack clearly, the redundancy and confusion largely disappear.

MCP: The Vertical Layer

Model Context Protocol is Anthropic’s answer to the question: how should an LLM connect to external tools and data?

The architecture is straightforward. An MCP server exposes capabilities through a small set of primitives:

• Tools — callable actions the model can invoke (run a query, send a message, list files)
• Resources — structured data the model can read (a document, a database record, a file)
• Prompts — reusable prompt templates with parameter slots
• Sampling — a back-channel that lets a server ask the model for a completion mid-task
• Elicitation — a way for a server to request information from the user through the client

Transport-wise, MCP uses stdio for local servers (the model and the tool run on the same machine) and Streamable HTTP for remote servers. SSE was used early on but was deprecated in the March 2025 spec revision in favor of a single HTTP endpoint that handles both request-response and streaming.

The adoption numbers tell the story. As of late 2025, MCP had over 10,000 published servers and 97 million monthly SDK downloads. ChatGPT, Cursor, Gemini, GitHub Copilot, and VS Code all support it. In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation — co-founded with Block and OpenAI, with Google, Microsoft, AWS, Cloudflare, and Bloomberg as supporters. The USB-C analogy that spread across the industry is apt: one plug, anything connects.

What MCP solves is vertical integration — the connection between a single agent and the tools and data below it.

       [ Agent ]
          │
     MCP  │   tools, resources, prompts
          │
    [ External Services ]
    (databases, APIs, filesystems)

A2A: The Horizontal Layer

Agent2Agent (A2A) was created by Google and addresses a completely different problem: how should agents talk to each other?

When an orchestrating agent needs to delegate work to a specialized agent, there was previously no standard for how that delegation should happen. A2A defines it.

The protocol has three key concepts:

Agent Cards — a JSON document each agent publishes (at /.well-known/agent.json) describing its identity, skills, and how to reach it. When an orchestrator wants to find a capable agent for a task, it fetches the Agent Card. This is capability discovery, similar to how browsers fetch robots.txt or OAuth clients fetch .well-known/openid-configuration.

Tasks — the fundamental unit of work in A2A. A task has an ID and moves through a defined lifecycle: submitted → working → input-required → completed (or failed, canceled). Long-running tasks stay open and update incrementally.

Messages — agents exchange structured messages containing typed “parts” (text, files, data). Streaming uses Server-Sent Events so an orchestrator can receive incremental updates from a long-running task without polling.

Under the hood, A2A uses JSON-RPC 2.0 over HTTP. It was donated to the Linux Foundation in June 2025, with AWS, Cisco, Microsoft, Salesforce, SAP, and ServiceNow as founding partners. IBM had launched a competing protocol called ACP for its BeeAI platform; in August 2025, the ACP team merged into A2A rather than sustain a parallel standard.

Where MCP is vertical, A2A is horizontal — it’s the network layer between peer agents:

  [ Orchestrator Agent ]
       │           │
  A2A  │           │  A2A
       │           │
[ Research    [ Code Review
   Agent ]       Agent ]

The two protocols are explicitly complementary. An agent might use A2A to receive a delegated task from an orchestrator, then use MCP internally to fetch data from a database and call an API. The A2A spec documentation says exactly this: “MCP provides helpful tools and context to agents; A2A provides agent-to-agent communication.”

Skills: Knowledge Above the Protocol

Skills are a layer above MCP — not a new protocol, but a packaging mechanism for domain knowledge that agents need to be effective.

Microsoft’s Agent Skills framework is the clearest example. It provides 134+ domain-specific knowledge modules that help coding agents work correctly with Azure SDKs and services. A skill for Azure AI Agents teaches an agent the right way to set up agents, handle threads, and manage authentication. A skill for Cosmos DB teaches the right partition key patterns, indexing strategies, and SDK idioms.

Skills answer a different question than MCP. MCP answers how an agent invokes a capability. Skills answer what the agent should know when doing so. A coding agent with access to a database tool (via MCP) but no knowledge of connection pooling, authentication patterns, or query optimization will produce worse results than one that has those patterns encoded.

Claude Code’s own skills system follows the same logic — reusable behavioral packages that activate in context, providing the agent with domain-appropriate knowledge without bloating every prompt.

Toolbox: Implementations Below the Protocol

If Skills sit above the protocols, Toolbox implementations sit below them — they’re the pre-built, production-ready servers that actually expose capabilities over MCP.

Google’s MCP Toolbox for Databases is a good example. Originally named Gen AI Toolbox for Databases, it was renamed when MCP support was added. It’s an MCP server that provides connection pooling, authentication (OAuth2, OIDC), and observability (OpenTelemetry) for a range of databases: AlloyDB, Cloud Spanner, Cloud SQL (Postgres, MySQL, SQL Server), Bigtable, BigQuery, Neo4j, and more.

Instead of writing boilerplate to connect an agent to a database and hoping you handled connection pooling correctly, you run Toolbox and get a well-engineered MCP server that handles the infrastructure concerns. The 10,000+ MCP servers in the ecosystem are collectively a growing Toolbox library: crawlers, email clients, Git providers, payment systems, calendar integrations.

Where It’s All Heading

The stack is becoming legible:

┌──────────────────────────────────┐
│         Skills                   │  domain knowledge for agents
├──────────────────────────────────┤
│         A2A                      │  agent ↔ agent (horizontal)
├──────────────────────────────────┤
│         MCP                      │  agent ↔ tools/data (vertical)
├──────────────────────────────────┤
│         Toolbox                  │  pre-built MCP server implementations
└──────────────────────────────────┘

Each layer has a job. MCP and A2A are now both under neutral governance at the Linux Foundation, which signals they’re infrastructure rather than competitive products — more like HTTP than a vendor feature. The ACP merger into A2A means one fewer competing standard for agent communication. The Agentic AI Foundation that now stewards MCP also includes AGENTS.md (OpenAI’s agent configuration format) and Goose (Block’s open-source coding agent), pulling further toward a common base.

The analogy to early TCP/IP development keeps coming up, and it’s fair. The routing is rough around the edges: identity isn’t unified across layers, observability is fragmented, and error propagation between MCP and A2A isn’t well-specified yet. But the basic architecture — MCP for the resource layer, A2A for the network layer, Skills for behavioral packaging, Toolbox for capability implementations — has a coherence that feels like something settling rather than something still searching.

The pattern echoes what happened with the web. HTTP defined how clients and servers talk. REST conventions standardized how resources were shaped. OAuth standardized authentication. Libraries and frameworks packaged the implementations. No single actor controlled all of it, and that’s why it worked.

The same thing appears to be happening for agents, just faster.