The dx0 MCP

The dx0 MCP server gives an AI agent read-only access to what dx0 already knows about your connected Salesforce orgs, git repositories and Workato workspaces. This article explains the moving parts and the permission model. Use it to answer security and procurement questions about connecting dx0 to Claude or any other MCP client.

To set it up, see Connecting Claude.

The short version

• Read-only. No tool available over MCP can create, update or delete anything in dx0 or in your connected systems.
• No dx0 AI. Every tool returns facts dx0 has already collected. The agent does its own reasoning, and none of your dx0 AI capacity is used.
• Acts as you. The agent sees exactly what you can see in dx0, under the same role and workspace rules. It never sees more.
• You can revoke it at any time. Disconnecting an agent in dx0 cuts it off on its next request.

Architecture at a glance

The server is a single endpoint, https://api.dx0.io/mcp, using the standard MCP Streamable HTTP transport. It keeps no session state between requests. Every request goes through the same steps:

1. The agent sends a request over HTTPS with a bearer token.
2. dx0 checks who the token belongs to and which workspaces that person can access.
3. dx0 answers from its stored index of your orgs, repositories and Workato workspaces. Permission checks and configuration signals also run read-only setup queries against Salesforce.

The four tools your agent sees

dx0 installs only four tools in your agent, which keeps its context window small:

Tool	What it does
dx0_get_connections	Lists the Salesforce orgs, repositories and Workato connections in every workspace you can access, the workspace each belongs to, and whether each is ready to use.
dx0_discover	Returns the catalog of dx0 tools that apply to the connections the agent selected.
dx0_execute	Runs one tool from that catalog against one connection.
dx0_get_skill	Returns a Salesforce skill guide, such as SOQL, Apex triggers, Apex tests, formulas, CPQ or impact analysis, so the agent follows Salesforce best practices and checks your org before writing code.

How agents discover connection-specific tools

Most of dx0's capabilities aren't installed as separate tools. They live in a catalog that dx0 serves at runtime, and the agent works through it in three steps:

1. List connections. The agent calls dx0_get_connections to get the real connection IDs. It never guesses them.
2. Discover tools. The agent calls dx0_discover with the connections it cares about. dx0 returns a compact list of the tools that apply to those connection types: Salesforce tools for an org, repository tools for a repo, Workato tools for a Workato workspace, and workspace-level tools for all of them. The agent then asks for the full instructions and input schema of only the tools it plans to use.
3. Execute. The agent calls dx0_execute with the tool, the connection and its arguments.

Because dx0 serves the catalog, new capabilities appear in your agent without reinstalling or reconfiguring anything.

What's in the catalog

• Salesforce orgs: the metadata index (browse, search and read Apex, Flows, fields, layouts and more), "where is this used?" impact analysis, user and object permission checks, configuration signals (security health check, admin users, risky permission sets, OAuth tokens, installed packages, triggers and more), change history between index runs, and results from code scans you've already run.
• Repositories: browse, search and read the default branch, recent commits and pull requests.
• Workato: browse, search and read recipes, connections and projects.
• Workspace: your team's context notes, your own past dx0 conversations, recommendations dx0 has flagged and your knowledge base articles.

How authentication works

Every request to the MCP endpoint must carry a bearer credential. Requests without one are refused. Browser cookies are never accepted.

Agent sign-in (recommended)

dx0 implements the standard MCP authorization flow (OAuth 2.1 with PKCE). You add https://api.dx0.io/mcp to your agent, the agent opens your browser, you log in to dx0 and click Allow. You never copy or paste a key.

• The consent page shows what's connecting. It shows the agent's name and where your browser goes next (for example claude.ai or an app on your computer), so you can confirm you started the connection.
• Tokens are short-lived and stored hashed. Access tokens last one hour and refresh automatically. dx0 stores only a hash of each token, never the token itself.
• Unused connections expire. A connection that goes unused for 30 days expires, and the next use asks you to sign in again.
• Tokens only work for MCP. An agent token reaches the MCP endpoint and nothing else in the dx0 API.
• Devices without a browser can use a code. For terminals and machines that can't open a browser, the agent shows a short code you enter at https://agent.dx0.io/activate.

API keys (fallback)

For scripts, CI pipelines or agents that don't support sign-in, you can generate a personal API key under Settings → MCP & API Keys → Advanced. Choose MCP only so the key can't be used anywhere else in the dx0 API. Keys are shown once, stored hashed, and can be revoked at any time. Prefer agent sign-in where possible, because it leaves no long-lived secret in a config file.

What permissions the agent gets

The agent acts as the person who connected it. There's no separate service account and no elevated access.

• Workspaces: the agent can reach every workspace you can access. For an account admin, that's every workspace in the account. For everyone else, it's the workspaces they're a member of.
• Roles: each workspace applies its own role and member rules. If you're an admin in one workspace and a standard user in another, the agent gets exactly that. See Who can do what.
• Changes apply immediately: removing someone from a workspace, or from the account, takes effect on their agent's next request.
• Private data stays private: your past dx0 conversations are visible only to you, and private context notes stay private.

To limit what a contractor's agent can see, add them only to the workspaces they need.

Access to your Salesforce orgs

The agent never receives Salesforce credentials. Most tools read the index dx0 has already built. Permission checks and configuration signals run read-only setup queries through dx0's existing connection to the org.

What the agent can't do

• Write, update or delete anything, in dx0 or in your connected systems.
• Read CRM record data.
• Call dx0's AI, start conversations, or trigger indexing or code scans.
• Manage users, connections, API keys or settings.
• Reach any dx0 API endpoint other than MCP.

Using dx0 with Claude

When you connect dx0 to Claude:

• dx0 doesn't get access to your Claude account. The access only runs one way: Claude gets a dx0 token that can read through the MCP endpoint, and nothing more.
• Tool results go to your AI provider. Whatever a tool returns (metadata, configuration, repository files) goes into Claude's context and is processed by Anthropic under your agreement with them. The same applies to any other agent you connect.
• You get an email. When dx0 is connected to Claude, the person who approved it receives an email with next steps and instructions for disconnecting.
• Team and Enterprise plans: a Claude organization owner can add dx0 once for everyone. Each member still signs in to dx0 individually, so each person's agent sees only what that person can see.

Monitoring and revoking access

• Connected agents: Settings → MCP & API Keys → Connected agents lists every agent you've connected, when it was connected and when it was last used. Disconnect takes effect on the agent's next request.
• Admin oversight: account admins can switch the list to everyone in the account and disconnect anyone's agent or revoke anyone's API key, for example when someone leaves or loses a laptop.
• Audit logging: dx0 logs every connect, consent, disconnect and revocation, with the user, account and IP address.
• Rate limits: requests are rate-limited per connected agent or API key.