Expose an Autolaunched Flow as a Custom MCP Tool

The scenario

Connecting an assistant to the standard sobject-reads server — covered in I Connected My Salesforce Org to Claude — gets you queries. Useful, but generic: the assistant sees objects and fields, and has to assemble meaning itself.

What it doesn't see is your logic. The account-review routine your team runs, the eligibility check, the rollup nobody remembers the formula for. That logic already exists in your org as automation. A custom MCP server publishes it as a callable tool.

In this build I created a custom server and added one tool backed by an autolaunched Flow that returns an Account with its related Contacts and Cases. One request, one shaped answer — instead of the assistant issuing three queries and stitching them together.

For beginners: a tool is a single callable capability an MCP client can discover and invoke. A custom MCP server is your own named collection of them. Configuring the server itself takes no code — you're choosing which existing capabilities to publish.

Why Flow is the right first tool

• It already exists. Most orgs have autolaunched flows doing exactly the kind of scoped, useful work a tool should do.
• It's declarative. Admins can publish a tool without waiting on a developer.
• The contract is already defined. A flow's input and output variables become the tool's input and output schema. You've done the design work without realising it.
• It composes. A flow can call subflows, Apex, and callouts, so one tool can front a surprising amount of logic.

Step 1 — Build the flow as a tool, not as a screen

The flow needs to be autolaunched — no screens, no user interaction. It runs headlessly and returns data.

• Take narrow inputs. An account identifier or a search term, not a bag of optional filters. Every input is something the assistant has to infer correctly.
• Return shaped output, not raw everything. Mine returns the Account plus its related Contacts and Cases — the set a human would actually pull up before a call.
• Name your variables in business language. The variable names travel to the assistant as part of the schema. accountName reads better than var1.
• Keep it read-only for the first tool. Prove the round trip before you publish anything that writes.

Step 2 — Create the custom server

1. Setup → Quick Find → MCP Servers → Salesforce Servers tab.
2. Click Create Salesforce MCP Server.
3. Label — a readable name, for example Account Insights. The Name auto-populates; this API name ends up in the server URL, so keep it clean.
4. Description — one line on what this server is for.
5. Click Create.

You now have an empty server. It has a URL, but nothing to call yet.

Step 3 — Add the Flow as a tool

1. On the server, click Add Server Assets → Add Tools.
2. In the type dropdown, switch from Apex actions to Flows.
3. Pick your autolaunched flow from the list.
4. Click Add Tool, then Save.
5. Click Activate.

Then copy the Server URL. Custom servers follow this shape:

https://api.salesforce.com/platform/mcp/v1/custom/YourServerApiName

Sandbox and scratch orgs carry a /sandbox/ segment in that path. Always copy the URL from Setup rather than typing it from the pattern.

Step 4 — The tool description is the whole interface

This is the part that decides whether the build works, and it isn't a technical step.

The assistant never sees your flow. It sees a name, a description, and an input schema, and from those three things alone it decides whether to call your tool and what to pass. A vague description means the tool gets skipped, or called at the wrong moment with the wrong arguments.

A description that works answers three questions:

Write it as if briefing a new colleague who has your org's data but none of its context. Avoid implementation detail — "runs a flow", "executes SOQL" — because it tells the assistant nothing about when to reach for it.

Step 5 — Create an External Client App

The server exists, but nothing can reach it yet. The External Client App is the trust relationship between the client and your org. Classic Connected Apps do not work for this flow.

Setup → External Client App Manager → New External Client App.

• Name it something obvious (Claude MCP Client App), add a contact email, distribution state Local.
• Expand API (Enable OAuth Settings) → check Enable OAuth.
• Callback URL: the redirect URI your client publishes. For the claude.ai web app that's https://claude.ai/api/mcp/auth_callback; a desktop or CLI client uses a localhost callback instead. Take it from the client's own connector screen rather than guessing.
• Scopes: mcp_api, plus refresh_token and offline_access. Use mcp_api — not the standard Salesforce api scope.
• Check these three: Require secret for Refresh Token Flow, Require PKCE extension for Supported Authorization Flows, Issue JWT-based access tokens for named users. PKCE is mandatory.
• Deselect the other options — changing them later needs Salesforce support.

Click Create. Then:

1. Policies → OAuth Policies: Permitted Users → All users may self-authorize; IP Relaxation → Relax IP restrictions.
2. Settings → OAuth Settings → Consumer Key and Secret → complete the verification dialog → copy both.

One app is enough for several servers. If you already made one for the standard servers in the previous build, reuse its Consumer Key and Secret here — only the server URL differs.

Step 6 — Add the connector in Claude

In claude.ai: left sidebar → Customize → Connectors → + → Add custom connector.

• Name: match the server, for example salesforce-account-insights.
• Server URL: the custom server URL you copied in Step 3.
• Advanced settings: paste the Consumer Key into OAuth Client ID, and the Consumer Secret alongside it.
• Add, then Connect.

You're redirected to Salesforce to log in. If you're already logged into that org, it may skip the challenge entirely.

Once connected, the connector lists the tools it discovered. Your Flow-backed tool should be there by the name you gave it — that's confirmation the server is activated and reachable, before you ask a single question.

Step 7 — Test it

Ask for the thing the tool does, in the words a colleague would use — not the tool's name:

Give me the full picture on the Edge Communications account
before my call — who are the contacts and what's still open?

A good result is the assistant selecting the tool on its own, from that phrasing. If you have to name the tool explicitly to get it invoked, the description is the thing to fix — not the flow.

What to publish next

• Keep the server focused. A server named for a job — account insights, order support — beats one server holding everything. Every connected server's tools load on every request, so a tight set keeps tool selection sharp.
• One tool per question. Two clear tools beat one tool with a mode switch. Ambiguity is what makes an assistant pick wrong.
• Read before write. Get the read-only tools trusted, then add tools that change data — behind confirmation.
• Reach for Apex when you need real guardrails — clamped inputs, explicit access checks, computed summaries rather than raw records. That's the next build in this lab.

Sources: Build Custom MCP Servers · Workshop: Create a Custom MCP Server · Create Custom Salesforce MCP Servers in API Catalog