What is MCP? The Model Context Protocol explained for enterprise architects

Picture the integration review six months into an enterprise agent programme. The service team’s agent reaches the order system through a connector someone built in a sprint. The sales copilot reaches the same system through a different connector — same API underneath, but its own auth handling, its own retry logic, its own hand-written tool definitions. A third pilot, on a third framework, is rebuilding the work again. Nothing is shared. Every new agent platform resets the clock to zero.

That’s the N×M problem: N agent platforms times M enterprise systems equals N×M bespoke integrations, each one a small, undocumented liability. The Model Context Protocol (MCP) is the industry’s answer — an open standard, released by Anthropic in November 2024, that gives AI applications one uniform way to discover and call tools, read data, and reuse prompts from any compliant server. In sixteen months it went from one vendor’s open-source project to a standard adopted by ChatGPT, Gemini, Microsoft Copilot, Cursor, and Visual Studio Code and supported across the Salesforce portfolio.

This guide covers what MCP actually standardizes, how it relates to the APIs you already run, what a server looks like on the wire, where the security risks concentrate, and what Salesforce’s MCP support means for an Agentforce roadmap.

From bespoke connectors to an open standard: why MCP exists

Anthropic open-sourced MCP on November 25, 2024 — a specification, SDKs, and a set of pre-built servers for systems like Google Drive, Slack, GitHub, and Postgres, with Block and Apollo as named early adopters. The pitch was deliberately modest: a universal, open standard for connecting AI systems to data sources, “replacing fragmented integrations with a single protocol.” The official documentation’s analogy has stuck because it’s accurate — MCP is a USB-C port for AI applications. Build a server for your system once, and any MCP-capable client can use it. Build MCP support into your agent platform once, and it can use any server.

The arithmetic is the whole argument. Point-to-point, ten agent surfaces times forty systems is four hundred integrations to build and patch. With a protocol in the middle, it’s fifty: each side implements MCP once, and N×M collapses to N+M. Anyone who has watched connector sprawl eat an integration team’s roadmap knows which curve they’d rather be on. We’ve seen orgs where the same ERP had five differently broken AI connectors before anyone asked why.

What made MCP different from previous plumbing standards is that the vendors with the least incentive to share adopted it anyway. OpenAI added MCP support to its Agents SDK in early 2025, with ChatGPT following. Google’s Gemini and Microsoft’s Copilot products now support it too. Then, on December 9, 2025, Anthropic donated MCP to the Agentic AI Foundation — a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI, with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg. By that point the project counted more than 10,000 active public MCP servers and 97M+ monthly SDK downloads across Python and TypeScript.

For an enterprise architect, the governance detail matters more than the download counts. A protocol owned by one model vendor is a bet on that vendor. A protocol under neutral foundation stewardship — the same institutional family that hosts Kubernetes and Node.js — is infrastructure you can standardize on without writing a vendor’s name into your architecture principles.

What the Model Context Protocol actually standardizes

MCP is narrower than the hype suggests, and the narrowness is its virtue. The official architecture documentation is explicit that MCP “focuses solely on the protocol for context exchange” — it does not dictate how applications use LLMs, how agents reason, or how context gets managed. Three roles, two layers, a handful of primitives. That’s the standard.

Hosts, clients, and servers

The participant model has three parts, and the terminology trips people up because “client” doesn’t mean what it usually means:

• Host. The AI application itself — Claude, ChatGPT, an IDE, or an Agentforce agent. It coordinates everything and owns the LLM interaction.
• Client. A component inside the host that maintains a dedicated one-to-one connection with a single server. A host connecting to five servers runs five clients.
• Server. The program exposing capabilities — your order system, your data warehouse, your ticketing tool. Servers can run locally as a subprocess or remotely as a shared service.

Two layers: JSON-RPC data exchange over pluggable transports

Underneath, MCP is a JSON-RPC 2.0 protocol with lifecycle management on top. A session starts with an initialize handshake in which client and server negotiate a protocol version and declare capabilities — which primitives each side supports, whether the server can push change notifications. It’s a stateful protocol, which is one genuine difference from the stateless REST style most integration teams default to.

Two transports are specified: stdio for local servers running as a child process, and Streamable HTTP for remote servers, which uses HTTP POST with optional server-sent events and supports standard HTTP authentication. Same messages either way; only the pipe changes.

Three server primitives — and a few client-side ones

Servers can expose three kinds of things:

• Tools — executable functions the model can invoke: run a query, create a case, post a payment. Each carries a name, a natural-language description, and a JSON Schema for inputs.
• Resources — data the application can read for context: file contents, schema definitions, records. Context, not actions.
• Prompts — reusable interaction templates a server can offer, such as a standardized triage prompt that pairs with its tools.

