LATdx ships a Model Context Protocol  (MCP) server so AI coding agents (Claude Code, Codex, Cursor, and any MCP-capable client) can run your Apex tests through LATdx and get structured results back instead of waiting on sf apex run test.

You attach it once. The agent then decides when to call it.

Prerequisites

• latdx installed and on your PATH (see installation).
• A Salesforce org authenticated via the Salesforce CLI, set as your default (sf config set target-org <alias>), or pass an org explicitly per call.

The one command you configure

Every MCP client launches the same stable invocation:

latdx mcp serve

It speaks MCP over stdio: the agent spawns it, talks JSON-RPC on stdout, and reads logs on stderr. There is nothing to keep running yourself and no port to manage. Because the invocation is stable, you never have to track how individual agents change their configuration formats.

Connect your agent (CLI)

Every client launches the same command; only how you register it differs. Claude Code and Codex each have a CLI for it.

Claude Code

claude mcp add latdx -- latdx mcp serve

Confirm with claude mcp list.

Codex

codex mcp add latdx -- latdx mcp serve

Equivalently, edit ~/.codex/config.toml (or project-scoped .codex/config.toml):

[mcp_servers.latdx]
command = "latdx"
args = ["mcp", "serve"]

Cursor

Cursor has no CLI command to add a server (its cursor CLI only lists/enables servers it already knows). Register it in the UI or a config file:

• Settings -> Tools & MCP -> New MCP Server, or
• create .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):

{
  "mcpServers": {
    "latdx": {
      "command": "latdx",
      "args": ["mcp", "serve"]
    }
  }
}

Any other MCP client

Point it at the command latdx with arguments mcp serve, transport stdio. That is the entire contract.

No CLI? Add it from the app

If you use a desktop app instead of a terminal, register the same command through the app’s config.

Claude Desktop app

1. Open Settings -> Developer -> Edit Config (this creates the file if it does not exist). The file is claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/, Windows: %APPDATA%\Claude\).

2. Add the server:

   {
     "mcpServers": {
       "latdx": {
         "command": "latdx",
         "args": ["mcp", "serve"]
       }
     }
   }

3. Fully quit and reopen Claude Desktop so it loads the server.

Codex IDE extension

The Codex VS Code / IDE extension reads the same ~/.codex/config.toml as the CLI. Open MCP settings -> Open config.toml from the extension’s settings, add the [mcp_servers.latdx] block shown above, and reload.

If the app cannot find latdx

Desktop apps do not inherit your shell PATH, so a bare latdx may fail to launch. Use the absolute path instead. Find it with which latdx, then set command to that full path (for example /Users/you/.bun/bin/latdx) and keep args as ["mcp", "serve"].

Tools the agent gets

run_apex_tests returns one compact JSON object the agent parses, with no prose wrapper: success, passed, failed, durationMs, and a short cache summary. On failure it adds failures, each carrying the failing Class.method names, the message, and a trimmed stack trace; methods that fail the same way are grouped into one entry. Anything not worth acting on is omitted (no zero counts, no passing methods), so the payload stays small even on large suites. Pass includePassing to also list the names of methods that passed. Pass failFast to stop at the first failing test: the result carries stoppedEarly: true and covers only the methods that ran (the rest are left for a follow-up run).

Example

Once attached, you can prompt the agent naturally:

“Run the AccountServiceTest class and fix any failures.”

The agent calls run_apex_tests with classNames: ["AccountServiceTest"], reads the returned failures, edits the code, and re-runs, all without you copying test output back and forth.

How it relates to the CLI

The MCP server runs tests through the same path as latdx test run, including the warm daemon org-context cache, so agent-driven runs are as fast as your CLI runs and produce the same results. The agent can do anything latdx test run does, minus the flags the tools do not expose.

Notes

• stdout carries the JSON-RPC protocol; the server never prints anything else there. Diagnostics go to stderr, which clients ignore.
• If no org is resolved (no orgAlias and no sf default org), the tool returns a clear error telling you to set one.
• The first call in a workspace starts the LATdx daemon in the background; subsequent calls reuse it for speed.