Data 360 MCP Server Goes Live

Yesterday, an agent inside your org could reach into Slack, could read Marketing Engagement, and could hit Data 360 through a beta MCP server that Salesforce reserves the right to change. Today one of those three is generally available, the other two moved a floor down in the stack, and Salesforce is telling you the platform is complete. Read the press release once and you get that impression. Read the GA fields on each product and you get a different one.

The August 19 Newsroom drop is a seven-minute read that carries most of the year's Headless 360 promises across the finish line. Six pieces went GA. Two of them stayed in open beta. The one still in open beta is the one you probably assumed had shipped, which is why the ship list is worth reading before your next roadmap review.

What Actually Shipped

On the GA side: the Data 360 MCP Server, the Data 360 Agent Skills, the Skills repository at more than 100 packaged workflows, the Salesforce Multi-framework for building React apps against native Salesforce authentication, Headless Commerce, and the Slackbot MCP Server and Client. The Slackbot MCP Client actually went GA on June 17; Wednesday's news is that the server half of that pair caught up and that Slackbot now ships as a matching MCP client, so any authorized agent can reach into Slack the same way Slackbot reaches out.

On the open-beta side: the Headless 360 MCP Server, and the Headless Experience Layer. The first of those is the interesting one. The Headless 360 MCP Server is the umbrella product, the one Salesforce described at TDX as the way any authorized AI agent will "discover, understand, and take action" across every business capability the platform exposes. It is documented as open beta as of the July 2026 developer post, and yesterday's release notes did not move it. It stays there today.

The distinction matters because press coverage collapsed the two. Multiple write-ups yesterday used "Headless 360 MCP Server" and "Data 360 MCP Server" interchangeably. They are different products. One reads and writes data. The other calls every other capability in the platform, and it is not yet a supported production surface.

The Data 360 Server Is The One That Really Shipped

The Data 360 MCP Server is Salesforce-hosted, Salesforce-managed, and exposes roughly 200 Data 360 Connect APIs to any authorized agent, plus a starter set of prepackaged skills for four categories of work: modeling, mapping, transforming, and activation. If you have watched somebody try to build a customer segment by hand-mapping fields between four sources into a Data 360 model, you already know what those categories cover, and you already know how long that has historically taken.

Rohan Kumar, one of the Salesforce leaders behind the platform, told SalesforceDevops.net that the point of pushing this to GA now is unit economics. "Agents get expensive because they operate at a data layer that is not curated well," is his framing. The knowledge layer inside Data 360 pre-creates the context an agent would otherwise have to rebuild every turn, and the MCP server hands that context to the model as pre-shaped skills rather than raw endpoint stubs.

There is a concrete customer number attached. Engine, a travel-management platform, put an AI support agent called EVA into production in twelve days on the beta stack, and reports resolving 50% of customer chats without a human. That is one company saying its onboarding fit inside a fortnight, and its containment rate is above the industry median. Take it as a directional signal about tooling speed rather than a promise about your own numbers.

Three Tools, Not Thousands

The reason any of this works is a design decision that is easy to miss under the marketing language.

A Salesforce org has, on a conservative count, several thousand callable features between the standard APIs, custom Apex, and installed managed packages. If each of those were exposed to an MCP client as its own tool, the model would spend most of a context window reading tool descriptions and picking one before it did any work. The developer blog for the Headless 360 MCP Server explains that Salesforce's answer is three meta-tools, plus a read-only sibling, that map onto how an agent actually works a request.

Discover takes whatever the agent decides you asked for and runs a semantic search over a vector index of every API and skill in the catalog, returning a ranked shortlist. Describe pulls back the technical contract for the chosen skill: parameters, dependencies, ordered steps. Dispatch invokes it. All three run under the same set of guards you already trust in the platform. Every transaction runs as the authenticated user with the mcp_api scope, so CRUD checks, field-level security, sharing rules, profile assignments, and permission set access all apply, and the audit trail attributes the write to the person the agent is acting on behalf of.

