Back to Blog
AI News

The Salesforce Headless Toolkit: Running Agents Without the UI

TS

Tushar Sharma

Chief Executive Officer

11 min read - Sep 25, 2026

The short version

  • The Headless Toolkit is the developer pillar of AIforce: the set of APIs, MCP servers, skills, plug-ins, and developer tools for building and governing Salesforce agents on any surface, with the UI as an option rather than a requirement.
  • It is the Dreamforce 2026 packaging of the Headless 360 architecture announced at TDX in April 2026. Same foundation, productized: Salesforce's own pages still use both names side by side.
  • Real pieces are usable today: the six hosted MCP servers went GA in April 2026 and are included in Developer Edition, the Headless Experience Layer is GA, and the sf-skills library and the @salesforce/mcp package are on GitHub and npm now.
  • Every headless call runs under the calling user's existing permissions, sharing rules, and field-level security, and Salesforce commits to zero data retention by model providers. Builder Central, Angular support, and the AI Control Plane are still beta or future-dated, so do not build a 2026 plan on them.

What the Headless Toolkit Actually Is

Salesforce defines the Headless Toolkit as the set of APIs, MCPs, skills, plug-ins, and developer tools required to build and govern agents in Salesforce, regardless of interface. Everything stays in the same system of record, and all of it is reachable through an API call, an MCP tool, or a CLI command instead of a browser session.

It arrived at Dreamforce 2026 as the developer pillar of AIforce, the interface layer Salesforce announced on September 15. AIforce shipped three packaged surfaces, Salesforce inside Claude, inside Slack, and an AI coworker inside Lightning, and one build-your-own path. The Headless Toolkit is that fourth path: the same data, logic, and permissions those products use, exposed directly to your own agents, apps, and interfaces. The full context is in our Dreamforce 2026 recap.

The pitch to developers is blunt: bring Salesforce into any AI, agent, application, or custom interface. The browser UI becomes one surface among many, and for a growing set of workflows, not the primary one.

From Headless 360 to the Headless Toolkit

None of this appeared from nowhere. The architecture underneath was announced as Headless 360 at TDX 2026 on April 15, which we covered at the time in Headless 360 at TDX 2026 and unpacked in the complete Headless 360 guide.

Patrick Stokes, Salesforce's President of Applications, drew the line between the two at Dreamforce: Headless 360 is really the raw MCP servers, the raw APIs, the exposure of those things from Salesforce, and AIforce is a step above it. His analogy: the spring announcement was the raw ingredients, and AIforce is the chocolate chip cookie that comes out of the oven.

Honest note on naming, because Salesforce is not consistent yet: the official product pages use Headless Toolkit and Headless 360 side by side, the architecture help article still says Headless 360, and the developer center is titled Salesforce Headless Toolkit. Treat them as one thing. Headless 360 is the architecture; the Headless Toolkit is what Dreamforce packaged it into as AIforce's developer surface.

What Is Actually in the Box

Strip away the keynote language and the toolkit is a concrete stack. These are the components Salesforce has documented:

  • Hosted MCP servers. Six standard servers, GA since April 2026: SObject All, SObject Reads, SObject Mutations, SObject Deletes, Data 360, and Tableau Next. Salesforce runs them; you connect an MCP client and get governed org access with no middleware to host.
  • 60+ MCP tools and 30+ preconfigured coding skills, per Salesforce's own toolkit pages, covering metadata, data access, deployments, and configuration.
  • The Headless Experience Layer. Separates business logic, data, and permissions from the screen, so one agent renders natively in Slack, Claude, Teams, WhatsApp, and mobile. Salesforce lists it as generally available.
  • Salesforce Multi-Framework. React and Angular micro-frontends that embed inside Lightning, Experience Cloud, and the Salesforce mobile app. Angular production support is still beta.
  • Builder Central, the natural-language app and agent builder, currently in beta with built-in safety checks and deployment controls.
  • The DX MCP server. The @salesforce/mcp package on npm: a local, CLI-based MCP server for Salesforce DX projects, so coding agents can work against scratch orgs and pipelines.
  • The sf-skills library. An open-source repo from Salesforce with 100+ skills, including the official Salesforce Development plugin for Claude Code with 40+ skills for metadata, Apex, LWC, and deployments.
  • Lifecycle and governance tools carried over from the TDX launch: Agent Script, Testing Center, Observability and Session Tracing, and Agent Fabric for cross-vendor agent governance.

What You Can Use Today, and What Is Still Coming

The useful question in September 2026 is not what was announced, it is what you can actually run. Generally available now: the hosted MCP servers (Enterprise Edition and above, and included free in Developer Edition), the Headless Experience Layer, the Marketing Cloud Engagement MCP server (GA since June), plus the @salesforce/mcp package and the sf-skills repo you can install today.

In preview or beta: the Data 360 MCP server (developer preview since May), Builder Central, Angular production apps, and Salesforce in Claude itself, which is an approval-gated beta we walk through in the Claudeforce plugin setup guide.

Further out, and worth hedging: Agentic Identity, credentials and access control purpose-built for agents, has been reported for November 2026 but only by a single outlet so far. And the AI Control Plane from Salesforce's separate Enterprise AI Harness announcement is not due before early fiscal year 2028, which in calendar terms means February 2027 at the earliest. Neither belongs in a 2026 delivery plan.

One more honesty check: you will see counts like 4,000+ APIs and 220+ CLI commands in recap articles. Salesforce's own toolkit pages stick to the 60+ tools and 30+ skills figures, so treat the bigger numbers as unofficial until Salesforce publishes them.

The Security Model, in Plain Terms

