10.2 Open Multi-Agent Protocols: MCP and A2A
Key Takeaways
- Model Context Protocol (MCP) is an open standard that makes external tools self-describing, so an agent's MCP client can discover a server's tools, schemas, and instructions.
- Agentforce connects third-party MCP servers through Agentforce Registry and MuleSoft or Salesforce-hosted servers through API Catalog, and allowlisted tools become agent actions in the asset library.
- MCP for Agentforce supports Streamable HTTP servers with no authentication or OAuth 2.0 client credentials, supports server tools only, and doesn't support user-level authentication.
- Agent2Agent (A2A) is an open protocol for agent-to-agent collaboration that starts with discovery through an Agent Card describing an agent's skills, endpoint, and authentication.
- Use APIs for deterministic integrations, MCP when an agent needs tools from external systems, and A2A when a task should be delegated to another agent's reasoning.
10.2 Open Multi-Agent Protocols: MCP and A2A
Quick Answer: Model Context Protocol (MCP) is an open standard for agent-to-tool connectivity. An MCP server publishes self-describing tools, and the agent's MCP client discovers and calls them. Agent2Agent (A2A) is an open protocol for agent-to-agent collaboration. An agent discovers another agent through its Agent Card, authenticates, and delegates a task that the other agent reasons through. In Agentforce, allowlisted MCP tools become agent actions. A2A extends collaboration to agents outside Salesforce.
Model Context Protocol (MCP)
Purpose
Traditional APIs require you to map every input and output manually and often add flows or Apex so an agent can use them. MCP instead makes capabilities self-describing for AI agents:
- An MCP server holds a configuration for each ability, called a tool, with its name, description, and inputs. An ERP's MCP server might expose order submission and returns tools.
- An MCP client connects the agent (the host) to the server and retrieves the list of tools and their schemas.
- The agent can then discover and call tools without custom wrapper code for each endpoint.
Salesforce's platform adds controls. Admins choose which tools to make available. If a server's tool description changes significantly, Agentforce suspends that tool until an admin reviews it, which guards against a changed description silently altering agent behavior.
Use cases
| Use case | Example |
|---|---|
| Use partner-built tools without writing integration code | Install an MCP server from AgentExchange for a ticketing or document system |
| Expose governed enterprise APIs to agents | Use a MuleSoft MCP server over existing APIs |
| Give agents Salesforce capabilities through a standard interface | Salesforce-hosted MCP servers (standard or custom) |
| Retrieve bulk, non-personalized data from an external system | "Get all customers' invoices," not "refund this specific user" |
How Agentforce connects MCP servers
| Server source | Connect in | Tool management |
|---|---|---|
| External / third party | Agentforce Registry: register from scratch, or install partner servers from AgentExchange | View and allowlist tools in Agentforce Registry |
| MuleSoft | API Catalog | Allowlist tools in API Catalog |
| Salesforce-hosted (standard or custom) | Create and activate in API Catalog, then register in Agentforce Registry | Standard tools are determined by Salesforce; custom tools come from selected APIs |
When you allowlist tools, they're added to the Agentforce asset library as agent actions, available to add to agents like any other action. MCP tool actions are billed at the same rate as other agent actions, and usage appears in Digital Wallet.
Requirements and considerations
| Area | Current rule |
|---|---|
| Transport | Streamable HTTP only. HTTP+SSE and other protocols aren't supported |
| Authentication | No authentication or OAuth 2.0 client credentials only. Authorization code, JWT bearer, PKCE, and other flows aren't supported |
| User-level auth | Not supported. No personalized, per-user operations |
| MCP features | Server tools only. MCP prompts, resources, and apps aren't supported |
| Builder | Agents created in the new Agentforce Builder (Service or Employee). Not legacy-builder agents |
| Timeouts | MCP client 60 seconds; Atlas reasoning engine 120 seconds across calls |
| Response shapes | Best with primitives and shallow structures; complex nested payloads aren't fully supported end to end |
| Changes | Changing a registration or server can break tool actions. Remove the actions from agents, delete them from the asset library, then re-register |
| Packaging | Agents with MCP tool actions can be packaged, but server registrations aren't. Register and allowlist in the new org, then replace the tool actions |
| Getting started | Start in a sandbox with a new agent |
In Script view, don't change an MCP action's developer name (a UUID). You can give it an alias and reference the alias in instructions.
Agent2Agent (A2A)
Purpose
API and MCP integrations give one agent more data and tools. Salesforce's architecture guidance notes that overloading a single agent with too many tools clutters its context and slows or degrades reasoning. A2A distributes work across specialized agents. It uses the reasoning abilities of another agent instead of relying only on the Agentforce agent's own capabilities.
Salesforce was a launch partner for the A2A protocol and contributed the Agent Cards concept. Salesforce's April 2026 integration-pattern guidance describes MCP and A2A support for Agentforce as beta features, so check current release notes for status.
How A2A works
| Stage | What happens |
|---|---|
| Discovery | The remote agent publishes an Agent Card, a JSON metadata document describing its identity, skills and capabilities, supported communication protocols, service endpoint URL, and authentication requirements |
| Authentication | The client agent authenticates with the security scheme named in the card. Agentforce establishes a secure OAuth 2.0 handshake. The remote agent handles authorization |
| Communication | The client sends a task. A2A uses JSON-RPC 2.0 messages, and long-running tasks can stream status updates with server-sent events when the card says streaming is supported |
| Opacity | Agents collaborate without exposing their internal instructions, tools, or memory to each other |
Use cases
- Delegate to a specialized agent. A customer service agent hands a return request to a returns agent, either an Agentforce agent or one provided by an ERP system, that evaluates eligibility and options with its own instructions and guardrails.
- Connect to third-party agents from SaaS vendors, including agents available through AgentExchange.
- Enable outside orchestrators to delegate work to Agentforce agents, extending collaboration beyond the Salesforce platform.
Choosing the Integration Pattern
| Choose… | When… | Example |
|---|---|---|
| Traditional APIs (flow, Apex, external services) | You need precise, deterministic integration with well-understood security, or no MCP or agent exists for the system | Post a payment to a core banking system with strict validation |
| MCP | The external system has (or can have) an MCP server, and the agent should discover and call its tools | Look up shipment status through a logistics provider's MCP server |
| A2A | The job needs another agent's reasoning, instructions, and guardrails, especially across platforms | Delegate a complex return decision to an ERP vendor's returns agent |
| Multi-Agent Orchestration (connected subagents) | Agentforce agents in the same org should work together behind one front door | Orchestrator delegates to billing and HR agents |
| Agent API | An external app or system needs to call an Agentforce agent over REST | Mobile app chat backed by a Service agent |
A simple memory aid: MCP = agent → tool, A2A = agent → agent, API = system → system, with deterministic mapping. Salesforce recommends a proof of concept to confirm which pattern meets your performance and scalability needs.
Scenario Practice
| Scenario | Best answer |
|---|---|
| A partner publishes an MCP server for its contract system, and the agent should look up contract terms | Register it in Agentforce Registry, allowlist the lookup tool, and add the resulting agent action |
| An MCP server requires OAuth authorization code flow for each end user | Not supported today. MCP for Agentforce supports no auth or OAuth 2.0 client credentials, with no user-level auth |
| An external procurement agent should decide how to handle a purchase exception | A2A delegation to that agent |
| An MCP server uses HTTP+SSE transport | Not supported. It needs Streamable HTTP |
| A legacy-builder agent needs MCP tools | Upgrade it to the new Agentforce Builder first |
| The agent must update a specific customer's refund in an external system through MCP | Use an API-based action instead, because MCP for Agentforce doesn't support user-level authentication |
Exam Traps
- MCP connects agents to tools; A2A connects agents to agents.
- Only allowlisted tools become agent actions.
- MCP prompts and resources aren't supported by Agentforce, only tools.
- Agent Cards are A2A discovery documents, not MCP registrations.
- Server registrations don't deploy with agent metadata.
What is the primary purpose of the Model Context Protocol (MCP) in Agentforce?
An admin registers a third-party MCP server in Agentforce Registry. How do its tools become available to add to an agent?
Which statement about current MCP support in Agentforce is accurate?
In the A2A protocol, what does an Agent Card provide?
You've completed this section
Continue exploring other exams