In Part 1 we covered what MCP is and why Salesforce hosting the server changes the picture. Now we get practical: turning the thing on.
Since Hosted MCP Servers went GA on April 29, 2026, the whole configuration lives in one place — the MCP Servers page in Setup. You do two things there: activate a server, and choose which tools it exposes. That second step sounds administrative. It isn’t. It’s the most important design decision you’ll make in this entire setup, and I want to spend most of this article on it.
Finding the page
Open Setup and search for MCP Servers. That’s the control panel for everything we’ll do in this series.
From here you can activate a server for your org and manage its tool list. Activation itself is the boring part — you switch the server on, and it becomes something an external AI client can connect to. No infrastructure to stand up, no gateway to deploy, no middleware to babysit. Salesforce hosts it; you configure it.
If you’ve ever built the do-it-yourself version of this — a Node process on a server somewhere, holding credentials, translating between an AI client and the Salesforce APIs — you’ll appreciate how much is simply gone from your plate. The hosted server handles the plumbing. Your job is deciding what flows through it.
Choosing tools: the real work
When you activate a server, you choose which tools it exposes. A tool, in MCP terms, is one capability the AI client can discover and call — one action with a name, a description, and defined inputs and outputs.
Here is the mindset shift I want you to make before you touch that list.
You are not asking: “What can this org do?”
You are asking: “What should an AI be able to do here?”
Those are very different questions. Your org can do thousands of things. That does not mean an AI assistant, acting on behalf of whoever signed in, should have all of them within reach.
Less is more — and I mean that technically, not just cautiously
There’s an obvious safety argument for a short tool list, and it’s valid. But there’s a second argument people miss: a short tool list makes the AI more accurate.
When a client like Claude connects to your server, it discovers the available tools and reads their descriptions. Every time you ask it to do something, it reasons over that list to pick the right tool. Twelve well-chosen tools with clear descriptions? It picks correctly almost every time. Eighty overlapping tools with vague names? It hesitates, picks the almost-right one, or chains three tools where one would do.
I spent twenty years teaching before I came to Salesforce, and this is the same principle as writing an exam. If you want a student to demonstrate one skill, don’t bury the question in noise. The model is your student here. Give it a clean question.
A concrete example from my own org
In my Urla Shoes demo org, I expose exactly two custom tools alongside the basics:
- LeadQualificationService — scores a lead Hot, Warm, or Cold (with a bonus for our DACH markets — Germany, Austria, Switzerland) and auto-creates a follow-up call task.
- OnboardReseller — takes a new reseller, derives their tier (Platinum, Gold, or Silver) and commission, and creates the Account, Contact, Opportunity, and Quote in one motion.
Both started life as ordinary Apex @InvocableMethod actions. Exposed as MCP tools, one plain-language request in Claude — “qualify this lead from Munich” or “onboard this reseller” — runs the whole flow. We’ll build a tool like this from scratch in Part 4.
Notice what I didn’t expose: generic delete tools, mass-update tools, anything touching setup. Not because the platform couldn’t secure them — every call runs as the authenticated user with their real permissions — but because nothing in my use case needs them. Every tool on the list earns its place by answering a question I actually expect someone to ask.
A simple worksheet for your tool list
Before you activate anything, sit down — away from Setup, ideally with coffee — and answer these:
1. Who will connect, and why?
Be specific. “Sales reps asking Claude to qualify inbound leads” is a use case. “People using AI with Salesforce” is not. Every tool should trace back to a sentence like the first one.
2. For each candidate tool: what’s the worst reasonable misuse?
Not malice — misunderstanding. The AI calls tools based on natural language, and natural language is fuzzy. A read-only lead lookup called on the wrong lead is a shrug. A tool that creates four records is worth a moment’s thought about what a confused request produces. This doesn’t mean don’t expose it — my OnboardReseller tool creates four records and I expose it happily. It means know the answer before you flip the switch.
3. Would I be comfortable seeing this call in the audit log with a colleague’s name on it?
Because that’s exactly what happens. Every MCP call runs as the authenticated user and is fully audited. This question has a way of clarifying things quickly.
The security floor is solid — that’s not an excuse to skip the thinking
I want to be honest about both sides here, because I’ve seen people land on each extreme.
The platform’s guarantees are real: the user signs in as themselves via OAuth, every tool call executes with that user’s permissions, and if your Apex uses WITH USER_MODE (it should — Part 4), field- and object-level security hold all the way down. The AI cannot see or touch anything the human couldn’t see or touch in the UI. And the audit trail records everything.
So no, you’re not one checkbox away from disaster. But permissions answer “is this allowed?” — tool selection answers “is this a good idea?” A sales rep is allowed to edit hundreds of records one at a time in the UI. Handing an AI a tool that does it in one call is a different proposition, even though the permission math is identical. The platform enforces the floor. You design the room.
Start narrow, widen deliberately
My honest recommendation for your first activation:
- Activate the server with the smallest tool set that serves one real use case. Two or three tools is a perfectly respectable start. That’s what I did.
- Live with it for a week or two. Watch what people actually ask for. The requests that fail because no tool exists are your roadmap.
- Add tools one at a time, each justified by observed demand, running each through the three questions above.
Growing a tool list is easy and instant — it’s a Setup change. Shrinking one after people have built habits around it is a harder conversation. Start from a position you’d be happy to defend.
What’s next
Your server is on and its tool list is short and deliberate. In the next article we connect the other end: adding your server to Claude as a custom connector, signing in with OAuth, and watching your tools appear in a real conversation. That’s where this stops being configuration and starts being genuinely fun.