Headless Data 360: driving your unified data from Claude with the MCP server

For a decade the way you got at Data Cloud — now Data 360 — was to open the app, click into a data stream, write a query in the Query Editor, or build a REST call by hand against one of a couple hundred API operations you had to go read the docs to find. The data was unified; getting a question answered against it still meant a human driving a UI or an engineer hand-rolling a request. Summer ‘26 quietly changed the shape of that. Salesforce made its hosted MCP servers generally available, and shipped an open-source Data 360 MCP server in developer preview, and between them your unified data stops being a place you visit and becomes an interface an AI client talks to directly.

This is the concrete edge of what Salesforce has been calling “Headless 360” — the idea that every capability the platform has accumulated over 25 years is reachable by API, MCP, or CLI, so an agent or a developer can build and act on any surface. The Model Context Protocol is the part of that story that lets Claude, Cursor, ChatGPT, or your own agent ask a question of Data 360 in natural language and get a grounded answer back without you writing a single connector. It’s genuinely useful and genuinely easy to point at the wrong data with too much authority. This post is the map: the two servers and how they differ, the facade architecture that makes 200 operations usable, the auth flow, and the boundary you draw before any of it touches production.

Two different servers wearing the same protocol

The first confusion to clear up — because Salesforce shipped both in the same release window — is that “Data 360 and MCP” now means two distinct things, and they solve different problems.

The Salesforce-hosted MCP servers (GA in Summer ‘26). These run on Salesforce’s own infrastructure. There’s an SObject server (CRUD and SOQL over your standard and custom objects), a Data 360 server (queries and metadata over your unified data), and a Tableau server (analytics), plus product APIs. Any MCP-compatible client — Claude, ChatGPT, Cursor, a custom agent — connects over standard OAuth, and because Salesforce hosts them there is no infrastructure for you to stand up or patch. This is the low-friction path for a business user or an analyst who wants to converse with their org’s data.

The open-source Data 360 MCP server (developer preview). This is a separate, self-hosted server — the forcedotcom/d360-mcp-server repository, built on Spring AI — that you run yourself as a local process and wire into a coding agent like Claude Code or Cursor. It fronts the Data 360 Connect API — roughly 201 operations across 22 tool families (Data Lake Objects, Data Model Objects, Data Streams, Identity Resolution, Calculated Insights, Semantic Data Models, machine learning, and more) — and is aimed at developers building and testing against Data 360 from their editor.

Hosted MCP is for talking to your data with no infrastructure. The open-source Data 360 server is for building against the Data 360 API from a coding agent. Same protocol, different jobs — pick by whether your user is an analyst asking questions or an engineer writing integrations.

Neither of these is the Salesforce DX MCP server, which drives metadata deploys, Apex tests, and scratch orgs, and neither is the same as connecting Agentforce to an external MCP server so an agent can call Jira or Snowflake as an action. If the whole MCP landscape is still fuzzy, the enterprise architect’s explainer is the place to start; this post assumes you know what MCP is and want the Data 360 specifics.

The facade trick: why 200 operations become three tools

Here’s the design problem that makes the Data 360 server interesting. The Connect API has ~200 operations. The naive way to expose an API over MCP is one tool per operation — but hand an LLM 200 tool definitions and you’ve spent a huge slice of its context window on a menu before it has read a single word of your actual question. Tool-selection accuracy also degrades as the list grows; the model starts guessing. Exposing everything directly doesn’t scale.

So the Data 360 server consolidates all ~201 operations behind three facade tools:

• search — the agent describes what it wants (“list my data model objects”, “run an identity resolution ruleset”) and gets back the handful of underlying operations that match, by intent, keyword, or tool family. This is discovery: the model finds the capability without carrying the whole catalog.
• payload_examples — for a chosen operation, the agent fetches a working example request body. Complex Data 360 calls have non-obvious payload shapes, and a real example is worth more to a model than a schema. This is what stops the agent from inventing a plausible-but-wrong JSON body.
• execute — the agent runs a named operation with its parameters and gets the result back.

