There’s a moment in every technology’s life when it stops being a demo for developers and becomes something a normal person can actually use. For the Model Context Protocol — MCP — that moment is remote MCP servers and custom connectors. You paste a URL into Claude’s settings, sign in the way you sign in to anything else, and suddenly the assistant can see and use tools from a real system. No terminal. No installation. No config files.
Let me walk you through what’s actually happening, because once you see the pieces, the whole thing stops feeling like a trick.
A one-minute refresher: what MCP is
Anthropic announced MCP in November 2024 as an open standard for connecting AI assistants to external systems. The idea is simple to say and powerful in practice: instead of every AI product building a custom, one-off integration for every tool, everyone speaks one shared protocol.
Think of it like USB. Before USB, every device had its own plug and its own driver disk. After USB, a device that speaks the standard works with any computer that speaks it too. MCP does that for AI: a system exposes its capabilities as an MCP server, and any MCP client — Claude being the one we’ll use here — can connect and use them.
The early days of MCP were very much a developer’s world. Servers ran locally on your machine, you started them from a terminal, and you edited configuration files to wire them up. It worked, and it proved the idea — but I would never have asked a sales manager or an admin-in-training to do any of that.
Enter custom connectors
A custom connector is Claude’s way of connecting to a remote MCP server — one that runs somewhere on the internet instead of on your laptop. And the setup is genuinely short:
- You add the server’s URL in Claude’s settings, under connectors. That URL is the address of the remote MCP server someone (a vendor, your company, or you) has published.
- You sign in via OAuth. The server needs to know who you are, so it hands you off to a familiar sign-in screen — the same pattern as “Sign in with Google” that you’ve used a hundred times. You approve, and you’re back in Claude.
- Claude discovers the tools. This is my favourite part. You don’t tell Claude what the server can do. Claude asks the server, and the server describes its own tools: their names, what they do, what inputs they need. From that point on, Claude can choose to use them in conversation, just like its built-in abilities.
That’s the whole flow. URL, sign in, done. The tools show up, and you talk to Claude normally — “check the status of order 4512” — and Claude decides when a connected tool is the right way to answer.
Why “remote” is the part that matters
If you’re technical, “the server runs remotely instead of locally” might sound like a small deployment detail. It isn’t. It changes who can use MCP at all.
No local install. A local MCP server assumes you have a development environment, permission to install software, and comfort with a terminal. A remote server assumes you have a browser and a login. That’s the difference between “developers can use this” and “your whole team can use this.”
Someone else keeps it running. A remote server is hosted, updated, and monitored by whoever operates it. When it improves, everyone connected to it improves with it. Nobody is debugging a stalled process on their own laptop.
Sign-in means real identity. Because the connection starts with OAuth, the server knows exactly who is calling. It can enforce that person’s permissions — not some shared super-user’s. This one property is going to matter enormously in next week’s article, so hold on to it.
One connector, many users. An admin can stand up (or subscribe to) one remote server, share the URL, and every colleague connects with their own credentials. Compare that with installing and configuring local software on forty laptops.
Twenty years of teaching taught me that the barrier to learning is almost never the concept — it’s the setup. Students don’t quit because an idea is hard; they quit because step three of the installation failed. Remote MCP removes the installation entirely. That’s why I think it’s the version of MCP that will actually reach business users.
What tool discovery feels like in practice
The first time you add a connector, I’d suggest doing what I do with every new tool: ask Claude to describe what it can now do. Something like “What tools do you have from the connector I just added?” Claude will list them, in plain language, because the server described itself in plain language.
This matters more than it looks. In MCP, a tool’s description is how the AI decides when to use it. A well-described tool — “Look up the status of a customer’s existing order by order number” — gets picked at the right moments. A vaguely described one gets ignored or misused. If you’ve read my Agentforce articles, this will sound familiar: it’s exactly how the Agentforce planner chooses actions. Same principle, different protocol. Good descriptions are the craft.
The honest caveats
I promised you honesty, so here are the edges:
- You’re trusting the server. Only connect to MCP servers from sources you trust, the same way you’d only install browser extensions you trust. The OAuth screen tells you what you’re granting — read it.
- Tools are only as good as their design. A connector with sloppy tools produces sloppy results. MCP standardises the plumbing, not the quality of what flows through it.
- The AI still decides when to call tools. Usually it decides well. Occasionally it needs a nudge (“use the order-lookup tool for this”). That’s normal, and it improves as descriptions improve.
None of these are reasons to wait. They’re just the difference between using something and understanding it.
Where this series goes next
Here’s why I’m laying this groundwork so carefully. Everything above — remote servers, OAuth sign-in, per-user identity, tool discovery — is the exact shape of something big that lands next week for Salesforce people. I’ve been building with it in my own org already, and it changes how I think about connecting AI to CRM data.
So: make sure the mental model is solid. An MCP server publishes tools. Claude, via a custom connector, connects to it with a URL and your own sign-in, discovers the tools, and uses them as you. No installs, no middleware, your identity end to end.
Sit with that for a week. Then come back — because the next article is the one where MCP and Salesforce finally meet properly, and I think it’s the most important thing I’ll write in this series.