Model Context Protocol
MCP connects AI assistants like Claude to the real systems where your work actually lives — safely, and through one shared interface.
Large language models are excellent at reasoning, but on their own they are sealed off from the world: they can't read your files, query your database, or take an action in your CRM. The Model Context Protocol (MCP) fixes that. It's an open standard — introduced by Anthropic in November 2024 and now adopted broadly across the industry — that gives AI a single, universal way to connect to external tools and data. Think of it as a USB-C port for AI: build one connector, and any MCP-compatible assistant can plug in.
Watch first
A full 24-minute walkthrough: what MCP is, how to connect Claude to a Salesforce Hosted MCP Server, and a live example turning plain language into real Salesforce actions.
MCP is a specification, not a piece of software you buy. It's open-sourced, with official SDKs in Python, TypeScript, and more. Any application can implement it, and it isn't tied to a single vendor or model — the same server works with different AI clients.
Before USB-C, every device needed its own cable. Before MCP, every AI-to-tool integration was hand-built and one-off. MCP is the universal port: define your connection once, in a standard shape, and everything that speaks MCP can use it.
With M AI apps and N tools, bespoke integrations mean M×N connectors to build and maintain — it explodes. MCP turns that into M+N: each app speaks MCP once, each tool exposes an MCP server once, and they all interoperate. Less glue code, more reuse.
MCP has three moving parts. They talk to each other over JSON-RPC — locally (stdio) or remotely (HTTP) — with the user always in control.
The AI application you interact with — Claude Desktop, claude.ai, or an IDE. It runs the model, orchestrates the conversation, and asks for your consent before anything consequential happens.
A connector that lives inside the host and manages one dedicated session with a single server — handling the handshake, the message passing, and the lifecycle of that connection.
A lightweight program that exposes the capabilities of one specific system — a database, an API, a filesystem, or a SaaS product like Salesforce. It advertises what it can do; the host decides when to use it.
Every MCP server offers up to three kinds of capability. Together they cover reading context, taking action, and reusable workflows.
Functions the assistant can call: create a record, send a message, run a query, kick off a job. The model decides when a tool is needed — and the host asks for your approval before it runs anything with real-world effects.
Content the assistant can pull in for context: files, records, documents, rows from a table. The application controls exactly what is exposed, so the model only sees what it's meant to.
Parameterized templates and flows a user can invoke on demand — a 'summarize this ticket', 'draft a quote', or 'review this PR' recipe — so best-practice prompts become one-click, shareable actions.
Where I use it
This is exactly where I work. As of April 2026, Salesforce Hosted MCP Servers are generally available — managed, Salesforce-hosted endpoints that expose an org's data, flows, and custom Apex to AI clients over MCP, with the org's own security still enforced. You set one up on two Setup pages: an External Client App (the OAuth bridge, with least-privilege scopes and PKCE) and MCP Servers (activate a server and choose the tools). Then you add the server's URL to Claude as a custom connector, sign in, and Claude discovers the tools. I did exactly this with my Urla Shoes org: two custom Apex @InvocableMethod actions — lead qualification with DACH-aware scoring, and reseller onboarding with automatic tier + commission — exposed as MCP tools via an McpServerDefinition, so a single plain-language request to Claude could qualify a lead or spin up a full deal (Account, Contact, Opportunity, Quote) inside Salesforce.
And in the opposite direction
The example above is Claude reaching into an existing Salesforce org. I also ran it the other way round: I designed an agentic loop that builds an org from nothing. A complete hospital-management org — 7 custom objects, a trigger-handler architecture, 90–100 % test coverage — delivered through six custom MCP deployment tools, with ApexTestRunner as the verifier: deploy → test → read the failures → fix → repeat, until the tests go green. The model doesn't decide when it's done; the test runner does. That's the difference between prompt engineering and loop engineering.
I build Salesforce + AI integrations — Agentforce, Einstein, and MCP connectors that let AI act safely inside real orgs. Let's talk.