The design decision that makes the whole thing defensible: headless access inherits your existing controls instead of introducing new ones. Every call routes through the same profiles, permission sets, org-wide defaults, sharing rules, field-level security, and validation rules that govern the UI. An agent sees only what the user behind the request can see, and early hands-on testing by the community confirms none of those layers are bypassed.

On data handling, Salesforce commits to zero data retention with model providers: business data is used to answer the request at hand and, per Salesforce, is not retained by the model provider. That is a vendor commitment, so verify it against your own data processing terms during procurement, but it is stated policy, not fine print.

Two governance layers sit alongside the toolkit. Security Mesh, an add-on to Security Center, now scores MCP servers for risks like prompt injection, tool poisoning, and rug-pull attacks, with Low, Medium, and High ratings and continuous re-scanning. And the Enterprise AI Harness, announced separately on September 10, is Salesforce's broader framework for governing agents across vendors. Useful direction, but as noted above, its control plane is future-dated.

Wiring It Up: Endpoints, Auth, and Editions

For the hosted MCP servers, the connection shape is straightforward and worth knowing before you scope anything:

HOSTED MCP · CONNECTION SHAPE

Production:  https://api.salesforce.com/platform/mcp/v1/<SERVER-NAME>
Sandbox:     https://api.salesforce.com/platform/mcp/v1/sandbox/<SERVER-NAME>

Auth:        OAuth 2.0 + PKCE via an External Client App
Scopes:      mcp_api, refresh_token
Editions:    Enterprise and above; included in Developer Edition

Auth is per user: you create an External Client App in Setup, enable PKCE org-wide, and each user authorizes their own connection, which is exactly what makes the permission inheritance work. Two practical notes from real setups: newly created External Client Apps can take up to 30 minutes to provision, and Salesforce has not published rate limits for the hosted servers yet, so design your agents to back off gracefully rather than assuming headroom.

On the client side, Salesforce's docs name Claude, ChatGPT, Cursor, Postman, and custom agents for the hosted servers, and Claude Code, Cursor, Codex, and Windsurf as the coding agents for development work. If your team already lives in one of those, the toolkit meets you where you are.

How It Fits with Claudeforce, Slackforce, and Coworker

The cleanest way to place the toolkit: the three AIforce products are what Salesforce built on it, and the toolkit is your path to building the fourth thing. Claudeforce puts the CRM inside Claude for sellers, Slackforce puts it inside Slack for teams, and Agentforce Coworker puts an AI teammate inside Lightning. All three run on the same headless architecture you now get direct access to.

The decision rule is simple. If you want the packaged seller experience, start with the plugin and our setup guide. If you want Salesforce inside your own product, an internal tool, a customer-facing agent, or a surface Salesforce has not built, the toolkit is the supported way to do it without screen-scraping or brittle middleware.

Getting Started

If you want to evaluate the toolkit seriously, here is the sequence we would run:

  • Spin up a Developer Edition org. The hosted MCP servers are included at no cost, which makes it a zero-risk sandbox.
  • Connect one MCP client, Claude Code or Cursor is the fastest path, through an External Client App with PKCE, and confirm the permission model does what you expect with a restricted test user.
  • Install the Salesforce Development plugin from sf-skills and let a coding agent do one real task end to end: pull metadata, write a change, run tests, deploy to a scratch org.
  • Pick one workflow that deserves to go headless, something users do outside Salesforce anyway, and pilot it on the Experience Layer rather than building a custom UI.
  • Before scaling, put the governance in place: Testing Center on the agent, Session Tracing turned on, and MCP Risk Scores if you are connecting third-party servers.

That is the same sequence we run with clients. Cloudsheer builds on Salesforce and Agentforce daily, from Agentforce implementations to platform development, and we have been working headless since the TDX announcement. If you want a clear read on what the toolkit changes for your org, and what to build first, book a call at cal.com/cloudsheer-consulting/30min and bring your use case.

FAQ

Frequently Asked Questions

What is the Salesforce Headless Toolkit?

The Headless Toolkit is Salesforce's set of APIs, MCP servers, skills, plug-ins, and developer tools for building and governing agents on the Salesforce platform without going through the browser UI. Announced at Dreamforce 2026 as the developer pillar of AIforce, it exposes data, business logic, and permissions through API, MCP, and CLI so developers can bring Salesforce into any AI, agent, application, or custom interface.

Is the Headless Toolkit the same as Headless 360?

Effectively yes. Headless 360 is the architecture Salesforce announced at TDX 2026 in April: the raw MCP servers, APIs, and CLI exposure of the platform. The Headless Toolkit is the Dreamforce 2026 packaging of that architecture as the developer surface of AIforce. Salesforce's own pages still use both names, so treat them as one thing at two stages of productization.

What parts of the Headless Toolkit are generally available today?

As of late September 2026: the six hosted MCP servers (GA since April 2026, Enterprise Edition and above, included in Developer Edition), the Headless Experience Layer, and the Marketing Cloud Engagement MCP server, plus the open-source sf-skills library and the @salesforce/mcp npm package. The Data 360 MCP server is in developer preview, and Builder Central, Angular production support, and Salesforce in Claude are in beta.

Does headless access bypass Salesforce permissions?

No. Every headless call runs under the calling user's existing profiles, permission sets, org-wide defaults, sharing rules, and field-level security, with authentication handled per user through OAuth 2.0 with PKCE via an External Client App. An agent can only see and change what the person behind the request could see and change in the UI, and Salesforce states that business data is not retained by model providers.

Want to see how this applies to your business?

Book a free 30-minute call. We will walk through your specific use case and show you what's possible.

Book Free Discovery Call
Ask me anything