Connecting Agentforce to an MCP server: giving an agent external tools without hand-building every action

There’s a moment in every Agentforce build where someone asks the agent to do something that lives outside Salesforce. Check a shipment in the logistics system. Look up a ticket in Jira. Query a metric that only exists in Snowflake. The default answer, for the last two years, has been: write a custom Apex action, wire up the callout, hand-author the input and output schema, describe it carefully enough that the agent picks it at the right moment, and maintain that code forever. Do that for every external tool and you’ve rebuilt, one action at a time, an integration layer that already exists somewhere else in your enterprise.

The Model Context Protocol is the standard that’s supposed to end that grind, and Agentforce now speaks it. Instead of hand-building an action per tool, you register an MCP server — Salesforce’s, a partner’s, or your own — and the agent discovers the tools that server exposes, reads their schemas, and calls them through the same reasoning loop it uses for native actions. This post is how that actually works in Agentforce: where you register a server, how governance splits between two different surfaces, what executes inside the trust boundary, and the beta-status and security caveats that decide whether you should point it at anything real yet.

If you want the protocol itself explained from first principles — hosts, clients, servers, the N×M problem it solves — start with our enterprise architect’s guide to MCP. This post assumes that and goes straight to the Salesforce specifics.

Agentforce is an MCP client — and that’s the important half

In MCP terms, Agentforce acts as a client: it connects out to MCP servers and consumes the tools they expose. That’s the direction that matters for most teams, because it means any system that already ships an MCP server — Snowflake, Slack, GitHub, Jira, a custom database, hundreds of others — becomes reachable by your agent without a line of custom integration code on the Salesforce side.

The timeline is worth being precise about, because it decides what you can safely build on today. Native MCP client support entered pilot in mid-2025 and moved to beta in early 2026, expanding through the Summer ‘26 wave alongside Atlas Reasoning Engine 3.0 and multi-agent orchestration. That means the capability is real and shipping, but “beta” is a load-bearing word: features can change, and availability depends on your edition and whether your account is enrolled. Before you commit a production dependency to it, confirm the current release status against the official Agentforce release notes for your org — the surface has been moving fast enough that any date you read in a blog post, including this one, should be treated as a pointer, not a guarantee.

MCP support doesn’t make your agent smarter. It makes your agent’s reach a configuration problem instead of a development project. That’s a bigger deal than it sounds — most agent programmes stall on integration, not intelligence.

There’s a second direction — Agentforce can also be exposed as an MCP server, so other agents and clients can call your Salesforce capabilities through hosted MCP servers. That’s the mirror image and worth knowing exists, but the client direction (Agentforce reaching out) is where the immediate leverage is, and it’s what the rest of this post covers.

The two-surface governance model: API Catalog governs, the Registry composes

Here’s the part that’s genuinely easy to get confused about, because MCP in the Salesforce ecosystem lives across two different admin surfaces with two different jobs. Get this mental model right and the rest of the setup makes sense.

API Catalog is the governance layer — the single pane of glass where a Salesforce admin discovers, approves, and governs MCP servers across the organization. If you run MuleSoft, API Catalog automatically syncs the MCP servers from your Anypoint Platform, so your existing, already-governed MuleSoft integrations show up as AI-ready tools without new wiring. This is where an admin decides which servers the org is allowed to talk to at all and which specific tools on each server are exposed — the allowlist.

The Agentforce Registry is the composition layer — where agent builders discover the approved subset and add specific MCP tools to specific agents in Agentforce Builder. The builder doesn’t get to reach past what the admin approved; they compose agents from the governed catalog.

That split is the whole security story in one sentence: admins govern in API Catalog, builders compose in the Registry, and an agent can only ever invoke a tool that survived both gates. It’s the same separation-of-duties principle we argued for in governing an agent fleet — the person who decides what’s possible shouldn’t be the same person racing to ship a feature.

Registering a server: the mechanics

For a server you’re connecting directly (rather than one syncing in from MuleSoft), the flow lives in Setup and is a guided wizard, not a code exercise:

