MCP vs A2A: The Agent Interconnection Showdown Between Salesforce and ServiceNow

When external AI tries to call your enterprise agents, Salesforce AgentForce and ServiceNow give completely different answers. One chooses to package agents as tools on an MCP server, while the other opens access through the A2A protocol. There's no winner in this protocol war—only differences in fit for specific scenarios.

Two Paths: MCP Server vs A2A Protocol

According to analysis from a YouTube channel, AgentForce's approach requires users to add agents as tools on a custom Salesforce MCP server. There are two key limitations here: only agents created with the AgentScript builder are supported, and agents run as the logged-in user. This means clear permission boundaries, but flexibility is limited to the Salesforce ecosystem.

ServiceNow takes a more open path. In AI Agent Studio, it allows third parties to access ServiceNow AI agents through the A2A protocol (version 0.3). A2A is designed specifically for agent-to-agent communication, and the version number indicates the protocol is still iterating rapidly.

Both support reverse invocation—that is, enterprise agents calling external MCP tools. But ServiceNow adds a governance layer: only servers approved by AI Control Tower can be called. This reflects ServiceNow's emphasis on security and compliance, making it especially suitable for regulated industries.

AgentScript Builder is Salesforce's low-code/declarative agent development environment for AgentForce. Developers define agent behavior logic, available tools, and data access scope through scripts rather than writing code from scratch. The limitation is that only agents created through the AgentScript builder can be published as tools on an MCP server, meaning agents built through other means (such as external frameworks or custom code) cannot directly connect to this channel. Enterprises need to evaluate rework costs when migrating existing agent assets.

AI Control Tower is a centralized governance component in the ServiceNow platform for AI assets, responsible for registering, approving, and policy-controlling agents, models, and external tool servers. It is not a runtime firewall, but rather establishes a "whitelist"-style admission mechanism before calls occur—only approved external MCP servers are allowed to be called by ServiceNow agents. This design moves governance responsibility forward to the configuration stage, but also requires enterprises to continuously maintain server lists and periodically review them.

The Design Philosophy Behind Protocol Choices

MCP (Model Context Protocol) is essentially a standardized way for AI models to access tools and data sources, treating agents as callable "tools." A2A (Agent-to-Agent) focuses on peer-to-peer communication between agents, closer to the model of service collaboration in distributed systems.

AgentForce's choice of MCP aligns with its platform DNA: Salesforce's core is data and processes, and embedding agents as tools into existing MCP servers maximizes reuse of permission systems and user context. But the two limitations—"only AgentScript builder agents" and "running as the logged-in user"—also mean complex cross-organization, cross-identity invocation scenarios may be restricted.

ServiceNow's choice of A2A is more like building an entry point to the agent internet. Although A2A version 0.3 is not yet mature, the protocol's support for agent discovery and task negotiation leaves room for multi-agent collaboration. AI Control Tower's approval mechanism is a necessary counterbalance to openness—openness does not mean no oversight.

MCP (Model Context Protocol) was proposed and open-sourced by Anthropic. Its core is abstracting external capabilities into three types of primitives: "tools," "resources," and "prompts," which clients (usually AI applications) discover and invoke as needed. It solves the problem of "how models can safely access the external world" and naturally has a client-server hierarchy, so permissions are often bound to the user or application identity that initiates the call.

A2A (Agent-to-Agent) is led by Google and later hosted by the Linux Foundation, positioned for peer-to-peer collaboration between agents. It defines Agent Cards for capability discovery and Task lifecycles for long-running collaboration and state synchronization. Unlike MCP's "invoke tool" semantics, A2A is closer to "delegate task"—the caller doesn't need to know how the other party implements things internally, only needs to negotiate goals and result formats. This is also why it's better suited for cross-organization, multi-vendor agent orchestration.

How Enterprises Should Choose

According to the video's viewpoint, "There's no winner, only differences. Choose the protocol your external AI uses." This actually clarifies the decision logic: it's not about comparing protocol pros and cons, but about what language your external AI ecosystem speaks.

If your agents primarily serve internal Salesforce processes and external callers are willing to adapt to MCP, AgentForce's path is more direct—permission inheritance and tool-based packaging reduce integration costs. But be aware of AgentScript builder limitations and the permission granularity issues that come with running as the logged-in user.

If your enterprise needs to connect with multiple third-party agent platforms, or operates in heavily regulated industries like finance and healthcare, ServiceNow's A2A + AI Control Tower combination provides a more structured governance framework. A2A's agent-to-agent communication semantics are also better suited for complex task orchestration, although the protocol version is still early and carries evolution risks.

One easily overlooked detail is bidirectional capability: both can call external MCP tools, but ServiceNow's approval mechanism means enterprises need to maintain a controlled server list. This increases operational burden but also brings auditability.

The Possibilities and Limitations of Protocol Convergence

MCP and A2A are not mutually exclusive. Theoretically, enterprises can support both protocols: use MCP internally to package tools, and use A2A externally to open agents. But real-world complexity lies in identity mapping, permission propagation, and audit trails—when external AI calls an agent through A2A, and that agent then calls tools through MCP, how do permissions propagate consistently along the call chain?

AgentForce's "running as the logged-in user" simplifies this problem, but sacrifices flexibility for cross-identity calls. ServiceNow's AI Control Tower provides an approval entry point, but the video doesn't elaborate on the runtime permission model. These details will determine the practical feasibility of protocol convergence.

At the current stage, a more pragmatic choice for enterprises is: identify the mainstream protocol of your external AI ecosystem and prioritize adaptation, while retaining a support path for the other protocol to avoid vendor lock-in. The endgame of the protocol war may not be one side winning, but rather protocol conversion services emerging at the gateway layer—but that's another topic.

Identity mapping and permission propagation are the most easily underestimated engineering challenges in protocol convergence. When external AI initiates a request through A2A, the ServiceNow side needs to associate that request with an auditable principal identity; if that agent then calls downstream tools through MCP, the downstream system sees yet another credential system. Cross-protocol call chains require each hop to complete identity transformation and permission convergence (i.e., taking the intersection rather than the union), otherwise permission escalation can easily occur. The industry's current common practice is to introduce short-term tokens and call-chain tracking identifiers, but standardization remains low and vendor implementations vary significantly.

One-line Summary

Salesforce packages agents with MCP, ServiceNow opens access with A2A—the protocol choice depends on the external ecosystem.

Paragraph Summary

The article compares two protocol paths for exposing enterprise agents to external parties: Salesforce AgentForce and ServiceNow. AgentForce requires adding agents as tools on a custom Salesforce MCP server, only supports agents created with the AgentScript builder, and runs them as the logged-in user—clear permission boundaries but limited flexibility. ServiceNow, in AI Agent Studio, allows third parties to access its agents through A2A protocol version 0.3 and uses AI Control Tower to approve callable external MCP servers, emphasizing governance and compliance. Both support reverse invocation of external MCP tools. The article points out this is not a contest of superiority but of scenario fit: choose AgentForce for internal-process-centric use, ServiceNow for multi-platform integration or heavily regulated industries, while noting that identity mapping and permission propagation remain key challenges in protocol convergence.