That guard set is the reason the beta is worth taking seriously and the reason the GA label matters. An agent that can call anything in your org can also, in principle, do anything a user can. The mistake in the beta window is to give the agent's user a permission bundle broad enough to make the demo work, and the fix is to build the permission set as if the agent is an intern with a keyboard, because from the platform's point of view that is what it is.

The Skills Repository Is The Story

Salesforce shipped the Skills repository past 100 packaged workflows on Wednesday. It is easy to read that number and move on. It is the piece of yesterday's announcement that will actually change what your developers write.

A skill is an opinionated wrapper around a small set of Connect API calls. It is what the model calls once, in place of a hand-written orchestration that would otherwise sequence six or seven endpoints, remember what to do when one fails, and negotiate what to pass to the next one. The repository launch covers admin work first (user provisioning, Apex trigger deployment, event-driven integrations, Named Credential creation), and adds business-user skills as the beta widens.

The Skills are the thing your platform team probably would have written itself over the next year. Salesforce shipped the version that comes with governance already built in, versioning maintained by product management, and support paid for by your license. Keep a private layer of company-specific skills on top of it, and hold the discipline that anything a shipped Salesforce skill already covers is not something your team should be rewriting from scratch.

The Multi-Framework Bit Is A Developer Story

Salesforce Multi-framework is the third piece of yesterday's news that gets under-covered. It is a React runtime that ships with native Salesforce authentication and the same access guards as the rest of the platform, and it is the answer to a specific problem that anyone building on Headless 360 was going to hit.

The Headless Experience Layer, still in open beta, is meant to let one UI definition render across Lightning, Slack, and any MCP client, using the Custom Lightning Types that went GA in Summer '26. The realistic case, though, is a modern web front end that is not Lightning at all. Multi-framework is the piece that lets that front end sign in with Salesforce identity, respect the same permission model, and share the same audit trail, without a bespoke integration layer. If your team has been sitting on a decision about whether to build the customer portal in React or in Lightning Web Runtime, Wednesday's announcement is the one that unblocks the React answer, at least on paper.

What The Slackbot Half Adds

The Slackbot MCP Server and Client pair rounds out Wednesday's Slack side. The client half went GA on June 17. What shipped yesterday is the server half, which lets any MCP-speaking agent invoke Slackbot as a capability, and 20 plus prebuilt partner integrations to go with it (Atlassian, Box, Canva, Docusign, Notion, Zoom, and a longer list on the Newsroom page).

What the pairing changes is where the identity boundary sits when an agent works across those tools. Before this, a cross-tool workflow meant a service token per system, stored somewhere your platform team hoped was safe. With Slackbot on the MCP server side, the identity travels with the user, and the audit lands in one place.

The Timeline, And What To Test Before Dreamforce

Dreamforce runs September 15 to 17, and it is the next window in which Salesforce is likely to promote the two remaining betas. Between now and then, three things are worth spending sandbox time on.

First, wire an authorized MCP client (Claude Code, Cursor, or the built-in Agentforce runtime) against the Data 360 MCP Server in a sandbox, using a dedicated integration user with the mcp_api scope and the smallest permission set you can get away with. Confirm that CRUD and FLS work the way you expect against a table with mixed permissions. This is the muscle you will need for the umbrella server later.

Second, walk the Skills repository against your open engineering tickets and mark the ones that a shipped skill would now cover. That is your Q4 replan.

Third, price the Multi-framework path against whatever you have currently scoped as a Lightning Web Runtime build. The customer-portal decisions your team has been deferring have a new default answer, and Dreamforce is the window in which most vendors in your stack will be asked to match it.

The one thing to not do is publish the Headless 360 MCP Server against a production integration on the strength of a press release. It is an open beta, and beta means the contract can change. Wait for the GA promotion in your admin console, and until then, treat the Data 360 server as the piece that actually shipped.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He writes and edits salesforcedictionary.com, published by KineticBit Inc., to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.