The standard hosted MCP servers only give Claude generic CRUD. This guide covers building your own MCP server — bundling your Apex actions, Flows, and REST endpoints (plus any standard tools you want alongside them) under a single URL Claude can call.
Companion to the Salesforce MCP Server → Claude guide — do that one first if you haven't, since custom servers reuse the same permission set and External Client App.
User Interface → Enable MCP Service (Beta), same switch as the companion guide) and the MCP Client User permission set from Phase 2 of that guide.
sobject-reads, sobject-all, etc.) are Salesforce's pre-built generic CRUD tools. A custom server is one you assemble — your own Apex actions, your own Flows, your own REST endpoints, optionally mixed with tools borrowed from the standard servers. Same OAuth model, same activation flow, just a different set of tools under the URL.
In Setup Quick Find, search MCP Servers and open it — the same "MCP Servers" area (under API Catalog) that lists the standard Salesforce Servers also has the option to build your own. Click Create Salesforce MCP Server.
Label: something specific, e.g. Custom Sales Tools (the API Name auto-populates, e.g. CustomSalesTools). Description: "A custom MCP server with sales tools." — or whatever actually describes what's inside.
Click Create. You now have an empty server ready for tools.
| Asset type | What it is | Best for |
|---|---|---|
| Apex Invocable Action | An Apex method with @InvocableMethod | Multi-step or complex business logic |
| Autolaunched Flow | Declarative automation you've already built | Reusing existing automation, no code |
@AuraEnabled method | An existing Lightning component controller method | Logic already wired into a component |
| Apex REST endpoint | A class with @RestResource | Integrations with an existing REST contract |
| API Catalog endpoint | Any REST API registered in your API Catalog | Third-party or platform APIs already catalogued |
On your new server, click Add Server Assets → Add Tools. Use the type dropdown to switch between Apex actions and Flows (and the other asset types above), then pick the specific action, Flow, or endpoint you want to expose.
Click Add Tool for each one, then Save. Repeat for every tool you want on this server — e.g. an Apex action like Create Account Sync Meeting Task alongside a Flow like Account Health Check Calculator.
Whatever description sits on the underlying Apex method, Flow, or REST endpoint is what Claude sees when it's deciding which tool to call. Vague names and blank descriptions mean Claude either picks the wrong tool or ignores it entirely.
Click Add Server Assets → Add from Server, pick a standard server (e.g. sobject-reads), and add the specific tools you want — for example Query Records (SOQL) and Search Across Objects (SOSL). Click Save.
These sit alongside your Apex- and Flow-backed tools from Phase 2 — Claude sees one server, one URL, one set of tools.
Click Activate. The Server URL for a custom server looks like:
For a sandbox or scratch org, this likely follows the same sandbox/ prefix pattern used by the standard servers — check the Details tab on your activated server for the exact URL rather than assuming.
Activating the server and having API Enabled isn't enough on its own — whoever authenticates also needs ordinary access to the Apex classes and Flows you added: Apex Class Access for each Invocable Action or @AuraEnabled controller, and Flow access for each Autolaunched Flow.
MCP Client User permission set from the companion guide and add Apex Class Access / Flow Access for everything you exposed in Phase 2. Skip this and the tool will show up in the list but fail — or silently return nothing — when Claude actually calls it.
Open the Headless 360 Playground, go to the Servers tab, paste your Server URL into the URL field, and click Add, then Test. You should see every tool you added in Phases 2 and 3 listed out — that confirms the server itself is wired up correctly, before Claude is even involved.
Same process as the companion guide's Phase 5 — just swap in this server's URL instead of a standard one. Open your existing connector (or add a new one) in Claude's Connectors screen, paste this Server URL in, and use your existing Consumer Key from Phase 4 as the OAuth Client ID.
@InvocableMethod annotation — plain public methods won't appear. For Flow, it needs to be an Autolaunched Flow that's Active — Screen Flows and inactive versions won't show up either.MCP Client User permission set actually grants Apex Class Access to the class behind the action (or Flow access for a Flow) — being able to see the tool in the server config and being able to run it as the authenticated user are two different permissions.@RestResource class is declared with sharing. Apex REST classes default to without sharing unless you say otherwise, which means the tool can quietly bypass the record-level access you're relying on elsewhere in this setup.