The Best MCP Gateways for Salesforce Agentforce in 2026

An MCP gateway gives Salesforce Agentforce one governed connection to the systems it can’t reach natively — Workday, ServiceNow, NetSuite — as a single MCP server URL registered in the Agentforce Registry, with curated tools, per-user credentials, audit logs, and injection scanning on every tool response. Agentforce already governs its own side well: the registry allowlists tools, the Einstein Trust Layer wraps the agent. The gateway governs what sits behind the registered URL. Our verdict: StackOne for cross-system depth under Salesforce’s ~20-tool-per-agent budget; MuleSoft if you’re an Anypoint shop that prefers building; Zapier for breadth-first pilots.

This is the Agentforce edition of our MCP gateway comparison — same criteria, applied to Agentforce’s constraints.

How does Agentforce connect to MCP servers today?

Agentforce 3, announced June 23, 2025, introduced native MCP support: Agentforce agents can consume external MCP servers as tools. The rollout has been deliberate — pilot in July 2025, Beta in January 2026, still Beta as of June 9, 2026. Salesforce’s Summer ‘26 platform release is rolling out now — production waves ran May 15 through June 13, per Salesforce’s Summer ‘26 developer guide — but that guide and the Summer ‘26 release summaries don’t announce GA for the MCP client, and Salesforce has not published a GA date for it. Check your org’s release notes.

The connection model is admin-led end to end (flow per implementation-partner write-ups, March 2026 — verify against your org’s Setup UI):

1. An admin registers the MCP server’s URL in Setup, in the Agentforce Registry.
2. The registry validates the server and pulls its tool manifest.
3. The admin builds an allowlist of permitted tools — nothing is exposed by default.
4. Each allowed tool becomes an action in the Agentforce Asset Library.
5. Agent builders add those actions to agents in Agentforce Builder.

Salesforce positions the registry as “one orchestration layer for governing which agents connect, what tools they access”, with enterprise-grade policy enforcement spanning security, rate limiting, and identity.

One constraint shapes everything else on this page. Salesforce’s own Agentforce MCP beta announcement states that “there’s roughly a 20 tool limit on the number of tools you can run at the same time,” for context-window management — alongside platform limits of 15 topics per agent and 15 actions per topic reported across Salesforce’s Agentforce considerations docs and partner guides. (One editorial note for the whole page: Salesforce’s marketing and pricing pages block automated retrieval, so where we rely on them we quote indexed copies — and a beta-stage limit can change, so verify the numbers in your org.) The design pressure is real either way: an MCP server that publishes 300 tool definitions doesn’t fit Agentforce’s model.

MCP isn’t the only path. Agent actions can also come from Flows, Apex @InvocableMethod classes, prompt templates, External Services (OpenAPI specs plus named credentials, since Spring ‘25), and MuleSoft for Agentforce. AgentExchange — Salesforce’s agent marketplace, launched March 2025 with 200+ partners — added MCP servers from 30+ partners at Agentforce 3.

Salesforce MCP server vs Agentforce MCP client: which direction do you need?

Salesforce’s own MCP servers run the opposite way: Salesforce Hosted MCP Servers went GA in April 2026 (Enterprise Edition and up), exposing Salesforce data, Flows, and Apex to external AI clients with OAuth 2.0 + PKCE, per-user identity, and a dedicated mcp_api scope. That’s Salesforce as a server — and if what you actually want is an AI client like Claude acting on Salesforce, that’s the direction StackOne’s Salesforce MCP connector serves, with 380 actions. Agentforce consuming external MCP servers — the direction a gateway plugs into, and the subject of this page — is the side still in Beta.

What Agentforce’s native controls don’t cover

The Agentforce Registry and the Einstein Trust Layer govern Agentforce. They don’t govern the MCP servers, tools, credentials, and data behind a registered URL — that’s the gateway’s job, underneath Salesforce’s controls, never instead of them.