1. In Setup, go to the Agentforce Registry and click New.
2. Enter your MCP server details — the endpoint and identifying information. The wizard fills in what it can discover for you.
3. Configure the connection, including authentication.
4. Select the specific MCP tools you want to register from that server. This is the allowlist step — you don’t have to expose everything the server offers, and you shouldn’t.
5. Add the approved tools to an agent in Agentforce Builder.

The server on the other end has hard requirements you need to check before you start:

• It must be reachable over the network from Salesforce — a public or properly exposed endpoint, not something only visible inside your VPN.
• It must use the Streamable HTTP transport. MCP defines stdio (local subprocess) and Streamable HTTP (remote) transports; Agentforce connects to remote servers, so Streamable HTTP is the one that applies.
• If it requires authentication, it must support OAuth 2.0. That’s the auth standard Agentforce expects; a server with a bespoke API-key scheme and no OAuth won’t fit the managed flow cleanly.

Once registered, the agent handles discovery itself. The Atlas reasoning engine — in its 3.0 iteration — treats a registered MCP server as an action source: it reads the tool schemas, understands what each tool does from its description, and invokes the right one using the same planner-and-action-selector logic it applies to native Salesforce actions. From the agent’s perspective, an MCP tool and a hand-built Apex action are the same kind of thing. The difference is entirely in how they got there.

The allowlist isn’t optional — it’s the whole design

The single most important habit with MCP in Agentforce is aggressive allowlisting, and there’s a concrete, non-security reason on top of the obvious one.

The obvious reason is data exposure: an MCP server might expose dozens of tools, some of which touch data or actions you never intended an agent to reach. The allowlist is what stands between “the agent can look up a ticket” and “the agent can delete a repository.” As an admin, you control exactly which tools flow through, so users can’t accidentally expose corporate data to tools nobody vetted.

The less obvious reason is model accuracy. There’s a well-observed ceiling on how many tools a reasoning model can juggle before it starts choosing badly — practitioner guidance puts it around 20–25 tools per context before selection accuracy degrades. An MCP server that dumps sixty tools into your agent doesn’t just widen the attack surface; it makes the agent measurably worse at picking the right one. Allowlisting to the minimum set an agent actually needs is a quality control as much as a security control. This is the same discipline that makes scoped topics work: a focused agent outperforms a kitchen-sink one.

The practical rule: register the two or three tools a given agent needs for its job, not the whole server. If a second agent needs different tools from the same server, give it its own scoped set. Breadth is the enemy.

What executes inside the trust boundary

The question every security team asks about MCP, correctly, is: when my agent calls out to some external server, what protects the data on the way? In Agentforce, MCP tool calls execute within the Einstein Trust Layer — the same governance envelope that wraps the rest of Agentforce. In practice that means the call path carries PII masking, field-level security enforcement, OAuth 2.0 authentication, rate limiting, and audit logging, rather than an agent making raw, unlogged calls to the open internet.

That’s real protection, and it’s the reason the managed MCP path is safer than the “just let the agent hit an HTTP endpoint” approach some frameworks take. But two honest caveats:

• The Trust Layer protects the Salesforce side of the boundary, not the server. What happens to your data once it lands in a third-party MCP server is governed by that server’s operator, not by Salesforce. A registered MCP tool is a supply-chain dependency — vet the server’s operator the way you’d vet any vendor with access to your data.
• MCP widens the prompt-injection surface. A tool result that comes back from an external server is untrusted content flowing into your agent’s reasoning. If that server can be manipulated to return crafted text, it can attempt to steer the agent. Everything we wrote about prompt injection and least privilege for agents applies double here — the allowlist and the least-privilege OAuth scope on the server connection are your primary defenses, not an afterthought.

MCP vs. custom Apex actions vs. MuleSoft: which reach do you use?

Registering an MCP server doesn’t retire the other integration paths — it joins them, and the right choice depends on what you’re connecting.

Reach for MCP when the target system already exposes a compliant MCP server (increasingly common for major SaaS and data platforms), or when you want to expose your governed MuleSoft integrations to agents without bespoke action code. It’s the lowest-effort path when the server already exists.

