Headless MCP on Salesforce: How to Adopt Headless 360 and Size the ROI

Headless MCP means running Salesforce as a set of Model Context Protocol tools an AI agent calls directly, with no user interface in the loop. Salesforce ships this as Headless 360: hosted MCP servers, generally available since April 2026, plus the Headless 360 MCP Server, in beta since July 2026. The agent authenticates as a real user and runs CRM and setup work under your org's existing security, so a natural-language prompt becomes a governed Salesforce operation. This guide covers what it is, how it works, what it can do today, the security it enforces, how to adopt it safely, what your security review must cover, how to size the ROI, and where a partner fits. Tekunda is the first firm delivering headless Salesforce with MCP in production, so the adoption rules below are the ones we apply on every rollout.

What is headless MCP on Salesforce?

The Model Context Protocol is an open standard that lets an AI model discover and call external tools, APIs and data at runtime, so any compatible client can talk to any compatible server without custom glue code. "Headless" means there is no screen in the loop: the work runs through the API and agent layer instead of clicks in the Lightning UI. Together, a headless MCP setup lets Claude, Cursor, Agentforce or any MCP-compatible client read records, run queries and execute setup operations by calling Salesforce tools directly. The person sets the intent; the agent finds the right operation and executes it.

That matters because most agentic prototypes never reach production. They work in a demo, then fall over the moment they meet real permissions, real data volumes and a security team. Headless MCP is the pattern that closes that gap, because the agent inherits context and policy from the platform rather than reinventing them.

What is Salesforce Headless 360?

Salesforce introduced Headless 360 at TDX in April 2026 as an initiative to expose every platform capability as an API, an MCP tool or a CLI command, so the browser becomes optional rather than required. Per the Salesforce Developers blog, it spans 60+ MCP tools, 30+ coding skills, more than 4,000 existing APIs and 220+ CLI commands.

Separate two layers, because both carry the Headless 360 name:

• The standard hosted MCP servers handle data work: SObject All, Reads, Mutations and Deletes, plus Data 360 and Tableau Next. Generally available since April 2026.
• The Headless 360 MCP Server collapses setup and integration work into four tools. In beta since July 2026.

How does the Headless 360 MCP Server work?

Its headline idea is restraint: agents get four tools, not four thousand. An org has thousands of features, and loading every endpoint into a model's context wrecks its decision-making, so the server presents a small, stable surface and does the routing itself:

• Discover - semantic search across a vector index of APIs and skills, returning ranked candidates for the request.
• Describe - the technical spec for a chosen skill: parameters, dependencies, ordered steps.
• Dispatch - invokes a skill, with access control enforced.
• Dispatch Read Only - runs read-only operations.

The discover-describe-dispatch loop keeps the model's context small while the catalogue behind it grows. The beta launched with roughly 100 skills, with thousands planned.

What can headless MCP do in Salesforce today?

At launch the Headless 360 MCP Server covers:

• User management, including creating and deactivating users, resetting passwords and assigning permissions.
• Apex trigger development.
• Event-driven integrations across Change Data Capture, platform events and event relays.
• Named credential configuration.

Beyond setup, the hosted data servers let an agent list leads, run SOQL and update fields in natural language, and Data 360's MCP surface exposes more than 200 APIs so an agent can build, map and query unified data with plain-language requests. The same pattern extends to the systems around Salesforce: a telephony integration that syncs call logs to records, or a WhatsApp conversation, becomes another set of governed actions an agent triggers, with Salesforce still the system of record. Instead of a custom connector for every AI surface, you expose one governed server and any MCP-aware client reaches it.

Salesforce widened Headless 360 again on 19 August 2026, adding a Slackbot MCP client alongside the Data 360 server and 100+ more agent skills, and the same shift is showing up in the DevOps tooling market too: Copado's Agentia added its own headless MCP mode in September 2026. Budget for beta, not GA, while you evaluate: the Headless 360 MCP Server itself is still in beta as of this writing, even as adjacent pieces like Data 360 and the Slackbot client move faster.

Is headless MCP secure?

An agent that can create users and deploy Apex is exactly as dangerous as the permissions behind it, so this is the question that matters. The reassuring part is that Headless 360 does not invent a new trust model; it rides on the one Salesforce already enforces. Every transaction runs as an authenticated user, scoped through an external client app with the mcp_api scope and OAuth 2.0 with PKCE, and every action is bounded by four layers:

• Identity - the agent acts as an authenticated user, never above them.
• Access - profiles, permission sets, org-wide defaults, sharing rules and field-level security still apply.
• Invocation scope - only explicitly exposed skills can be called.
• Governance - validation rules, transaction security policies, approval chains and governor limits still fire.

The model provides intelligence. The platform provides identity, access, capabilities and governance, the context that makes intelligence useful.

If a person cannot do it in Salesforce, their agent cannot do it through MCP either. Salesforce also ships the standard servers disabled, and separates read, create/update and delete into different servers, so you never grant delete by accident. Enable it deliberately, because "delete all leads" is one prompt away once you do. Basic hosted MCP access needs Enterprise Edition or above and is not locked behind Agentforce licensing.

How do you adopt headless MCP safely in production?

The demos are easy. Production is where teams get burned. The rules we apply at Tekunda on every rollout:

• Start read-only. Give agents Dispatch Read Only or the SObject Reads server before any write path is live.
• Scope a dedicated permission set. The agent inherits its user's access, so give it its own least-privilege user, not an admin login.
• Require approval for writes. Keep the client's permission mode on 'needs approval' for create, update and delete until you trust the flow.
• Log every dispatch. Capture which skill ran, as whom, and against what records, so an agent action is as auditable as a human one.
• Rehearse in a sandbox. Never let a new skill touch production data on its first run.

The security Salesforce enforces is a floor, not a strategy. The risk is not the protocol; it is over-broad permissions on the connected user, and an agent acting as that user can still do broad damage fast. If you are wiring several agents together, or want one action surface that spans Salesforce and the ERP, telephony and devices around it, the handoff design matters as much as the permissions - see running CRM actions from one agentic hub and what makes agent-to-agent handoffs work in production. When you want that rollout designed and governed properly, our Salesforce services team does exactly this work.

What belongs on a security review checklist for MCP-connected apps?

If you package software for the AppExchange, exposing capabilities over MCP does not exempt you from the AppExchange Security Review; it raises the stakes. Our short version, drawn from shipping through the review ourselves:

1. Enforce CRUD, FLS and sharing in every Apex entry point an agent can reach, not just the UI.
2. Kill SOQL injection with bind variables, never string-built dynamic SOQL.
3. Encrypt data in transit with TLS 1.2 or higher and at rest with AES-256.
4. Scope named credentials and connected apps to the minimum, and prove it.
5. Set security headers and cookie flags (X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security, Secure and HttpOnly).
6. Scan before you submit with Salesforce Code Analyzer plus a scanner such as Checkmarx, OWASP ZAP or Burp Suite, and document every false positive.
7. Document data storage, authentication and every external integration the agent uses.

Agentic surfaces add one line to that list: confirm no tool can escalate beyond the running user's permissions. A headless surface removes the human who used to be the last check, so the org's own controls have to carry that weight. Treat the agent as another authenticated client: if each dispatch would pass review on its own, the headless layer above it will too.

For those controls in the order that matters, work through our Salesforce security review checklist, and when the scanners flag issues you have already handled, our guide to documenting false positives keeps them from stalling your submission.

How do you size the ROI of a headless MCP rollout?

Size it before you build. Salesforce publishes an Agentforce ROI calculator that projects cost savings and efficiency over a three-year horizon and estimates the Flex Credits a use case will consume, the consumption unit Salesforce bills agent usage in. It is a fair starting point, but it runs on generic assumptions, and a defensible model uses your numbers.

Ground it with a simple frame, all normalized to a monthly figure: (hours saved per process x monthly volume x loaded rate) - (monthly Flex Credit spend + build cost divided over the payback horizon + monthly governance). Convert Flex Credits to their currency cost so every term is money per month. Headless MCP moves the 'hours saved' side hardest on repetitive, multi-step setup and data tasks, the work that used to mean a dozen clicks across several screens, because it removes the interface tax: work that never needed a screen now runs as a direct call. The same math holds for AI voice agents on a telephony integration: model the deflected minutes and freed rep hours by volume, handle time and the Flex Credits each automated interaction consumes.

Where does a Salesforce PDO or Agentforce partner fit?

Adopting headless MCP safely is a governance project as much as a build. A Salesforce PDO (Product Development Outsourcer) builds commercial apps on the platform, packages them correctly and shepherds them through AppExchange security review. That skill set maps directly onto headless MCP: an ISV exposing its product as MCP tools needs someone who can design the tool surface, enforce the running-user model and pass review the first time. An Agentforce partner does the same for an internal agent, wiring the four tools to real business logic rather than a demo. When you evaluate either, weigh three things:

1. Do they design the permission model first, or bolt it on after the demo works?
2. Can they show real headless agent work against a governed org, not slideware?
3. Do they own integration, packaging and the security review, or hand you off midway?

That combination of platform depth and governance discipline is what Tekunda brings to headless projects, and we run it in production today, not on a roadmap. Our headless MCP team maps the safe path for your org, from tool surface to security review.

FAQ

Is headless MCP the same as Agentforce?

No. Agentforce is Salesforce's agent product; headless MCP (Headless 360) is the tool surface an agent calls. You can drive it from Agentforce or from an external client like Claude or Cursor.

Is the Headless 360 MCP Server generally available?

No. It entered beta in July 2026, with roughly 100 skills at launch, on hosted MCP servers that reached general availability in April 2026. Pilot before you commit critical flows.

Does an agent using headless MCP bypass Salesforce security?

No. It runs as an authenticated user with the mcp_api scope, and CRUD, field-level security, sharing rules and permission sets are all enforced. Give the agent a least-privilege user.

Do I need an Agentforce license to use headless MCP?

Basic hosted MCP access requires Enterprise Edition or above and is not gated behind Agentforce licensing, though metering terms can change with notice.

Do I need a separate security review for an MCP-connected app?

AppExchange packages still go through the standard Security Review. MCP adds no separate process, but it widens the surface, so CRUD, FLS, sharing and least-privilege access must hold at every entry point.

Do we need code to adopt it?

Not for basic use. You activate the hosted MCP server in Setup and connect an MCP-compatible client. Production governance is where planning pays off.

Where should we start?

Enable a read-only server first, connect it to one client, confirm the permission model behaves, then widen scope. Bring in a partner if governance is not your team's core skill.

Headless MCP is how agent-driven work reaches Salesforce, and it is already in beta. If you want that surface to move fast without widening your attack surface, that is the build and security work Tekunda does every day. Book a short scoping call.