MCP in Salesforce: How AI Agents Safely Reach Your Org

Why MCP Exists

Before MCP, every time you wanted an AI to touch a system you wired up a one-off integration: this model, that API, custom glue in the middle. Do that across a dozen tools and you have a dozen brittle connections to maintain, each one slightly different. It does not scale, and it breaks quietly.

MCP replaces all of that with one shared way for an AI client to find and call the tools you have approved. Approve a tool once, and any MCP-aware client can use it, under the rules you set. Fewer moving parts, and one place to control access.

What MCP Actually Is

MCP - the Model Context Protocol - is an open standard. Anthropic introduced it in late 2024, and OpenAI, Google, Microsoft, and Salesforce have all adopted it since. It lets an AI client discover and call the tools you have approved, instead of you hand-building a separate integration for every job. People call it the USB-C for AI: one connector, many tools.

Under the hood it is simpler than it sounds. Messages travel as JSON-RPC, either on your own machine (stdio) or over the web (HTTP with server-sent events). If you have used the REST API, the idea will feel familiar: a client asks a server what tools it has, the server answers with a list, and from then on the model can call any of those tools by name.

One Request, End to End

Here is a single request, from a plain-language question to a plain answer. Nothing magic happens in the middle: the model chooses a tool, the server runs it, the result comes back.

MCP or REST: When to Reach for Which

MCP does not replace the REST API, and it does not replace your Apex, Flow, or SOQL skills. It sits alongside them and changes how an AI client finds and uses what you already approved.

The clean split: use REST for fixed, system-to-system integration where you control every call and want the same result every time. Use MCP when a person asks in plain language and the agent has to pick the right approved tool on the spot. One is deterministic plumbing; the other is a way to let a model choose, safely, from a menu you wrote.

One more distinction worth keeping straight: MCP connects an agent to its tools. A sibling standard called A2A connects an agent to other agents. They work together - an agent reaches its tools over MCP and talks to other agents over A2A.

The Salesforce MCP Servers You Will Meet

Salesforce has adopted MCP across the platform, and you will meet it through a few different servers. Pick one based on whether you are building for developers, for Agentforce, or for an outside MCP client. This area moves fast, so treat every status here as "check the current docs before you ship":

• Hosted MCP Servers (GA, Enterprise+). Salesforce-managed endpoints - Salesforce handles hosting, auth, and permissions, and you connect a client over OAuth. The safe default.
• DX MCP Server (Beta). Org management, metadata deploys, and DX tasks from a client like Claude Code, Cursor, or Codex - the developer's entry point.
• Data 360 MCP Server (Dev preview). Open source; connects Data 360 APIs to any stdio client and curates the endpoints so they do not flood the context window.
• Heroku / MuleSoft (Custom). Host a fully custom server in your language of choice, then connect it to Agentforce for scale - for when the hosted options genuinely cannot cover you.

Whichever you use, the safe default is the first-party hosted option, where Salesforce enforces auth and permissions for you. Reach for a custom server only when you have a reason the hosted ones cannot cover.

The Runtime, Wired Up

Put the pieces together and you get the path a request actually travels inside Salesforce. The registry curates the tools, the Trust Layer checks the work, Flow or Apex does the job, and anything risky waits for a person.

The Einstein Trust Layer is the part that earns its keep. It masks sensitive fields before they reach the model, keeps zero retention with the model provider, filters bad output, and writes an audit trail. Readers of the loops guide will recognize what this is: the gate - the check that can fail an agent's work. And it is already built. Lean on it instead of piping raw records to a model yourself.

Two Limits That Shape Design

Two practical limits decide how you build an agent, so it helps to know them up front.

• About 20 tools per agent. An agent handles roughly twenty tools at a time for context reasons. You curate what you expose - the tools a given agent actually needs - rather than pushing your whole API surface into one place.
• Everything runs through a registry. Exposure is controlled by an MCP server registry with allowlists, rate limits, and identity checks. Admins decide exactly which tools and which data reach which agent - which is where your governance lives.

What MCP Changes for Salesforce Admins

Here is the part most MCP explainers skip, and it matters more than the protocol details: MCP quietly redefines what a Salesforce admin is. For fifteen years the admin's power tools were profiles, permission sets, and sharing rules - deciding which humans see which data. The MCP registry is the same job for a new kind of user. Which tools does this agent get? Which objects can that one read? Who approves the risky calls? That is admin work, and nobody else in your org is positioned to do it well.

Two of your existing habits suddenly pay compound interest. First, field and flow descriptions: they used to be documentation nobody read, and now they are literally what the agent reads to understand your org - a well-described schema makes an agent sharper the same way it once made a new hire faster. Second, data hygiene: dirty data used to embarrass a dashboard; now it feeds a confident agent confidently wrong answers. The admins who kept clean orgs out of professionalism just became the most AI-ready people in the building.

So if you are an admin wondering where you fit in the agent era, this is the answer: you are the registry keeper, the gate designer, and the person who decides what the AI may touch. That is not a smaller job than the one you have. It is a bigger one.

Best Practices That Actually Matter

• Lean on the Trust Layer. Use its masking, zero retention, and audit trail rather than sending raw records to a model.
• Least privilege everywhere. Scope OAuth and tool access to the minimum the agent needs, and use role and attribute based rules so access is contextual.
• Curate the tools. Choose the roughly twenty tools an agent needs on purpose. A smaller, sharper set beats a big vague one.
• Prefer the hosted server. Let Salesforce enforce auth and permissions unless you have a clear reason to run your own.
• Test and trace before you trust. Simulate how the agent picks tools, review the logs for risky calls, and throw edge-case prompts at it to see if the guardrails hold.
• Feed it clean context. Good data and well-described metadata are what let the agent understand your org. Describe your flows and fields well and the agent reads that context.