Reach for a custom Apex action when the logic lives inside Salesforce, needs transactional control, or has to run against your org’s data and governor limits directly. MCP is for reaching out; Apex is for doing something inside the platform with precision. The description you write for that action still matters more than the code, which is a point worth re-reading if you’re new to it.

Reach for MuleSoft API actions — now increasingly surfaced as MCP servers through API Catalog — when you need enterprise-grade orchestration, retries, and policy enforcement in front of the systems the agent touches. The lines here are blurring precisely because MuleSoft is becoming a way to produce the MCP servers Agentforce consumes.

And if the thing you’re actually trying to do is put your own agent behind an API for your own app rather than reach out to someone else’s tools, that’s a different pattern entirely — the headless Agent API, not MCP.

What to actually do

MCP support is the feature that turns “integrate the agent with system X” from a development ticket into a configuration decision — and that’s a genuine shift in how fast an agent programme can move. But the speed is exactly why the governance discipline matters: a capability that makes it trivial to give an agent new reach is a capability that makes it trivial to give an agent too much reach.

So: treat the two-surface model as the design, not a detail — admins govern which servers and tools exist in API Catalog, builders compose the approved subset in the Agentforce Registry, and nothing an agent can do escaped both gates. Allowlist ruthlessly, for accuracy as much as security — a handful of tools per agent, never the whole server. Confirm the beta status and your edition’s availability against the current release notes before you build a production dependency on it. Vet every external MCP server as the supply-chain dependency it is, and scope its OAuth grant to the minimum. Do that, and you get the reach without the sprawl. Skip it, and MCP becomes the fastest way yet to hand an agent a capability nobody signed off on.

If you’re deciding whether to connect a system through MCP, a custom Apex action, or MuleSoft — and you want the governance and the trust boundary right before the agent touches production data — talk to us. Designing agents that reach the systems they need without over-reaching is exactly the work we do.

Understanding the basics

Is Agentforce an MCP client or an MCP server?

Both directions exist, but the one that matters for most builds is client: Agentforce connects out to external MCP servers and consumes the tools they expose, so systems like Snowflake, Jira, GitHub, or Slack become reachable by your agent without custom integration code. Agentforce can also be exposed as an MCP server through hosted MCP servers, letting other agents call your Salesforce capabilities — but the client direction is where the immediate leverage is.

How do you connect an MCP server to an Agentforce agent?

In Setup, open the Agentforce Registry, click New, enter the MCP server’s details, configure the connection and authentication, and select (allowlist) the specific tools you want to register. Then add those tools to an agent in Agentforce Builder. The server must be reachable over the network, use the Streamable HTTP transport, and support OAuth 2.0 if it requires authentication. If you run MuleSoft, your Anypoint MCP servers can sync in through API Catalog, which is where an admin governs and approves servers org-wide.

Is Agentforce MCP support generally available?

Treat it as evolving. Native MCP client support entered pilot in mid-2025, moved to beta in early 2026, and expanded through the Summer ‘26 wave with Atlas Reasoning Engine 3.0. “Beta” means it can change and availability depends on your edition and enrollment, so confirm the current status against the official Agentforce release notes for your org before building a production dependency on it.

Is connecting an MCP server safe?

The call path executes inside the Einstein Trust Layer, so it carries PII masking, field-level security, OAuth 2.0 authentication, rate limiting, and audit logging rather than raw, unlogged calls. But the Trust Layer protects the Salesforce side of the boundary, not the third-party server — vet the server’s operator like any vendor with data access. MCP also widens the prompt-injection surface, since tool results are untrusted content entering the agent’s reasoning, so aggressive tool allowlisting and least-privilege OAuth scopes are essential.

---

Trying to decide whether a system belongs behind MCP, a custom Apex action, or MuleSoft — and want the allowlist, the OAuth scope, and the trust boundary right before production? Talk to us. Building agents that reach what they need without over-reaching is exactly the work we do.