• The registry allowlists tools; it doesn’t supply or curate them. It governs which tools an agent may call, not whether those tools are well-named, scoped to the right fields, or few enough to fit the ~20-tool budget. The manifest is whatever the server behind the URL publishes.
• Data masking is currently disabled for agents. Per Salesforce’s Trailhead module on the Einstein Trust Layer, masking applies to embedded features like Einstein Service Replies but is “currently disabled for agents.” If an external tool returns salaries or SSNs into an agent conversation, the Trust Layer won’t redact them today.
• Prompt defense is hedged by Salesforce itself. It “can help protect” against prompt injection and “decrease the likelihood” of attacks (Salesforce documentation) — careful language, and it concerns the prompt side. Tool responses from external systems entering the agent’s context are a separate injection surface.
• Per-user credentials for external systems are yours to build. Salesforce’s own model is clean: employee agents run as the logged-in user; service agents run as a dedicated agent user with its own permission sets (Salesforce Help, agent users). Outbound, named credentials offer a Named Principal (shared identity) or Per-User Principal (acts as the individual) — but someone still operates that lifecycle per external system, per user.
• Audit ends at the boundary. The Trust Layer’s audit trail and Agentforce Command Center (GA August 2025) record what the agent did. What happened inside Workday or ServiceNow on each tool call needs logging on the other side of the URL.
• Every action costs money. Per Salesforce’s May 2025 Flex Credits pricing announcement and secondary coverage (verify current pricing with Salesforce), Flex Credits run $500 per 100,000, a standard action consumes 20 credits ($0.10), with a $2-per-conversation option. An agent choosing among sprawling, vague tools burns paid actions on wrong calls; a curated surface is an economic feature, not just a context-window one.

What to look for in an MCP gateway for Agentforce

The best MCP gateways for Agentforce, compared

The comparison set differs from our hub post: MuleSoft is the native baseline here, and self-hosted routing gateways matter less when Salesforce’s registry already governs the routing side.

1. StackOne

StackOne is the enterprise layer for AI agents to safely act on any application — 310+ managed connectors exposing 20,000+ agent-optimized actions across HRIS, ERP, CRM, and ITSM, behind one URL.

• The tool budget stops being a constraint. With StackOne’s Tool Search, agents get two meta-tools, search and execute, instead of thousands of definitions. Two tools cover Workday (128 actions), Jira (147 actions), and the rest of the catalog; context stays constant whether an integration has ten actions or ten thousand (a 460× reduction versus loading every definition), and the search half is accurate enough to carry that design — 92.8% first-try accuracy, the leading score in our published comparison. In Agentforce, picking the right tool first try is also a billing event: every action is metered in Flex Credits, so retrieval accuracy is an economic feature too.
• The registry allowlist still governs — it just governs at a different altitude. In meta-tool mode, the manifest the Agentforce Registry pulls contains those two tools, and the admin’s allowlist governs them. Per-action control doesn’t disappear; it moves to StackOne connector profiles, where admins scope which actions search can return and execute can run — the profile’s action scoping is what you walk a security reviewer through. Admins who want the registry allowlist itself as the per-tool control point can expose individual curated actions instead of the meta-tools (tool modes) and accept the ~20-tool budget as the trade.
• Per-user auth behind the gateway. An OAuth 2.1 flow where the end user authorizes themselves gives the systems behind the gateway the equivalent of Salesforce’s Per-User Principal.
• Governance that covers the masking gap. Admins scope actions per connector profile and can define custom versions of actions that never return non-compliant fields — directly covering the masking-disabled-for-agents gap — while request logs capture every call down to provider requests and StackOne Defender scans tool responses for prompt injection (89.0% detection accuracy in our published evaluation). SOC 2 Type II, GDPR, HIPAA.

Limitations: the catalog focuses on business systems, not consumer applications — for the consumer-app long tail, Zapier’s catalog is far bigger, though when a system isn’t in the catalog, the AI Connector Builder builds or extends a connector on the same engine that powers the pre-built ones.

Best for: Agentforce teams whose agents must act on systems of record beyond Salesforce, under IT sign-off.

MuleSoft MCP Connector (the native baseline)

The fair first comparison for any Salesforce shop. The MuleSoft MCP Connector v1.6 turns Mule apps into MCP servers (and clients) over Streamable HTTP (SSE is deprecated), and MuleSoft for Agentforce plus Topic Center wire Anypoint assets into agents. If your integration estate is already API-led on Anypoint, this path keeps everything with one vendor: same support contract, same governance stack.

It’s an integration-platform build motion, not a managed connector catalog. You build and host a Mule app per system, design every tool’s name and description yourself (what the registry manifest and the agent’s tool selection both depend on), and maintain it as provider APIs change. Fine for a team with Anypoint skills and a contained system list; as a route to fifty deep external connectors, it’s the line item that dominates total cost. Pricing isn’t published.

Best for: existing Anypoint enterprises with MuleSoft engineers and a short list of target systems.

2. Zapier MCP

