Headless Salesforce and MCP: Running CRM Actions From One Agentic Hub

The short answer: headless Salesforce means the platform's data, logic and workflows are callable without the Lightning UI, and an MCP server is the standard way to expose those calls to an AI client. Together they give you one action surface, so an agent, a Slack thread or your own front end can run a CRM action and an ERP action in the same step. Salesforce made this official at TrailblazerDX on 15 April 2026 with Headless 360, and its hosted MCP servers became generally available the same month for Enterprise Edition and above.

What does headless Salesforce actually mean now?

It means the browser is optional. Every capability is reachable as an API, an MCP tool or a CLI command, so the system of record can be driven by something other than a Lightning page. That was the framing at TrailblazerDX 2026, alongside more than 60 new MCP tools and an experience layer that renders components into Slack, Teams, mobile and MCP-compatible clients.

Two clarifications, because both get muddled:

• Headless is not UI-less. It means the interface is a choice rather than a dependency. Most headless builds still have a screen. It just is not the org.
• Headless is not rip and replace. Your objects, flows, validation rules and sharing model stay exactly where they are. What changes is who is allowed to call them.

What is an MCP server in a Salesforce context?

An MCP server publishes a list of tools an AI client can call, with typed inputs and a permission model behind them. In practice you will meet three kinds:

• Salesforce hosted MCP servers, generally available since April 2026 for Enterprise Edition and above, exposing org data, Flows, Apex invocable actions, AuraEnabled methods and named queries.
• The Salesforce DX MCP server, aimed at developer workflows such as deploying metadata and running Apex tests.
• Your own MCP server, which is where the interesting work sits, because it is the only one that can span Salesforce and everything around it.

The security model is the part worth memorising. The hosted server authenticates per user with OAuth 2.0 and PKCE, and the agent acts inside that user's permissions, with CRUD, field-level security and sharing rules still enforced. An agent is not a superuser.

Why is the value a single action surface, not a nicer UI?

Here is the gap in almost everything written on this topic. Most of it describes Salesforce exposing Salesforce. That is useful, and it is not where the pain is.

Real operational work does not stay inside one system. "Approve this credit exception, release the order and tell the customer" is three systems and one intention. Today that intention is executed by a person tabbing between the CRM, the ERP and a telephony console, translating between them by hand. Every one of those translations is a chance to be wrong.

A single action surface collapses the tab-switching into one callable action:

• The agent, or the front end, calls one tool.
• The tool orchestrates the CRM write, the ERP call and the notification.
• The permission check happens once, somewhere you can audit.
• A failure in any leg is one failure, not a half-finished process nobody owns.

A headless implementation that only exposes CRM has moved the buttons. One that exposes intentions has removed the swivel chair.

What does one action hub look like across CRM and the systems around it?

1. Salesforce stays the system of record. Objects, sharing and validation are untouched.
2. An MCP layer publishes intentions, not tables. release_order, not update_order_record.
3. Connectors sit behind each intention: ERP, finance, telephony, scheduling, connected devices. We run this across more than 70 enterprise systems.
4. One identity model. The caller's permissions decide what the tool will do, in every system it touches.
5. Clients are interchangeable. Claude, Cursor, Agentforce, a Slack app or your own front end all call the same tools.
6. Every call is recorded as a business event, not just an API hit.

Tekunda has been building this shape since before it had a product name, and to our knowledge we are the first firm delivering headless CRM plus MCP action hubs in production.

What do most teams get wrong?

• Publishing objects instead of actions. A tool per object gives an agent a thousand ways to make a mess. A tool per business intention gives it one right way.
• Skipping idempotency. Agents retry. If release_order is not idempotent, a retry ships the order twice.
• Letting the agent own the permission. Run as the user, not as an integration account that can do everything.
• No approval gate on irreversible actions. Read freely. Write with a check on anything financial or customer-facing.
• Treating it as an integration project. It is an interface design project that happens to require integration.

Where should you start?

1. Pick one workflow that already crosses two systems and annoys somebody every week.
2. Write down the three or four intentions it contains, as verbs.
3. Implement them as MCP tools, with typed inputs, per-user auth and one audit line each.
4. Point two different clients at them, an agent and a Slack action for instance, to prove the surface is genuinely shared.
5. Only then widen the catalogue.

FAQ

Does headless Salesforce mean giving up the Lightning UI?

No. It makes the UI optional. Most implementations keep Lightning for the people who like it and add other entry points for the people who do not.

Is the Salesforce hosted MCP server enough on its own?

It is enough to let an AI client work inside your org. It is not enough for actions that span the org and other systems, which is where a custom MCP layer comes in.

Is an agent with MCP access a security risk?

It carries the risk of the identity it runs as. With per-user OAuth, CRUD, field-level security and sharing rules still apply, so the answer is to scope the user rather than to trust the agent.

Do we need Agentforce to do this?

No. MCP is an open standard, so Claude, Cursor and your own applications can call the same tools. Agentforce is one client among several.

Tekunda builds headless Salesforce implementations and MCP action hubs across CRM, ERP, telephony and connected devices. If your team is tab-switching through a process that ought to be one action, that is the workflow to start with.