The workflow the model follows is always the same: search for the right capability, fetch a payload example to learn the shape, then execute. It’s the same instinct behind a good semantic layer for agents — put a thin, intent-oriented interface in front of a wide, technical surface so the reasoning model spends its budget reasoning, not memorizing. If you’ve ever watched a coding agent flail against a sprawling API, you’ll appreciate why the facade matters: it’s the difference between an agent that finds the right call in two steps and one that burns ten turns and still gets the endpoint wrong.

Standing up the open-source server

The developer-preview server is a Java application. The prerequisites are Java 17 or later and Maven 3.9 or later (the repo’s installer can pull these in for you), plus a Salesforce org with Data 360 and Connect API access. Build and run are ordinary Maven:

# Build the server JAR
mvn clean package -DskipTests

# Run it in STDIO mode (the default for MCP client integration)
java -jar target/data360-mcp-server-1.0.0.jar

Authentication has two flows. For quick local testing you pass an access token directly:

export DATA360_INSTANCE_URL="https://your-domain.my.salesforce.com"
export DATA360_ACCESS_TOKEN="your_access_token"

For anything you’ll run more than once, use the auto-refreshing client-credentials flow tied to a connected app or external client app, so you’re not pasting a token that expires in a couple of hours:

export DATA360_CLIENT_ID="3MVG9..."
export DATA360_CLIENT_SECRET="your_client_secret"
export DATA360_AUTH_FLOW="client_credentials"

Then wire it into your coding agent. In an MCP client, the server is a command-plus-environment entry — you point the client at the java -jar invocation and hand it the credentials through the environment:

{
  "mcpServers": {
    "data360": {
      "command": "java",
      "args": ["-jar", "/absolute/path/to/data360-mcp-server-1.0.0.jar"],
      "env": {
        "DATA360_INSTANCE_URL": "https://your-domain.my.salesforce.com",
        "DATA360_CLIENT_ID": "3MVG9...",
        "DATA360_CLIENT_SECRET": "your_client_secret",
        "DATA360_AUTH_FLOW": "client_credentials"
      }
    }
  }
}

One optional knob worth calling out: the server can use an OpenAI API key to power semantic search over the operation catalog (the search facade). It’s optional — keyword search works without it — but if you enable it, understand that you’re introducing a second external model provider into the loop, and decide whether that’s acceptable for your environment before you set the key. Because this is a developer preview, treat the exact env-var names, JAR version, and tool behavior as things to confirm against the repository’s current README rather than as frozen contract; preview surfaces move between commits.

The hosted path: OAuth, no JAR

If you don’t want to run a Java process, the hosted Data 360 MCP server is the alternative, and its setup is entirely OAuth. The shape of it, connecting a client like Claude as a custom connector, is roughly:

1. Activate the MCP server for your org and require PKCE on the connection.
2. Create an External Client App with the client’s exact callback URL (for Claude’s custom connector that’s https://claude.ai/api/mcp/auth_callback), and grant the mcp_api and refresh_token scopes.
3. Set the app’s policies, copy the consumer key and secret, and paste them into the client’s custom-connector configuration.

From there the client runs an OAuth authorization-code flow, the user logs in, and the connection is live — no server for you to host, patch, or scale. The trade-off versus the self-hosted server is control: you get Salesforce’s hosted surface and its supported operation set, not the full open-source catalog you can inspect and extend. Confirm the current scope names and the exact step list against the live setup docs before you wire this into anything that matters, because the connector-configuration details are the kind that shift release to release.

The boundary you draw before production

Everything above is plumbing. This is the part that decides whether pointing an AI client at Data 360 is a productivity win or an incident.

An MCP server is exactly as privileged as the identity it connects with. The hosted server acts as the OAuth-authenticated user, so it inherits that user’s permissions and Data 360 sharing — connect as an admin and the agent can see and do what an admin can. The open-source server with client-credentials acts as that integration user. The single most important configuration decision is therefore not in the server at all; it’s the permission set on the identity you hand it. Give it a purpose-built, least-privilege user scoped to exactly the data spaces and objects it needs, the same discipline you’d apply to governing which data an agent can reach. “Connect as yourself because it’s easy” is how a convenience tool quietly gets read access to your entire customer graph.

Read is a different risk class than write. A coding agent that can query Data 360 to help you build is low-stakes; a poorly-scoped execute call that can create or delete a Data Model Object, kick off an identity-resolution ruleset, or mutate a data stream is not. For exploratory and grounding use, scope the identity to read-only and you’ve removed most of the blast radius. Reserve write capability for a deliberately separate, tightly-scoped configuration, and know which of the 22 tool families your identity can actually reach.

Preview means preview. The open-source server is a developer preview: not covered by the same support and SLA as a GA feature, subject to change, and — critically — not something to point at a production org without a hard look at what it can touch. Run it against a sandbox or a scratch Data 360 environment while you learn its behavior. The hosted servers are GA, which is a different assurance level, but even there the governance question is the same: what identity, what scope, read or write.

Semantic search sends text to a model. If you enable the optional OpenAI-powered search, operation descriptions and your search intent go to an external provider. That’s fine for many teams and disqualifying for some; make it a conscious choice, not a default you flipped past.

Get the identity and the read/write line right and the rest is upside. Get them wrong and you’ve built the most convenient possible path to an over-permissioned data-access incident.

Where this is actually going

It’s tempting to file MCP support under “nice developer convenience,” but the direction it points is bigger. When your unified data is reachable by any MCP client under governed OAuth, grounding stops being a bespoke pipeline you build per agent and becomes a standard interface any agent can consume. The Query API and the SQL surface were the first step in that — programmatic access to Data 360 for code. MCP is the second: programmatic access for reasoning models, with a discovery layer so the model can find its way around ~200 operations without you writing glue for each one.

For teams already invested in Data 360, the practical near-term wins are unglamorous and real: a developer building an ingestion or identity-resolution flow can have a coding agent draft and test the API calls against the live metadata instead of alt-tabbing to docs; an analyst can ask questions of unified data from the client they already work in; and an integration engineer can prototype against the Connect API at conversation speed. None of that requires the fully autonomous agent the keynotes love — it just requires the data to be an interface, which, as of Summer ‘26, it is.

The mistake to avoid is treating “the data is now reachable by an agent” as the same thing as “the data is now safe for any agent to reach.” It isn’t. The protocol is open, the setup is a few steps, and the governance is entirely on you. Draw the identity and read/write boundaries first, prove it in a sandbox, and then let Claude drive your unified data.

Understanding the basics

What is the Data 360 MCP server?

It’s a Model Context Protocol server that exposes Salesforce Data 360 to MCP-compatible AI clients. There are two flavors. Salesforce’s hosted MCP servers (Data 360, SObject, Tableau) went generally available in Summer ‘26 and connect over standard OAuth with no infrastructure to run. The open-source Data 360 MCP server (forcedotcom/d360-mcp-server) is a developer-preview Java application you self-host; it fronts roughly 201 Connect API operations across 22 tool families and is aimed at coding agents like Claude Code and Cursor.

Why does it expose three tools instead of one per operation?

Because handing an LLM 200 tool definitions consumes its context window and degrades its tool-selection accuracy before it even reads your question. The server uses a facade architecture: search discovers the right operation by intent, payload_examples returns a working request body so the model gets the payload shape right, and execute runs the chosen operation. The agent searches, fetches an example, then executes — a stable three-step loop regardless of which of the ~200 operations it needs.

Is it safe to point an AI client at my production Data 360?

Only with deliberate scoping. An MCP server acts with the permissions of the identity it authenticates as, so connect it to a purpose-built, least-privilege user — ideally read-only for exploration and grounding — scoped to just the data spaces and objects it needs. The open-source server is a developer preview, so run it against a sandbox while you learn its behavior rather than production. Treat write-capable operations (creating or deleting data model objects, running rulesets, mutating streams) as a separate, tightly-gated configuration.

---

Trying to work out how MCP, Data 360, and Agentforce actually fit together in your stack — and where the governance boundaries have to sit before you turn any of it on? Talk to us — a governed data foundation that AI can safely reach is the work we do.