Here’s a small experiment I like to run with people who are new to AI tools. I ask them to open Claude — or any chat assistant — and type: “How many open Cases do I have in my Salesforce org right now?”
The model can explain what a Case is. It can write you an SOQL query to count them. It can even describe, step by step, where to click in Setup. But it cannot answer the question, because it has no way to reach your org. It’s like asking a brilliant consultant who’s locked in a soundproof room with no phone, no laptop, and no window. All that knowledge, and no connection to your world.
The Model Context Protocol — MCP — is the answer to that problem. And because I’ve spent the last while actually building with it (more on that later in this series), I want to walk you through it the way I’d walk a student through any new idea: slowly, concretely, and honestly about what it is and isn’t.
Why models are sealed off in the first place
A language model, on its own, is a text machine. Text goes in, text comes out. Everything it “knows” was baked in during training, which means it knows nothing about your data: your Accounts, your Opportunities, the spreadsheet on your desktop, the database behind your app.
For a long time, the workaround was copy-paste. You’d copy a record’s details into the chat, the model would reason about it, and you’d copy the answer back out. It works, but you are the integration. You’re the cable between the model and your systems.
The obvious next step was to build real integrations — code that lets the model call your systems directly. And that’s where things got messy.
The N×M problem
Imagine you have M AI applications (Claude Desktop, an IDE assistant, a chat app) and N systems you care about (Salesforce, GitHub, a Postgres database, your file system). If every app needs its own custom integration to every system, you’re building M × N connectors. Ten apps and ten systems means a hundred integrations — each one written differently, maintained separately, breaking in its own special way.
I lived a version of this in the Salesforce world for years. Before standards, every system spoke its own dialect and every connection was a bespoke project. It doesn’t scale. It never scales.
MCP’s core idea is beautifully simple: agree on one protocol, and the problem becomes M + N. Each AI application implements MCP once. Each system exposes an MCP server once. Now any MCP-capable app can talk to any MCP server — ten apps plus ten systems is twenty pieces of work, not a hundred.
This is why people call MCP the “USB-C port for AI.” Before USB-C, every device had its own charger and its own cable drawer full of regret. After USB-C, one port fits everything. MCP aims to be that port: a single, standard way for AI applications to plug into data and tools.
So what exactly is MCP?
MCP is an open standard announced by Anthropic on November 25, 2024. Let me unpack those words, because each one matters.
Open means the specification is public and anyone can implement it. It isn’t locked to one vendor’s products. The full documentation lives at modelcontextprotocol.io, and there are official SDKs in Python and TypeScript so you don’t have to build the plumbing yourself.
Standard means it’s a protocol — an agreement about how two pieces of software talk to each other. Under the hood, that conversation happens over JSON-RPC, a lightweight message format. You don’t need to memorize that today; just hold onto the idea that MCP defines the language, not the participants.
And the structure of the conversation is simple to say out loud: an MCP server is a small program that sits in front of something useful — a database, an API, your Salesforce org — and offers its capabilities in a standard shape. An AI application connects to that server and can then see and use those capabilities. The model in the soundproof room finally gets a phone line.
One sentence to keep: MCP is a standard way for AI applications to discover and use external tools and data, so every integration doesn’t have to be invented from scratch.
What MCP is not
Twenty years of teaching taught me that a new concept only sticks when you also draw its edges. So let me be precise about what MCP is not:
- It’s not a product. You can’t buy MCP or install “the MCP app.” It’s a specification — like HTTP is a specification. Products implement it.
- It’s not a model. MCP doesn’t make the model smarter. It gives whatever model you’re using a standard way to reach outward.
- It’s not an agent framework. MCP doesn’t decide what the AI should do; it defines how capabilities are offered and called. The reasoning still belongs to the model and the application around it.
- It’s not a free-for-all. The protocol is designed with a human in the loop: the user is asked for consent before consequential actions run. The model can propose creating a record; you approve it.
That last point deserves a highlight, because it’s the first question every admin and architect should ask. An AI that can touch real systems is powerful, and MCP’s design acknowledges that power belongs behind a consent step, not around it.
Who’s behind it, and why I trust the direction
MCP was created and open-sourced by Anthropic, the company behind Claude. But the open-standard framing is the important part: the spec, the SDKs (Python and TypeScript), and the documentation at modelcontextprotocol.io are public, and the whole point is that anyone — any app, any vendor, any solo developer — can build to it.
Standards succeed when they’re boring and shared. USB-C won not because it was clever but because everyone could adopt it. MCP is making the same bet.
Why a Salesforce person should care
Fair question — this is a Salesforce blog, after all. Here’s my honest answer: MCP is the bridge between the AI tools you already use and the org you already run.
I’ll give you a preview of where this series goes. I’ve exposed custom Apex as MCP tools, so Claude can call logic in my org directly — real Apex, invoked from a chat window, with me approving each consequential step. I’ve gone further and designed an agent loop that built out an entire Salesforce org — objects, automation, the lot — through that same standard plug. Once the port exists, what you can plug into it gets interesting fast.
None of that required a custom integration invented from zero. That’s the M + N promise, and it’s not theoretical anymore.
Your next step
Today you only need one mental picture: models are sealed off, custom integrations don’t scale, and MCP is the shared port — a spec, not a product, announced by Anthropic in November 2024, documented at modelcontextprotocol.io — that turns N×M chaos into M+N order.
This post kicks off a new weekly Friday series on MCP. Next Friday we’ll open up the machine and meet the three moving parts — the Host, the Client, and the Server — and see who actually does what when Claude reaches into your systems. Bring your curiosity; I’ll bring the diagrams-in-words.