Each primitive supports discovery (tools/list, resources/list) so a client can ask a server what it offers at runtime, and servers can send list_changed notifications when their offerings change. The protocol also defines client-side primitives — sampling (a server requests a completion from the host’s model), elicitation (a server asks the user for input or confirmation), and logging — which is how server authors build richer interactions without embedding their own LLM.

That’s the inventory. No agent memory, no orchestration graphs, no agent-to-agent messaging. If someone tells you MCP solves those, they’re selling something.

MCP vs. API: the wrong question, answered properly

“MCP vs. API” is one of the most-searched framings and it’s subtly wrong, because an MCP server almost always wraps your existing APIs rather than replacing them. The REST endpoint still does the work; MCP changes who the interface is designed for. An API is documentation read by a developer at build time. An MCP server is a self-describing interface read by a model at runtime — the client calls tools/list, gets machine-readable descriptions and schemas, and the model decides what to call. Vercel’s engineering FAQ draws the line well: an API is made for apps to call directly, while an MCP server is made for models, providing the metadata that helps a model understand which tools exist, what they do, and when to use them.

The practical differences look like this:

Concern	Traditional API integration	MCP
Designed for	Deterministic code written by developers	LLM-driven applications choosing tools at runtime
Discovery	Human reads docs, writes glue code	Client calls tools/list; contract is machine-readable
Interface contract	Different per API (paths, verbs, auth, errors)	Uniform JSON-RPC methods across every server
Integration count	N×M bespoke connectors	N+M protocol implementations
Session model	Typically stateless	Stateful, with capability negotiation and notifications
Auth (remote)	Varies per vendor	OAuth 2.1-based authorization profile
Replaces your APIs?	—	No; servers typically wrap existing APIs

When shouldn’t you bother? If a tool serves exactly one application on exactly one platform, a direct function-call integration is simpler and Vercel’s guidance says as much. MCP earns its keep when the same capability needs to serve many agent surfaces — which, in an enterprise rolling out agents in the service console, in Slack, and in a developer IDE, happens faster than most roadmaps predict.

What an MCP server looks like in practice

Strip away the abstraction and a working session is four moves. The client connects and sends initialize; the server replies with its capabilities. The client calls tools/list. The host puts those tool definitions in front of the model alongside the user’s request. When the model picks a tool, the client sends tools/call with arguments matching the schema, and the result comes back as content the model can read. Here’s a trimmed tools/list response for a single tool wrapping an existing order-status endpoint:

{
  "tools": [
    {
      "name": "orders_get_status",
      "title": "Order status lookup",
      "description": "Returns the current status, carrier, and estimated delivery date for a customer order. Use when a customer asks where their order is.",
      "inputSchema": {
        "type": "object",
        "properties": {
          "orderId": {
            "type": "string",
            "description": "Order number, e.g. ORD-48291"
          }
        },
        "required": ["orderId"]
      }
    }
  ]
}

Two things about this JSON deserve an architect’s attention. First, the description fields are prompt content. The model reads them verbatim to decide when and how to call the tool, so vague descriptions produce erratic agents, and well-scoped ones (“use when a customer asks where their order is”) do more for reliability than most prompt tuning. Writing tool descriptions is an interface-design discipline, not documentation.

Second, notice how little there is. A useful internal server is often a few hundred lines with an official SDK — the reference implementations and SDKs cover the protocol mechanics, and your code is mostly the thin mapping from tool calls to the services you already run. The hard work, as ever, is deciding what to expose and to whom. Which brings us to security.

MCP security: authorization, tool poisoning, and the server supply chain

MCP inherits every risk of giving software agency over enterprise systems, plus a few of its own. This is where most early deployments go wrong — teams evaluate the protocol and forget to evaluate the servers.

Authorization is specified — insist on it

For remote servers, the spec defines an authorization profile based on OAuth 2.1: the MCP server acts as an OAuth resource server, clients must use PKCE, tokens must be audience-bound to the specific server via RFC 8707 resource indicators, and — critically — token passthrough is explicitly forbidden. A server must not accept a token minted for something else and forward it downstream; the spec’s security best practices document walks through why, from broken audit trails to confused-deputy attacks. In practice this means your MCP estate can and should hang off your existing identity provider, with per-server tokens and least-privilege scopes. The same document warns against omnibus scopes (admin:*) for exactly the blast-radius reasons your IAM team would predict.

Tool poisoning: prompt injection’s supply-chain cousin

In April 2025, Invariant Labs demonstrated tool poisoning attacks: malicious instructions hidden inside a tool’s description — invisible in most client UIs, fully visible to the model — that steered an agent into exfiltrating SSH keys and config files, and even “shadowed” the behaviour of other, trusted servers connected to the same agent. Remember that JSON above? Every description field is text the model treats as instructions. A poisoned server doesn’t need to be called to do damage; being listed is enough.

Microsoft’s guidance on indirect prompt injection in MCP recommends layered mitigations — detection and filtering of embedded instructions, “spotlighting” to mark untrusted content, and treating tool metadata as untrusted input. None of it is exotic; all of it has to be deliberate.

