MCP + Agentforce: Plug Your Agents Into Everything

Model Context Protocol is becoming the USB-C of enterprise AI — here is how it works across Agentforce, MuleSoft and your dev tooling, with a real scenario.

Agentforce Integration

MCP in one minute

Model Context Protocol (MCP) is an open standard, introduced by Anthropic in November 2024, that gives AI agents a uniform way to discover and call external tools. An MCP server exposes tools (functions with typed inputs/outputs); an MCP client — your agent — connects, lists the tools, and invokes them. Before MCP, every agent-to-system integration was a custom action; with MCP, any compliant server is instantly usable by any compliant agent.

In June 2025 Salesforce announced MCP support across its products — and it landed in three places that matter to you.

1. The native MCP client in Agentforce

Agentforce ships a native MCP client, so an agent can consume tools from any MCP-compliant server without custom Apex or middleware. It entered pilot with the July 2025 release and rolled out as beta in January 2026. Alongside it, Salesforce is delivering an enterprise MCP server registry: admins register approved servers centrally, and policy enforcement (identity, security, rate limiting) applies to every tool call an agent makes.

Why the registry matters: the scary part of MCP in an enterprise is agents calling arbitrary tools. The registry flips that — only registered, policy-wrapped servers are reachable, and every invocation is auditable. Check the MCP solutions page in the Agentforce Developer Guide for current availability before building on it.

2. MuleSoft: turn existing APIs into MCP servers

The fastest path to real tools is MuleSoft MCP support (GA). Two options:

Your years of MuleSoft integration work become an AI tool catalog — governed by the same gateway policies you already trust.

3. The Salesforce DX MCP server (for you, the developer)

MCP also runs in the other direction — your development tools as MCP tools. Salesforce open-sourced the Salesforce DX MCP server (@salesforce/mcp on npm), which exposes org operations — query records, deploy metadata, run Apex tests — to any MCP-capable assistant (Agentforce Vibes, Claude, Cursor, VS Code agents). 

// Example MCP client config (e.g. .mcp.json / claude_desktop_config.json)
{
  "mcpServers": {
    "salesforce": {
      "command": "npx",
      "args": ["-y", "@salesforce/mcp", "--orgs", "DEFAULT_TARGET_ORG",
               "--toolsets", "all"]
    }
  }
}

With that in place, "run the failing test class and show me the coverage gap" becomes a one-line request to your AI assistant — it calls the DX MCP tools against your scratch org.

Real-life scenario: order tracking across SAP + logistics

A retailer runs order management in SAP and shipping through a 3PL provider's REST API. Their Agentforce service agent needs to answer "where is my order?" with live data:

Customer ──> Agentforce agent (MCP client) │ ├──> MuleSoft MCP Bridge ──> SAP order API (order status) └──> MuleSoft MCP server ──> 3PL tracking API (parcel events)
  1. The integration team exposes the two existing MuleSoft APIs as MCP tools — no new integration code.
  2. An admin registers both servers in the MCP registry with rate limits and identity policies.
  3. The agent's topic instructs it to resolve the order first, then fetch tracking; the LLM composes the answer from both tool results.
  4. When the 3PL API changes, only the Mule app is updated — the agent keeps working because the MCP tool contract is stable.

Compare that to the pre-MCP approach: two custom invocable actions, Apex callout code, named credentials per system, and a redeploy every time the contract shifts.

Takeaways

Sources: Introducing MCP Support Across Salesforce (June 2025) · MuleSoft MCP servers · MCP Solutions — Agentforce Developer Guide