Salesforce Exposed Its Whole API as Four MCP Tools. Your Permission Set Is the Tool List Now.
Salesforce and Anthropic announced Claudeforce on 26 August, and the part that matters to anyone shipping agents is underneath the launch. Salesforce in Claude runs on the Headless 360 MCP server, which puts the entire Salesforce API surface behind exactly four tools.
One of those tools is called Dispatch. It accepts GET, POST, PUT, DELETE and PATCH, and what it can reach is not fixed in the manifest. It gets resolved at runtime by a semantic search over a vector index of every API and skill in the org.
That is the correct call for context economics, and it quietly retires the tool list as a review artifact. If your agent governance is a set of allow rules keyed on tool names, you now have one name to reason about, and the actual access boundary is the permission set of whoever authorised the connection.
What shipped
Claudeforce was announced on 26 August. Salesforce in Claude ships as a plugin carrying 37 prebuilt sales skills, things like meeting prep, deal health and pipeline review. It is with select pilot customers now, open beta is expected in September 2026, and more skills start landing late in the year.
The rest of the announcement is a model default swap. Claude becomes the default behind Slackbot, Agentforce Vibes, Agentforce Coworker, Claude Tag and Slack Code, and it is the reasoning model behind the Atlas Reasoning Engine. Salesforce serves it through Amazon Bedrock inside its own trust boundary, so the data does not leave for an external API.
For existing Agentforce deployments this changes very little. Claude has been a foundation model option in Agentforce since late 2025, and teams that already picked it in Agent Builder wake up to the same setup they went to bed with. The genuinely new direction is the other one, Salesforce reaching into Claude rather than Claude reaching into Salesforce.
That direction runs on a server that went to beta in early July and has been mostly ignored outside the Salesforce developer community.
Four tools, a hundred skills, one vector index
Headless 360 exposes four tools, and they map to the stages of a request.
Discover takes the agent's reading of what the user wants and runs a semantic search across an index of available Salesforce operations, returning ranked candidates. Describe returns the technical contract for a chosen operation, including APIs, parameters, dependencies and the ordered steps to complete it. Dispatch invokes it, routing to the correct endpoint and enforcing user access guards. Dispatch Read Only does the same thing restricted to GET.
At beta launch there were roughly 100 skills covering user management, Apex triggers, platform events, named credentials and Commerce Cloud orders. Salesforce says thousands more are coming. Connecting requires API v67.0 or later and an External Client App scoped with mcp_api.
Salesforce states the reasoning directly in its own developer blog. Exposing each feature as its own tool would force the model to reason over thousands of tool descriptions, which burns context, tokens and time.
They are not wrong, and the numbers back them. A production agent in early 2026 typically connects five to twenty MCP servers with five to fifty tools each. Ten servers at twenty tools and 500 tokens per definition is 100,000 tokens spent before the user has typed a word. Claude Code now ships MCP Tool Search, which kicks in automatically once tool descriptions would exceed 10% of the context window. The MCP maintainers named progressive tool discovery a priority in the roadmap they published on 22 August. Everyone arrived at the same problem in the same quarter.
Salesforce just took the most aggressive available answer, which makes sense when your API surface is one of the largest in enterprise software.
The manifest stopped describing the agent
For about a year, the tool list has been the practitioner's review surface. It had three properties that made it useful. It was static, so you could diff it between releases. It was named, so a tool called delete_records told you what could happen without reading code. And it was finite, so enabling a server meant accepting a countable set of capabilities.
Four tools breaks all three.
Dispatch is a verb, not a capability. The capability set lives in the index, and the index grows on Salesforce's release schedule rather than yours. An operation added in a Winter '27 release becomes reachable the moment it ships, with nothing in your configuration having changed and no diff for you to review.
Your audit trail degrades the same way. A log line that reads dispatch carries no information. You need argument-level logging, where the argument is an operation identifier and a payload, and most MCP observability built over the last year records the tool name and the outcome.
Your allow rules collapse to a single decision. Tool-name allowlisting becomes all or nothing. The one meaningful control left is enabling Dispatch Read Only and withholding Dispatch, which is a real boundary and worth using, but it is binary and it is the only shape available.
This is also where the design collides with the direction the rest of the ecosystem is moving. Cloudflare's WriteGuard, in private beta since the middle of the month, sorts every MCP tool call into four risk tiers and runs policy before the handler executes. That approach assumes tools are granular enough that the name carries risk information. Point it at a server with four tools where one is a universal verb, and the tier has to be computed from the argument instead. The policy layer stops needing to understand MCP and starts needing to understand Salesforce operations.
Where the check actually lives now
Salesforce is not hiding any of this. Every transaction runs as the authenticated user through the External Client App. Object permissions, field-level security, sharing rules, profile permissions and permission sets all apply. If a person cannot perform an action in the Salesforce UI, their agent cannot perform it through the MCP server either.
The documentation then tells admins to test in a sandbox first and to pay particular attention to admin and developer users, because they carry wide permissions.
That advice is the entire risk model in one sentence. Over-provisioned profiles have been a known and tolerated condition in most Salesforce orgs for years, because the practical rate limiter was a human clicking through a slow interface. Nobody sits down and enumerates everything their own profile permits. An agent with semantic search across every operation in the org does precisely that, deliberately, in seconds.
The failure mode here is not a jailbreak or an injection. It is a correctly authenticated agent doing something the profile always allowed and no human ever got around to doing.
The recommended mitigation is client-side approval prompts before anything that changes configuration or deletes data. That holds until volume arrives. When Claude Code changed its permission model earlier this month, the telemetry behind the decision showed users approving 97% of the prompts they were shown. A confirmation dialog that fires on every write becomes a reflex inside a day.
Before the September beta
Treat the permission set as the tool manifest. The review artifact is now a profile export for whoever will authorise the connection, read as a list of capabilities rather than a compliance checkbox.
Start on Dispatch Read Only and add write access one skill at a time, with a reason written down for each.
Log the arguments, not the tool name, and make sure your MCP observability can capture an operation identifier before you pilot anything.
Remember that agent writes are ordinary writes. Validation rules, Flows, Apex triggers and governor limits fire exactly as they do for Data Loader, and an agent that retries politely can trip all four.
Decide who owns the connection identity. Hosted MCP servers run per-user OAuth so every call carries the person who made it, while the Slack side of this launch uses client credentials against a dedicated integration user. Two different security postures shipped under one announcement, and the audit story is very different depending on which one a workflow runs through.
The four-tool pattern is going to spread, because the context argument against thousand-tool manifests is unanswerable and the token bill is real. What travels with it is the part worth internalising now. The tool list is no longer the thing that tells you what an agent can do. The connected identity is, and for most orgs that identity has never been audited with an agent in mind.