Zapier MCP brings the largest catalog in this comparison — 9,000+ apps, 30,000+ pre-built actions — riding on 13+ years of auth infrastructure, with no-terminal setup and workable pilot governance (allowlists, approvals, history log). For an Agentforce pilot touching consumer-grade SaaS, your existing Zapier connections carry over and there’s nothing to host. The Agentforce-specific caveats: the catalog’s size works against the ~20-tool budget — you must curate each agent’s tool list down hard; actions are automation-shaped, broad rather than deep; and cost stacks — each MCP call consumes two Zapier tasks on top of the Flex Credits the action already burned.

Best for: breadth-first Agentforce pilots by teams already paying for Zapier.

3. Composio

Composio offers 1,000+ toolkits and 20,000+ tools with genuinely good SDKs, published pricing (free tier, from $29/month), and per-user connected accounts via Connect Link — a real per-user-principal story. It’s developer-led, though: as of June 9, 2026 we couldn’t find an org-level control plane (central policy, approval workflows) in its public docs. The Agentforce buyer is an admin working through a registry allowlist and an IT review — for that buyer, that’s the entire question.

Best for: developer teams prototyping Agentforce tool integrations ahead of an IT-led rollout.

4. Merge Agent Handler

Merge’s Agent Handler includes inline runtime security controls: DLP scanning on tool-call inputs and outputs, guardrails that block, redact, or mask, audit logs on all plans, SCIM, SOC 2 — relevant to the masking-disabled-for-agents gap. What’s missing is published depth on the agent side: the catalog is summarized as “thousands of tools”, and while Merge documents per-integration coverage for its Unified API, Agent Handler doesn’t publish a per-system tool catalog to verify against your Workday or ServiceNow requirements, and pricing is credit-metered (free tier; Pro $1,000/month for 25,000 credits).

Best for: teams that want DLP-style redaction bundled into a managed tool-call path — verify per-system tool coverage on your systems first.

How to connect StackOne to Agentforce

What the admin does (the registry path is still Beta — re-verify each step in your org):

1. Register StackOne’s MCP URL in Setup, in the Agentforce Registry. One URL covers the whole catalog. StackOne’s endpoint is a managed remote MCP server with OAuth 2.1 authorization — the shape the registry’s documented server requirements ask for. Registration is also where you configure how your org authenticates to the server; the registry’s Beta docs describe its supported credential options, so match StackOne’s authentication setup to whichever your org uses and verify the pairing in Setup.
2. Let the registry validate and pull the manifest. In search-and-execute mode, the manifest contains StackOne’s two meta-tools — named and described for allowlisting, not raw API dumps; in individual mode, it lists each enabled action as its own tool.
3. Allowlist the tools. With meta-tools, the registry allowlist governs the two tools the agent may call; per-action control happens in StackOne connector profiles, where admins scope which actions search can return and execute can run — so only the actions you intend to expose are reachable behind the URL.
4. Find the tools in the Asset Library as actions, and add them to agents in Agentforce Builder.
5. End users link their accounts for the systems behind the gateway through StackOne’s OAuth 2.1 flow — SSO sign-in, consent screen, per-account opt-in. That’s the employee-agent pattern, mirroring Salesforce’s Per-User Principal. For service agents — which run as a dedicated agent user, not a logged-in employee — link a scoped service account instead (the equivalent of Salesforce’s Named Principal), restricted through the same connector profiles.

The admin sees registry entries, the allowlist, Asset Library actions, and StackOne’s request logs per tool call. The end user sees an agent acting on their Workday or ServiceNow data as them, after a one-time account link.

When you don’t need a gateway for Agentforce

• Your agents only act on Salesforce. Flows, Apex, and prompt templates cover Salesforce-side actions natively, under the Trust Layer, with no external URL to govern.
• One or two external APIs, technical team. External Services with an OpenAPI spec and named credentials is simpler for a contained surface.
• You’re a deep Anypoint shop with a short system list. MuleSoft’s MCP Connector keeps the stack with one vendor — the build cost is real but already staffed.

The trigger points mirror the hub post’s: the first security review of agent actions on external systems, the first “which tools can this agent see?” conversation, and the first user asking IT to connect an account for them.

StackOne is the governed layer between AI agents and 310+ enterprise systems with 20,000+ agent-optimized actions — over MCP, A2A, API, and SDKs — with end-user OAuth linking, connectors you can extend, and built-in prompt-injection defense. See the full MCP gateway comparison, explore StackOne MCP, or start with a connector: Salesforce, Workday, Jira. See pricing or book a demo.

More MCP gateway guides

Every guide in this series applies the same disclosed criteria to a different AI client. Start with the full comparison, or jump to yours: