SOLVD.cloud
Talk through your project
All articlesArticle

Salesforce Headless Toolkit: What Headless 360 Means Now

Becca Lough

Before an AI assistant changes an opportunity, your sales manager has to know why that change is the right one. Connecting the assistant to Salesforce is only a small part of that decision.

Salesforce Headless Toolkit gives developers and AI tools a way to work with Salesforce outside its usual screens. It carries forward what Salesforce introduced under the name Headless 360. The useful question for your team is which job you move off those screens first, and what evidence you want in hand before an assistant is allowed to change a record.

Quick answer: As of October 2026, Headless Toolkit covers several capabilities, and they sit at different release stages. Salesforce's standard hosted MCP servers are generally available, while the specific Headless 360 MCP Server is still in beta. Start with one narrow task, confirm the exact tools it needs, and test its decisions before you widen access.

What Salesforce Headless Toolkit means

Headless means you separate the work Salesforce performs from the screen a person uses to ask for it. A developer can work through a coding assistant, or an employee can work through an AI client, while Salesforce supplies the data underneath and the operations it supports.

Salesforce's Headless Toolkit overview describes access through APIs, Model Context Protocol tools, and command-line commands. APIs let software request operations. MCP gives AI applications a standard way to find and call tools. Command-line tools let developers run commands directly.

Start with the operation your workflow needs, then confirm which access method supports it. Check the documentation before you assume every feature works through every method.

Your team can also keep using Lightning. Salesforce positions headless access as another way in, alongside the browser, and is still building in Lightning, including Agentforce Coworker. You can move one useful task into another interface without planning to replace the whole CRM.

SOLVD's headless CRM services focus on that practical change, where agents carry routine work and people keep oversight while Salesforce holds the customer record.

How Headless Toolkit relates to Headless 360

Salesforce introduced Headless 360 on April 15, 2026. That announcement described more than 60 new MCP tools and more than 30 preconfigured coding skills, along with an experience layer for delivering interactions across different interfaces.

As of October 2026, Salesforce’s main headless product page uses Headless Toolkit. In September, Salesforce rebranded Headless 360 as AIforce and launched it at Dreamforce alongside Claudeforce, Slackforce, and Agentforce Coworker, with Headless Toolkit as the developer layer that powers it. In October, Marc Benioff announced the name is now SIForce, though Salesforce’s own pages still say AIforce. Older announcements and some technical documentation still say Headless 360, so expect to see all of these names for a while. Those launch counts describe the wider offering, not the number of tools inside any single server.

Salesforce also has a specific product called the Headless 360 MCP Server, and you have to check its release status on its own. Hosted MCP servers being generally available does not mean this one is.

Agentforce plays a related role here. Salesforce describes Agentforce as its platform for building and deploying AI agents. Headless Toolkit gives you ways to reach Salesforce capabilities from different tools and interfaces. Pick the agent experience and the access method together, based on the work you actually want it to perform.

What is available as of October 2026

The distinction that matters most for planning is between developer tooling, business-data access, and broader administrative operations.

  • Standard Salesforce hosted MCP servers. As of October 2026, Salesforce announced GA in April 2026 for Enterprise Edition and above. What to do: Check the specific server and any product requirements before you select it.
  • Salesforce DX MCP Server. As of October 2026, this local developer server reaches end of life on November 2, 2026, and Salesforce is moving that tooling to skills. What to do: Plan development and deployment work around Salesforce’s skills and plugins, and keep that access separate from employee access to CRM records.
  • Headless 360 MCP Server. As of October 2026, the current reference labels it beta and requires API v67.0 or later. What to do: Review the supported operations and the beta terms before you rely on it.
  • Data 360 MCP Server. As of October 2026, the current reference requires a Data 360 license and API v66.0 or later. What to do: Use its own documentation and limits when the task depends on Data 360.

Sources: Salesforce's hosted MCP GA announcement, DX and hosted MCP comparison, Headless 360 server reference, and Data 360 server reference.

Salesforce also documents hosted MCP access in Developer Edition. That gives developers a place to try it out, though production planning still depends on the requirements for the product and server you pick.

For ordinary CRM reading, the standard server catalog includes SObject Reads, which supports reading and querying without changing records. Separate servers handle creating and updating records, deleting them, or combining those operations. Choose the smallest set of capabilities that covers the job in front of you.

