MCP (Model Context Protocol) and A2A (Agent-to-Agent Protocol) both involve agents communicating. Both use JSON-RPC over HTTP. Both promise interoperability.
But they solve completely different problems. Here’s how to tell them apart.
One Example That Shows Both
Your Account Executive (AE) Agent is working on a $200K deal. The prospect wants a custom discount. Here’s what happens:
First, the AE agent gathers context using MCP:
- Calls
query_crm(company='Acme Corp')→ gets deal history - Calls
calculate_revenue_forecast(deal_size=200000)→ projects ARR impact - Calls
get_competitor_intel(company='Acme Corp')→ checks competitive threats
These are tools. They execute and return data. No thinking. No negotiation.
Then, the AE agent negotiates with the Finance agent using A2A:
The AE sends a task: “Approve 25% discount for Acme Corp — $200K, 3-year commit, competing against Competitor X.”
The Finance agent doesn’t just execute. It reasons:
- “What’s our discount policy for deals over $150K?”
- “What’s the win rate against Competitor X?”
- “Can we offer 20% instead and still close?”
Finance responds: “Approved at 20% with quarterly reviews. 25% needs exec approval.”
Why you need both:
- MCP lets the AE agent use tools (CRM, calculators, databases)
- A2A lets the AE agent collaborate with another agent (Finance) that has its own reasoning and policies
One agent, using tools and negotiating with peers in the same workflow.
MCP: Agent → Tool
Model Context Protocol standardizes how agents discover and call tools.
Before MCP, every LLM had its own function-calling format. You’d build a calculator for Claude, then rewrite it for GPT-4. MCP fixes this — one protocol, any agent, any tool.
How it works:
- Tools advertise capabilities:
tools/list - Agents invoke them:
tools/call - Tools execute and return results
Key principle: The agent controls everything. Tools are passive — they wait to be called, execute, return data. A calculator doesn’t decide when to calculate. Your agent does.
Example: Your Agentforce agent calls an MCP calculator server. The calculator has no LLM, no reasoning, no autonomy. It’s just a function.
A2A: Agent ↔ Agent
Agent-to-Agent Protocol (by Google) standardizes how autonomous agents collaborate across different systems.
Before A2A, connecting a Salesforce agent to a Google Cloud agent meant custom webhooks and proprietary orchestration. A2A fixes this — one protocol for agent-to-agent collaboration.
How it works:
- Agents advertise skills via an Agent Card at
/.well-known/agent.json - Agents discover each other
- Agents send Tasks (not function calls — full goal-oriented requests)
- Tasks have a lifecycle: submitted → working → completed/failed
- Communication is async, streaming, multi-turn
Key principle: Agents are peers. Each has its own LLM, its own reasoning, its own tools. When Agent A sends a task to Agent B, Agent B thinks about how to accomplish it — may ask questions, delegate, or refuse.
Example: Your CRM agent sends a task to an HR agent: “Find engineers hired in Q1 who completed compliance training.” The HR agent reasons independently, uses its own tools (via MCP), and returns results.
The One Rule That Clears Up All Confusion
“Does the other end have its own reasoning loop?”
- NO (it’s a function, API, database, service) → MCP
- YES (it’s an LLM-powered agent with goals) → A2A
Or think of it this way:
MCP = Hiring a contractor with a task list. You decide what happens. They execute.
A2A = Partnering with a consulting firm. You send a business objective. They figure out the how — and may push back with questions or alternatives.
The official A2A spec says: “A2A is about agents partnering on tasks, while MCP is more about agents using capabilities.”
MCP vs A2A: Head-to-Head Comparison
| Dimension | MCP (Model Context Protocol) | A2A (Agent-to-Agent Protocol) |
|---|---|---|
| Core purpose | Agent discovers and calls tools | Agents discover and collaborate with agents |
| Relationship model | Controller → Tool (master/servant) | Peer ↔ Peer (collaborators) |
| What’s on the other end | A function, API, database, service | Another autonomous agent with its own LLM |
| Does the other end reason? | No — passive execution only | Yes — full reasoning, may negotiate or refuse |
| Communication pattern | Request/Response (mostly synchronous) | Task lifecycle (async, streaming, stateful) |
| Discovery mechanism | tools/list from MCP server |
Agent Card at /.well-known/agent.json |
| State | Mostly stateless | Stateful tasks with lifecycle tracking |
| Transport | JSON-RPC over HTTP or stdio | JSON-RPC over HTTP |
| Real-world analogy | Chef using kitchen tools | Restaurants collaborating on an event |
| Salesforce implementation | MCP Server registration + Agent Script binding | A2A federation (external agent discovery) |
When to Use Which
Connecting to something that executes commands? → MCP
Connecting to something that thinks and negotiates? → A2A
Common Mistakes
Using A2A for simple tools: If it’s just a database wrapper with no reasoning, it’s a tool. Use MCP.
Using MCP for peer collaboration: If the other side needs to ask questions, negotiate, or delegate, it’s an agent. Use A2A.
Treating them as competitors: You need both. Agents use tools (MCP) AND collaborate with other agents (A2A).
The Bottom Line
MCP = Agent uses a tool (CRM query, email API, calculator)
A2A = Agent negotiates with another agent (Finance, Legal, HR)
Tools don’t think. Agents do.
MCP gives your agent hands. A2A gives your agent a phone.
The one-question test: Does the other end have its own reasoning loop?
Yes → A2A. No → MCP.
Further Reading:
- Use MCP and Agent Script to Connect Agentforce to External MCP Tools — Hands-on tutorial for implementing MCP with Agentforce
- SOMA + A2A: The Two-Layer Architecture for Enterprise Multi-Agent Systems — Deep dive on multi-agent architecture patterns
- A2A Protocol: A2A and MCP — Official comparison from the A2A specification