Do This, Not That

The quick reference, earned from real deployments. Do:

• Keep a person on anything that writes to records or touches a customer.
• Start agents on low-risk, well-defined tasks and expand from proven wins.
• Deploy AI-built metadata through your normal review and test pipeline - agent output is still a change.
• Pin tool versions and vet where a server came from.
• Track unauthorized-action attempts and rejected prompts over time - the trend is your early warning.

And the mirror image - do not let the AI both decide the design and build it unsupervised; do not over-provision OAuth scopes or tool access "just in case"; do not blindly trust community or third-party servers; do not assume an error will always show up (dirty data fails silently); and do not schedule anything you have not first made reliable by hand - the same build-order rule the loops guide ends on.

The Risks to Plan For

Because MCP lets outside tools feed instructions and data to a model, it brings real failure modes. Know them so you build the defense in from the start, not after something breaks.

• Tool poisoning. Harmful instructions hidden inside a tool's own description, which the model reads as if it were trusted.
• Rug-pull tools. A tool you approved quietly changes its behavior later.
• Supply-chain holes. A wave of MCP-related security issues turned up in early 2026. Pin versions and vet where a tool came from.
• Prompt injection. Crafted input tries to hijack the agent's instructions. The Trust Layer helps, but it does not make the risk zero.
• Dirty data. The quiet one: no error message, just a confident agent giving confidently wrong answers off duplicate or stale records.
• Hidden validation traps. The agent creates a record fine, a downstream flow updates a related object, and that object's rule fails. Catch these with fault paths.
• Ungoverned tech debt. The real danger is not a bad build - it is building the wrong thing fast, because the AI scaled a decision nobody senior checked.

Every defense is the flip side of a risk: registry allowlists, version pinning, least privilege, the Trust Layer, clean data, and above all a human on the gate for anything that matters.

Green Zones and Red Zones

Once an agent can act through MCP, the question is what you let it act on. Green - let it act: reading and summarizing records or metadata; drafting fields, validation rules, and formulas; running saved, checkable queries and reports; documenting flows and fields; repetitive, schedulable jobs with a clear pass-or-fail check; and opening internal drafts (a case, a task) for a person to confirm.

Red - require a person: unsupervised writes to production; refunds, mass updates, deletes, and customer emails; anything acting on dirty or duplicated data; over-broad OAuth scopes or tool access; untrusted third-party servers; and design or architecture decisions.

Red zones are not "never use AI." They are "never without a person on the gate." The AI drafts and proposes. A person approves.

Your First Safe MCP Connection, This Week

You can feel all of this working without touching production. The developer path is the gentlest on-ramp:

1. PICK    a sandbox org and an MCP client you already use
           (Claude Code, Cursor, or Codex all speak MCP)

2. CONNECT the Salesforce DX MCP server to that client,
           authenticated as a dedicated integration user

3. SCOPE   the user read-only: describe objects, run SOQL,
           read metadata. No create, update, or delete yet.

4. ASK     real questions in plain language:
           "which flows changed this month?"
           "list validation rules on Opportunity"
           "how many Accounts are missing an owner?"

A week of read-only use teaches you how the agent chooses tools, where it shines, and where it guesses - with zero risk to data. Then widen the scope one permission at a time, gates first, exactly like the loops build order: prove it, harden it, then automate it. If your client is Claude, our full connection guide walks the same setup end to end, and the skills library gives your coding agent known-good Salesforce playbooks to work from.

What a Week of Read-Only Actually Looks Like

The first time we connected a client's sandbox this way, the questions started small and got interesting fast. This is the shape of a real first week - the kind of exchange that convinces a skeptical team faster than any slide deck:

DAY 1   "list validation rules on Opportunity"
        agent picks the metadata tool, returns 14 rules with criteria
        -> the team learns it never guesses when a tool fits

DAY 2   "which flows changed this month, and who changed them?"
        SOQL against setup audit data, a table in seconds
        -> the answer used to take one admin twenty minutes

DAY 3   "how many Accounts are missing an owner or industry?"
        agent writes the query, flags 312 records, offers to draft
        a cleanup task list - and asks first, because writes are off

DAY 5   "why would the discount approval skip stage two?"
        agent reads the flow, walks the branch logic in plain English
        -> wrong once all week, and the miss was traceable to a
           stale field description, not the protocol

Notice what the week did and did not prove. It proved the agent picks tools sensibly, that plain-language access changes who can answer org questions (suddenly the ops lead does not queue behind the admin), and that the guardrails hold - the day-three ask-first moment is the registry doing its job. It did not prove the agent should write to production, and that is the point: you earn each widening of scope with evidence, not enthusiasm. The one wrong answer traced to a stale description is also your homework - the agent is only as sharp as the metadata you describe.

Loops Plus MCP: The Full Picture

Put this series together and you have the complete architecture of useful AI in a Salesforce org. Loops give the model a goal, a self-check, and a stop condition - the discipline. MCP gives it a governed way to reach your tools - the hands. The Trust Layer and the registry give you the gates and the audit trail - the safety. Miss any of the three and you get either a chatbot that describes work instead of doing it, or an agent you cannot trust unattended.

This is not theoretical for us: our flagship Agentforce deployment runs goals, gates, and human escalation in production across 12,000+ cases a month at 92% autonomous resolution, and we wire Claude into orgs through exactly the MCP patterns above. If you want the hands-on version - your org, your data, a working read-only agent by Friday - our Salesforce consulting team does this every week.