Salesforce built Agentforce to let AI agents take real actions inside a CRM, not just summarise records or draft an email. The harder problem, and the one this post actually digs into, is what happens when that agent needs to reach outside Salesforce: into a billing system, a support desk, a data warehouse, or another company’s agent entirely. The Model Context Protocol (MCP) is the piece of plumbing Salesforce has adopted to make that reachable without every integration being a bespoke build.
This is written for a RevOps or sales operations lead who has to make a build decision, not for someone comparing marketing slogans. It covers what Agentforce is and isn’t, how MCP actually works, where the two meet in a real deployment, and the failure modes that show up once agents get write access to production data.
What Agentforce Actually Is (and Is Not)
Agentforce is Salesforce’s layer for building agents that decide which action to take next, rather than agents that just answer questions. An agent is given a role, a set of instructions, and a defined list of actions it is allowed to call: a Flow, an Apex invocable method, a prompt template, or an external tool. The reasoning step is what decides which of those actions fits the situation in front of it, and in what order.
That distinction matters because it means Agentforce is not a replacement for the automation a Salesforce admin has already built. It is closer to a dispatcher sitting on top of that automation. A well built agent calls the same Flow a human user would trigger from a record page; it does not reinvent the underlying business logic in a prompt. Teams that treat Agentforce as a chat interface bolted onto existing automation get further, faster, than teams that try to have the model reason its own way through a process from scratch.
Where this gets harder is when the action an agent needs isn’t inside Salesforce at all: checking a shipping status in a logistics platform, pulling an invoice from a finance system, or updating a ticket in a support tool the CRM has never talked to directly. Salesforce’s own connectors cover a lot of common cases, but they cannot cover every system a given customer runs, and building a custom Apex callout for each one does not scale past a handful of integrations. That gap is exactly what MCP was built to close.
The Interoperability Problem MCP Is Trying to Solve
Before a shared protocol existed, connecting a language model to an external tool meant writing a custom function definition for that specific model host, describing the tool’s inputs and outputs in whatever schema that particular vendor expected. Swap the agent host, or add a second one, and the same tool had to be described again in a different format. With five systems and three agent hosts, that is fifteen bespoke integrations instead of five.
MCP, released as an open standard, defines one interface for exposing a tool, a piece of data, or a reusable prompt to any compliant agent host. A system exposes its capabilities once, through an MCP server, and any MCP-aware client, Agentforce included, can discover and call them without a custom adapter written for that specific pairing. The protocol itself is documented in full at modelcontextprotocol.io, and it is worth reading the specification directly rather than relying on a vendor’s summary of it, since the primitives it defines are what everything downstream depends on.
For a RevOps team, the practical upside isn’t abstract standards compliance. It means the finance system integration built for one agent doesn’t have to be rebuilt when the company adopts a second agent platform for a different function, and it means a Salesforce admin isn’t the only person who can extend what an agent can reach.
How MCP Works Under the Hood
MCP separates three roles: a host application that runs the agent, a client inside that host that manages the connection, and a server that wraps one external system and exposes it in a standard shape. Agentforce plays the host and client role; a system such as a billing platform or a data warehouse sits behind its own MCP server.
Resources, Tools and Prompts
An MCP server exposes three kinds of thing. Resources are read only data the model can pull into its context, such as a customer’s current contract terms. Tools are named actions with a defined input and output shape, such as an action that updates an opportunity’s stage given an opportunity ID and a target stage value. Prompts are reusable instruction templates a server can offer so a host doesn’t need to hard code its own version of a common task. The distinction between a resource and a tool is deliberate: a resource cannot change anything, so exposing more of them is low risk, while every tool is a potential write and needs to be scoped narrowly.
The Client Server Handshake
When a session opens, the client and server exchange a capability list: what resources exist, what tools are callable, what parameters each one takes. From that point, every call is a structured message, typically JSON-RPC, over either a local process pipe or an HTTP based transport for a remote server. The agent never has direct database access; it can only call the specific, named tools the server operator chose to expose. That boundary is the whole point of the model, and it is also where most implementation mistakes originate, because a server that exposes a tool too broadly hands the agent latitude nobody intended it to have.
Where Agentforce Uses MCP in Practice
In a real deployment, an Agentforce agent handling account renewals might need to check a customer’s support ticket history, look up their current invoice status, and confirm contract terms, none of which live in Salesforce. Rather than three custom Apex callouts, each system sits behind its own MCP server: one for the support desk, one for the billing platform, one for the contract repository. Agentforce, as the MCP client, discovers what each one offers and calls the relevant tool when the reasoning step decides it’s needed.
The same arrangement works in reverse. A data analyst using a completely different MCP-compatible assistant to investigate churn risk can reach the same Salesforce data through a Salesforce-side MCP server, without anyone building a second integration for that second tool. This is the actual interoperability benefit: not that agents chat to each other in some abstract sense, but that the integration work for a given system gets built once and reused by whichever agent host needs it next.
General Salesforce platform documentation, including how actions and connected systems are configured, is maintained at developer.salesforce.com/docs, which is the primary reference for anyone building past the marketing description of what an action or a connector does.
Building an Interoperable Agent Stack: A Practical Sequence
Teams that roll this out well tend to follow the same rough order, and skipping a step almost always shows up as a production incident later rather than a clean failure at build time.
First, map the data contract: for each system the agent needs to reach, decide exactly which fields matter, which system is the source of truth for each one, and who in the organisation owns changes to that data. Second, stand up an MCP server per system boundary rather than one server trying to cover everything; a billing platform and a support desk have different authentication models and different rate limits, and conflating them into one server makes a fault in one look like a fault in both. Third, register narrow tools, not whole objects: a tool called update-opportunity-stage with two parameters is safe to reason about; a tool that accepts an arbitrary field name and value is not, because it hands the model the same latitude a database admin has. Fourth, wire Agentforce in as the client and confirm, in a sandbox, that it discovers only the tools intended for that agent’s role, not every tool every server happens to expose. Fifth, add the audit layer, logging every tool call with its inputs and outputs, before any agent is given write access to a system a customer or a regulator would care about.
Governance, Guardrails and Human Oversight
Permission scoping has to happen at two levels, and conflating them is a common mistake. Salesforce’s own permission sets still govern what the agent’s running user can touch inside the org, exactly as they would for a human user. Separately, each MCP tool needs its own scope: a tool that reads a resource should never share a code path with a tool that writes one, even if they touch the same underlying record. Treating MCP as if it were itself a security boundary, rather than a calling convention that sits on top of the org’s existing permissions, is how a narrowly scoped agent ends up with access nobody signed off on.
Actions with a side effect, a refund, a contract change, a data deletion, should sit behind an explicit approval step rather than autonomous execution, at least until the agent has a track record. Read only actions can run without that friction. This split is also where audit logging earns its keep: every tool call, with its full input and output, needs to be retrievable after the fact, because “the agent did something wrong” is a much easier problem to fix when you can see exactly which tool it called and with what arguments.
For any UK organisation, this sits alongside existing data protection obligations rather than replacing them; the ICO’s guidance for organisations, at ico.org.uk/for-organisations, is the reference point for how automated decision making and personal data handling need to be documented, regardless of which agent platform is doing the automating. Equanax has recorded an 86 percent reduction in fixable sync errors across CRM automation work. Tight validation at the point data enters a system is one of the mechanisms that tends to drive results like that, independent of which specific protocol or platform is in use.
Common Failure Modes When Rolling Out Agentforce
Exposing whole objects instead of narrow actions is the most frequent mistake: a tool that lets the model set any field on an Opportunity record invites it to write to fields nobody intended it to touch, simply because the schema allows it. The fix isn’t complicated in principle, name the tool for the exact business action it performs, but it does mean more upfront design work than wiring a generic CRUD wrapper.
Missing idempotency handling is the second most common issue. If an agent’s tool call times out and the host retries it automatically, a write tool without an idempotency key can create a duplicate opportunity, a duplicate contact, or a duplicate invoice line, and nothing in the system will flag it as wrong because both records are individually valid.
A third pattern is session context bleeding across unrelated records: an agent handling one customer’s renewal pulling context from a different customer’s account because the tool’s scoping wasn’t tied tightly enough to the current conversation. Fourth, unversioned tool schemas break quietly when a Salesforce admin renames or removes a field the tool depends on; the agent doesn’t error clearly, it just starts calling the tool with stale assumptions until someone notices the output looks wrong. Building a version check into each tool definition, and testing it whenever a schema change ships, catches this before a customer does.
Frequently Asked Questions
Is the Model Context Protocol a Salesforce technology?
No. MCP is an open standard originally released by Anthropic for connecting AI models to external tools and data sources. Salesforce has built Agentforce to work with it rather than inventing a private equivalent, which is what allows an Agentforce agent and a completely different agent host to reach the same backend system through the same interface.
Does adding MCP support mean Flow and Apex automation become redundant?
No. MCP sits above existing automation rather than replacing it. An MCP tool is usually a thin wrapper around a Flow, an Apex method or an existing API endpoint, so the agent calls automation that already exists instead of the platform rebuilding that logic from scratch.
What is the biggest security mistake teams make when exposing Salesforce data through MCP?
Registering a tool that maps to an entire object, such as a generic update-any-field action, rather than a narrow, named action like update-opportunity-stage. A broad tool gives the model far more latitude than any single business process needs, and that gap is where unintended writes happen.
Do we need a separate MCP server for every system, or can one server cover everything?
In practice, one server per system boundary works better than a single server covering every backend. Each system has its own authentication, its own rate limits and its own data model, and keeping servers separate means a fault or a credential rotation in one system cannot take down access to the others.
Related Reading
- CRM & HubSpot Consulting
- RevOps Consultancy
- AI Deployment
- AI QuickStart Programme
- Case Studies
- Book Your Free Audit
For more on this, see the Salesforce archive, including Automating Salesforce Custom Object Updates with n8n Workflows, Automating Salesforce Custom Objects with n8n for Scalable RevOps, and Salesforce CPQ Automation with N8N: Streamline RevOps Workflows.
Leave a Reply