What Admins Should Know About Salesforce MCP

Every AI tool your team uses (Claude, ChatGPT, a coding assistant, Slack's AI features) needs some way to reach your Salesforce data if it's going to be useful for actual work. Before MCP, that meant a custom integration for each pairing of AI tool and system: one connector for Claude to Salesforce, a different one for ChatGPT to your ERP, another for the coding assistant to your ticketing system. Multiply that across every tool and every system, and the integration work never ends.

Model Context Protocol (MCP) is an open standard that replaces that pattern with one connection per system instead of one connection per tool-and-system pair. Salesforce has built its own implementation on top of it, and as of this year it's live in production for admins to turn on.

What MCP actually is

MCP defines a standard way for an AI application to discover what a system can do and call it directly, the same way a person would use an API, except any MCP-compatible AI client can use it without custom code for that specific pairing. Salesforce's own developer documentation describes it plainly: "MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems."

The practical shift: instead of building a bespoke integration every time a new AI tool needs Salesforce access, an admin configures a server once, and any MCP-compatible client (Claude, ChatGPT, Cursor, a custom agent) connects to it using standard OAuth authentication.

Two directions, not one

This gets confusing because Salesforce is involved in MCP in two separate ways, and a lot of coverage blurs them together.

Salesforce as the thing being connected to

This is Salesforce Hosted MCP Servers: a Salesforce-managed endpoint that exposes your org's data, Flows, Apex actions, and other logic to any external AI client that speaks MCP. If someone is asking Claude or ChatGPT to pull account history from Salesforce, this is what makes that possible.

Salesforce as the thing doing the connecting

This is Agentforce acting as an MCP client, reaching out to external MCP servers so Agentforce agents can use outside tools and data. Salesforce announced this direction alongside Agentforce 3 in mid-2025, with MCP servers from more than 30 partners (AWS among them) discoverable through AgentExchange.

Most of what admins need to understand day to day is the first one: Hosted MCP Servers, since that's the piece that changes what external AI tools can do inside a Salesforce org.

What's live right now

Hosted MCP Servers went through a pilot in spring 2025, a beta starting October 2025, and reached general availability on April 29, 2026, per Salesforce's own developer blog. It's available now for every Enterprise Edition org and above. Salesforce hosts and scales the servers the same way it does REST APIs: nothing to provision, no uptime to manage, enabled in Setup.

What an admin can expose through it, per Salesforce's own documentation:

SObject access: four pre-configured levels (read-and-query only, create-and-update without delete, delete-only, or full CRUD), each respecting the same field-level security, object permissions, and sharing rules already set up in the org, per user, no separate permission model to learn.

Custom tools without new integration code: Apex classes with @InvocableMethod, existing @AuraEnabled controller methods already backing Lightning components, Apex REST endpoints, and Flows built in Flow Builder can all be exposed as MCP tools directly.

Prompt Builder templates, so an org's own curated prompts show up inside a connected AI client rather than living only inside Salesforce.

Data 360 and Tableau Next access, for querying unified customer data and analytics through the same protocol.

The security model

Every MCP transaction runs as the authenticated user, not a shared service account. If an agent updates a record through MCP, that person's name is what shows up in the audit trail, and if their permissions don't allow an action, the agent can't take it either. Access goes through per-user OAuth 2.0 with PKCE, using a dedicated OAuth scope that doesn't extend to Salesforce's existing REST APIs. MCP servers also have to be explicitly enabled per org; nothing is exposed by default.

What to check before turning it on

Since Hosted MCP Servers inherit whatever access a permission set or profile already grants, the actual security review is the same one that mattered before MCP existed: knowing exactly what each permission set grants at the object and field level. Two existing tools cover that from opposite directions: Permission Sets Reporting Helper opens a permission set and shows everything it grants, and Fields Access Explorer starts from a specific field and shows who has access to it. Either one is worth running before connecting any AI client through an MCP server with broad SObject access, not after.

Salesforce's own setup guidance puts the process at under 30 minutes: enable a server in Setup under API Catalog, create an External Client App with the mcp_api and refresh_token scopes, then connect a client, starting with something low-risk like the read-only platform/sobject-reads server in a sandbox before opening up anything broader.

For the deeper access-governance side of preparing an org for AI agents generally, see the Agentforce readiness checklist and the rest of that series. Or start at the Power User Toolkit overview.

Get Power User Toolkit on Salesforce AppExchange →