Treat servers as a software supply chain

There are more than 10,000 public MCP servers, and most were published with the review rigour of a weekend npm package. The controls that work are the ones you already know: an internal allowlist of approved servers, version pinning with checksums so a server can’t silently change its tool descriptions after review, egress restrictions on what servers can reach, and audit logging of every tool call. The spec’s security best practices additionally cover session hijacking and confused-deputy patterns for anyone operating shared MCP infrastructure. Least privilege does the heaviest lifting: an agent that can only call orders_get_status can embarrass you, but it can’t empty a table.

What MCP support means for Salesforce and Agentforce architects

Salesforce committed to the protocol early and publicly. In June 2025 it announced MCP support across the portfolio, and the pieces land at different maturity levels — worth reading carefully if you’re planning around them.

• Agentforce as an MCP client. Agentforce gained a native MCP client — agents connecting to any MCP-compliant server without custom code — launched as a pilot with the July 2025 release. As of this writing (April 2026) Salesforce hasn’t announced it as generally available, so confirm current status with your account team before a production roadmap depends on it.
• MuleSoft as the governed gateway. The most production-ready piece. The MuleSoft MCP Server and the ability to convert any API or existing Mule application into an MCP server were generally available at announcement, which means the integration layer you already govern — policies, tracing, traffic controls — can publish agent-ready tools today. If you’ve invested in disciplined integration patterns, MCP is a new front door onto that work, not a replacement for it.
• Salesforce Hosted MCP Servers. Salesforce-managed servers exposing CRM data access, queries, and core actions to any MCP client, with org permissions — CRUD, field-level security, sharing — enforced on every call. These entered beta in October 2025 with general availability targeted for early 2026; as of this writing they remain in beta, so treat dates with the usual safe-harbour caution.
• Developer tooling. The Salesforce DX MCP Server (beta) lets MCP-capable coding assistants run deployments, scratch-org creation, and tests — the lowest-risk place to get hands-on experience.

Our advice for Salesforce shops mirrors what we tell clients about any integration architecture decision: inventory the capabilities agents will actually need, decide who owns MCP server governance before the sprawl starts, and pilot in a sandbox with the beta features rather than waiting for every GA date. The protocol layer is settling faster than the product layer; the skills transfer either way.

Standardize the plumbing, keep the judgment

Protocols win by becoming boring, and MCP is most useful once you see it that way. TCP/IP didn’t make networked applications good; it made the networking stop being the interesting question. MCP is doing the same thing to agent-tool integration. Within sixteen months of release, the connector layer went from a competitive differentiator every vendor rebuilt to shared infrastructure under foundation governance — which means the effort your team was spending on N×M glue code is being handed back to you.

Spend it one level up. The durable, differentiating work is everything the protocol deliberately doesn’t standardize: which capabilities you expose to agents and which you don’t, how sharply your tool descriptions are written, how least-privilege your scopes are, how you review and pin the servers in your supply chain, and whether your audit trail can answer “what did the agent do, and why?” six months after the fact. Those are architecture decisions, and no foundation will make them for you.

The capability to build now is fluency. Stand up one internal MCP server around a system you own. Wire it to two different clients — an IDE and an agent platform — and watch the same tool definitions work in both. Run the security review as if it were an AppExchange submission. Do that once, and the next vendor slide deck about agent integration becomes something you can evaluate in minutes, because you’ll know exactly which parts are protocol, which parts are product, and which parts are still your job.

Understanding the basics

What is the Model Context Protocol (MCP)?

The Model Context Protocol is an open standard, released by Anthropic in November 2024 and now governed under the Linux Foundation’s Agentic AI Foundation, that standardizes how AI applications connect to external systems. Over a JSON-RPC 2.0 session, MCP servers expose tools (executable functions), resources (contextual data), and prompts (reusable templates) that any MCP-compatible client — Claude, ChatGPT, Agentforce, an IDE — can discover and use at runtime.

Does MCP replace REST APIs?

No. An MCP server almost always wraps existing APIs rather than replacing them — your REST endpoints still do the work. What changes is the interface audience: instead of a developer reading docs and writing bespoke glue for each agent platform, the server describes its own tools in machine-readable form and any MCP client can use them. That collapses N×M custom integrations into N+M protocol implementations.

Is MCP secure enough for enterprise use?

The protocol side is solid: remote MCP uses an OAuth 2.1-based authorization profile with PKCE, audience-bound tokens, and an explicit ban on token passthrough. The risk concentrates in the servers themselves — tool poisoning hides malicious instructions in tool descriptions, and thousands of public servers exist with no review. Enterprises should allowlist and version-pin servers, enforce least-privilege scopes, and audit every tool call.

---

Working out where MCP fits in your Salesforce and agent architecture? Talk to us — standardizing the plumbing is what we do.