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 that one account 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.

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

On the server, click Server Assets → Add Tools and choose Apex actions from the picker at the top left. The picker lists the eight runtime actions: ContextWorks: Get Catalog, Find Records, Get Records, Get Briefs, Get Skill, Get Info, Update Records and Create Records.

Select one, click Add Tool, repeat for the rest, then Save. You don’t name these. Each tool takes its action’s own name, and Deploy → MCP step 3 shows every one with its Apex class.

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 endpoint checks that user’s access to the action classes. The permission set reaches the actions and ContextWorks’ own configuration records, never your Salesforce data, 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 picks which tools the client can call.

Claude’s callback URL is https://claude.ai/api/mcp/auth_callback. Other clients publish their own, and it has to 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 for the load. The Surface column names the tool that ran, get_catalog or get_records, exactly as it would for an Agentforce agent: ContextWorks can’t tell one client from another at the action boundary. To read one client’s traffic on its own, give it scoped tools, which stamp their own tool name.

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, for briefs, skills, or an entity’s text), the changes that ask you to confirm first (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 whoever administers ContextWorks. Everyone else’s client never lists these tools.

Then you can administer by conversation: connect Claude to the admin server, fetch document_to_briefs with Get Skill, paste a methodology deck, and review the brief drafts it composes. A draft reaches no one until you activate it. → 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 ones. Put them on the same server or a server of their own. A second server just gives one audience a shorter tool list; 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.

What’s next

• Custom tools