The beta Headless 360 server takes a different approach. Salesforce documents four core tools: discover, describe, dispatch, and dispatch_readonly. Those tools find an available operation, explain what it requires, and run it, with a separate read-only path for execution. Salesforce's beta announcement explains the design. A handful of tools can reach a growing library of operations, so the tool count by itself tells you very little about how much authority you are handing over. At beta launch, most of those operations are admin Setup tasks, so for everyday record work the SObject servers are usually the better fit.

What stays under Salesforce control

Today, requests to Salesforce-hosted MCP servers run as the user who authorized the connection, so object permissions, field access, and record sharing all still apply. Salesforce's security documentation specifies OAuth authorization code flow with PKCE, which protects the sign-in exchange. It does not support machine-to-machine authentication for these hosted servers.

An administrator has to enable the server and configure an External Client App. The hosted MCP connection uses the mcp_api scope. Headless work still runs through an authenticated connection.

Plan around the person who authorizes that connection, and check what that person can actually see and change. Keep any unattended integration requirements separate from this per-user access path.

That is changing. Salesforce is targeting November for agent registration, which gives each external agent its own identity and lets admins grant it a narrower permission set than the person it works for. Salesforce has said MCP server use will require registration within three months of its notice, and each successful call a registered agent makes over MCP or API will be metered against Flex Credits. Plan for cost as well as access, and confirm with Salesforce how agent and user permissions combine before you rely on either one.

Salesforce permissions decide what a user is allowed to do, and your workflow still has to decide when a specific change is justified. A sales manager may have permission to move an opportunity stage, but the assistant still needs solid evidence that the deal meets your team's stage criteria.

For the connection concepts, see our Salesforce MCP explainer. Use the current vendor documentation for the exact configuration.

Choose the data source before the agent's job

The Headless 360 MCP Server and the Data 360 MCP Server cover different ground. Salesforce's reference draws the line clearly: the Data 360 server works with Data 360 data, while Headless 360 reaches broader Salesforce operations.

The current Data 360 reference describes access to its Connect API for querying, transforming, and activating customer data. It also says this server replaces an earlier one that is now documented as legacy. Older descriptions of a query-only server can send a rollout plan in the wrong direction. Calls through this server also count against the underlying Connect API limits and Flex Credit usage, so include them in your cost estimate.

Say you want an account briefing. Decide which facts belong in the answer. Salesforce opportunities may cover the pipeline question on their own. A renewal recommendation may also need product usage or finance data. Write down where each fact comes from and how your team checks that it belongs to the right customer.

SOLVD's data practice covers data strategy, Databricks foundations, and Salesforce Data 360 activation. That work matters when the workflow depends on information spread across systems, because an MCP connection by itself does not tell you whether those records agree with each other.

Require evidence before you allow writes

We recommend you approve one business action at a time. Before an assistant can change records, make it show you the proposed change and the source information behind it.

Take an opportunity update. In the first stage, connect the assistant to a read-only server like SObject Reads so it can read the records it is allowed to see and prepare a suggested update for review. Have the sales manager compare that suggestion against the source information and your team's rules. Anything unclear goes back to a person before a single field changes.

Use these checks to decide whether the workflow is ready for write access:

  • Record selection: Can the reviewer confirm the exact record the assistant means to change, even when several accounts have similar names?
  • Evidence: Does the source support the proposed field value, or is the assistant filling a gap with an assumption?
  • Change boundaries: Does the workflow leave unrelated fields alone and stop when the requested action goes past its scope?
  • Recovery: Can your team see what happened, handle a partial failure, and keep a retry from duplicating the work?

These are acceptance checks we recommend, not built-in promises of Headless Toolkit. They give the business owner something concrete to approve. Test them in a sandbox before production use, and keep a person in the loop wherever a wrong change would cost you.

SOLVD's Headless Readiness Assessment helps you look at one workflow's data, ownership, and operating gaps. The result is a planning aid, not approval to deploy.

Before launch, also settle who reviews failed requests and who can shut access off. Our managed services can support ongoing Salesforce, data, and AI work when your team wants help carrying that responsibility.

Bring one workflow you would like to improve, along with the records and decisions it depends on. We can help you work out a sensible first scope in a short fit conversation.