MCP
Expose ContextWorks as MCP tools, so Claude or any MCP client can ground its answers in your Salesforce records — as the user who logged in. Deploy → MCP walks these steps with your org’s values.
1. Create the external client app
MCP clients authenticate through an External Client App (ECA). Don’t use a shared service account — every user would then see whatever it can see.
Setup → External Client App Manager → New External Client App. Fill in the name and contact email, then expand API (Enable OAuth Settings) and check Enable OAuth.
| Setting | Value |
|---|---|
| Callback URL | Your client’s — https://claude.ai/api/mcp/auth_callback for Claude. See step 6. |
| OAuth scopes | Access MCP servers (mcp_api) and Perform requests at any time (refresh_token) |
| Token format | Issue JSON Web Token (JWT)-based access tokens for named users |
| Flow | Require proof key for code exchange (PKCE) |
Leave the other token and flow options off. Click Create, then open the app’s Settings → OAuth Settings → Consumer Key and Secret and copy both values — step 6 needs the key and the secret.
WARNING
A new external client app takes up to 30 minutes to become usable. Connecting a client before then fails to authenticate.
2. Create an MCP server
Setup → MCP Servers → New. Suggested name: ContextWorks. A server can’t ship inside a package, so this is a per-org step.
3. Register the tools
Add the three invocable actions to the server as tools, named exactly as the Deploy page shows — the same rule as Agentforce agent actions. The Copy Tool List button gives you the names and purposes in one paste.
TIP
The tool descriptions are the agent’s only documentation — Get Catalog says to call it first, Find Records explains filter syntax and that totals cover the full matching set, Get Records explains that each record’s object is resolved from its ID. Read them yourself before registering.
4. Activate the server
Activate it on the server’s detail page and note the endpoint URL it exposes.
5. Grant access
Assign the ContextWorks User permission set to every user who will connect a client — tool calls run as the authenticated user, and the REST endpoint checks their class access. It grants nothing else, so broad assignment is safe.
6. Connect your client
Use the endpoint from the server’s detail page. It takes this shape:
- Production, Developer Edition —
https://api.salesforce.com/platform/mcp/v1/custom/ContextWorks - Sandbox, scratch —
https://api.salesforce.com/platform/mcp/v1/sandbox/custom/ContextWorks
In Claude, open Customize → Connectors, click +, and choose Add custom connector. Name it, paste the endpoint, then open Advanced settings and fill in both: the external client app’s consumer key as OAuth Client ID, and its consumer secret as OAuth Client Secret. Click Add, then Connect to authorize in your org. Configure chooses which tools are exposed.
Claude’s callback URL is https://claude.ai/api/mcp/auth_callback. Other clients publish their own, and it must be on the external client app before the first connection attempt.
Then try it: “What do you know about the Global Media account?” The client should call Get Catalog, then Get Records, and answer from your curated context. Check Observe → Usage — the load records mcp as its surface, so MCP traffic reads separately from Agentforce traffic.
The administration server: steps 2a–6a
The nine admin tools go on their own MCP server, never mixed in with the runtime ones, so an agent that answers questions cannot reconfigure the system it reads from. The external client app from step 1 covers both servers; everything else repeats with admin values:
- 2a. Create the admin server — Setup → MCP Servers → New. Suggested name:
ContextWorks_Admin. - 3a. Register the admin tools — same motion as step 3, with the admin actions and only those: the reads (Get Full Config, Get Health, Get Change Log, Get Catalog), the composer (Save Draft — briefs, skills, or an entity’s text), the digest-confirmed serving changes (Activate Draft, Update Domain Contents, Deactivate), and Get Skill. The Deploy → MCP page lists all nine.
- 4a. Activate it — and note its endpoint, which differs from the runtime server’s only by name.
- 5a. Grant access — these tools require the ContextWorks Admin or ContextWorks Domain Manager permission set; there is nothing to assign more broadly.
- 6a. Connect — admins only — the same client setup as step 6 with the admin endpoint, added as a second connector by the people who administer ContextWorks. Everyone else’s clients never list these tools at all, which is the point of the separate server.
The payoff is the transformation session: connect Claude to the admin server, fetch document_to_briefs with Get Skill, paste a methodology deck, and review the brief drafts it composes — drafts reach no one until you approve them. What the surface can do, and its safety model: → The admin agent
Scoped tools over MCP
A domain’s generated tools are ordinary invocable actions, so they register on an MCP server exactly like the built-in four. Put them on the same server or their own — a separate server gives one audience a narrower surface, but it’s routing convenience, not access control. Permissions still decide what any caller receives.
Security notes
- Every call runs as the authenticated user. Object permissions, field-level security, and record sharing apply per caller — see Security.
- Payloads leave your org — to the MCP client, and from there to whatever model it uses. Curation is your control: an entity that omits a sensitive field never sends it, for anyone.
- The external client app is the boundary. Whoever can authorize it can reach these tools. Restrict it with a permission set on the app’s OAuth policies if the org is broad.