Salesforce Headless 360

The Apex side
of Headless 360,
on your machine.

Headless 360 turns your Salesforce org into an MCP-callable surface for AI agents. Nimbus runs the Apex side of that surface offline — every @InvocableMethod, @AuraEnabled, @RestResource, and Flow you expose as a custom MCP tool, tested locally in under a second per iteration.

The short answer

Salesforce Headless 360 (announced TDX 2026, GA April 2026) lets admins create MCP servers in Setup that expose Salesforce data and Apex logic to external AI agents like Claude Code, Cursor, and Codex. The standard servers wrap SOQL, DML, and metadata APIs. Custom servers wrap your existing Apex — specifically @InvocableMethod, @AuraEnabled, @RestResource, and autolaunched Flows.

Nimbus has supported all four of those Apex hooks since day one. The "MCP wrapper" Salesforce adds is metadata configuration, not new Apex code. Your Headless 360 custom MCP servers are testable in Nimbus today, with no additional setup.

On top of that, Nimbus itself ships an MCP server (nimbus mcp) that registers alongside the Salesforce DX MCP server. Agents call both: live-org tools through Salesforce, local test execution through Nimbus.

Custom MCP servers run locally

A custom MCP server in Salesforce is configured in Setup → Integration → Salesforce MCP Servers. The configuration is no-code; the actual tools exposed by the server are existing Apex artifacts:

Apex hookBecomes an MCP tool of
@InvocableMethodInvocable actions exposed as MCP tools
@AuraEnabledApex methods callable from MCP clients
@RestResourceCustom Apex REST endpoints mapped as tools
Autolaunched FlowFlows exposed as MCP tools

Nimbus executes every one of these constructs in its embedded interpreter against an embedded PostgreSQL — the same fidelity it gives any other Apex code. There is no separate "MCP test mode" to enable. Write the test, run it, get a result.

bash
// Custom MCP tool: an @InvocableMethod
public class WeatherLookup {
  public class Input {
    @InvocableVariable(required=true)
    public String city;
  }
  public class Output {
    @InvocableVariable
    public Decimal tempF;
  }

  @InvocableMethod(label='Lookup Weather')
  public static List<Output> run(List<Input> inputs) {
    Output o = new Output();
    o.tempF = 72;
    return new List<Output>{ o };
  }
}

// Local test — runs in Nimbus exactly the same as
// any other invocable. The MCP wrapper is metadata
// the runtime never has to know about.
@isTest
private class WeatherLookupTest {
  @isTest static void returnsValueForCity() {
    WeatherLookup.Input i = new WeatherLookup.Input();
    i.city = 'Berlin';
    List<WeatherLookup.Output> out = WeatherLookup.run(
      new List<WeatherLookup.Input>{ i }
    );
    System.assertEquals(72, out[0].tempF);
  }
}

Nimbus ships its own MCP server

nimbus mcp exposes the local test runner to AI agents over standard Model Context Protocol stdio. Agents register Nimbus next to the Salesforce DX MCP server and get fast, structured access to local execution alongside live-org tools.

Three tools surface to the agent:

  • run_apex_tests — run by class, method, pattern, or path. Returns pass/fail counts, failure objects with file/line, and total duration. Optional timeout_seconds and max_failures bound runtime and payload size.
  • get_coverage — per-class line coverage from the most recent run.
  • list_test_classes — every @isTest class in the project, no DB hit.
bash
# Register Nimbus with Claude Code
claude mcp add nimbus -- nimbus mcp

# An agent's typical loop:
#  1. read code
#  2. call run_apex_tests("MyTest.testCase")
#  3. read JSON failure: {file, line, error}
#  4. edit
#  5. call run_apex_tests again
# Round trip: under a second per iteration.

Standard MCP servers

Headless 360 ships eight standard MCP servers out of the box. Each wraps platform APIs that Nimbus already simulates locally — SOQL queries, DML, metadata describes, custom- metadata access. Tests that exercise code paths these servers reach through still run against the embedded database with no extra wiring.

ServerWraps
sobject-readsSOQL queries, record describes, read-only access
sobject-mutationsCreate and update operations on standard and custom objects
sobject-deletesDelete operations on standard and custom objects
sobject-allFull CRUD plus query and search
data-cloud-queriesData Cloud unified SQL queries
metadata-expertsMetadata API tools for describing and editing org config
salesforce-api-contextREST API Catalog tools
engagement-interactionMarketing/Slack engagement tools

What's not covered yet

Headless 360 today is a one-way surface: external agents call into Salesforce. There is no equivalent for Apex code to call out to an MCP server, so there is nothing for Nimbus to simulate on that side. If Salesforce adds an Apex-side client API in a future release, Nimbus will follow with mocking and recording support modelled on its existing HTTP-callout infrastructure.

The closest related path that does ship today is Apex invoking an Agentforce agent. From Apex's point of view the boundary is the agent, not MCP — so it's mockable as a normal invocable action without any MCP-specific layer.

Try it

If you have a Salesforce project with custom @InvocableMethod or @RestResource classes — whether or not you've wrapped them as MCP tools yet — Nimbus will run their tests in under a second.

bash
# Install (macOS / Linux)
curl -fsSL https://install.testnimbus.dev | sh

# Windows — works in any shell
powershell -c "irm https://install.testnimbus.dev/win | iex"

# From your Salesforce project root
nimbus init
nimbus test

# Hand the local runner to your AI agent
claude mcp add nimbus -- nimbus mcp

See also: AI & Agentic Coding · nimbus mcp reference