Using the CLI as an MCP host

Like Claude Code, the TestRelic CLI is a full MCP host. It spawns your local MCP servers, lists their tools, and advertises them to the cloud agent. When the agent calls one, the CLI executes it locally and posts the result back — the agent's stream continues with your local tool's output.

{
  "mcpServers": {
    "everything": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-everything"]
    }
  }
}

A hand-recreated slice of the real host — connecting a server, the /mcp health panel, the mode-scoped capability set, and secret masking in a tool result.

Manage servers

Use testrelic mcp add | list | remove to manage the local MCP servers the agent can call:

# stdio child process
testrelic mcp add everything -- npx -y @modelcontextprotocol/server-everything

# streamable HTTP (HTTPS endpoints supported)
testrelic mcp add --transport http myserver https://example.com/mcp

# write to the global config instead of the project file
testrelic mcp add --global everything -- npx -y @modelcontextprotocol/server-everything

testrelic mcp list
testrelic mcp remove everything

• --transport http adds a streamable-HTTP server; HTTPS endpoints are supported.
• --global writes to ~/.testrelic/mcp.json instead of the project-local ./.mcp.json.
• Presets — common servers can be added by short name without typing the full command.

Config files

Project config lives in ./.mcp.json (the Claude-Code-compatible format); global config in ~/.testrelic/mcp.json. On a name collision, the project config wins.

{
  "mcpServers": {
    "everything": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-everything"]
    }
  }
}

How a tool call flows

On startup the CLI spawns every configured server, lists its tools, and advertises them to the cloud agent as <server>__<tool> (for example everything__echo). When the agent decides to call one:

1. The cloud agent emits a client_tool_use request.
2. The CLI executes the tool locally against the matching MCP server.
3. The CLI posts the result back, and the agent's stream resumes with that output.

Use /mcp in the interactive UI to see live server health and each server's tool list.

Capabilities and limits

The host advertises a set of capabilities to the cloud agent via TESTRELIC_MCP_CAPS. These must be valid server capability values, and which set is available depends on your mode:

• Cloud mode — the full capability set is available.
• Local mode — capabilities are read-only.

A single turn can surface up to 200 client tools to the cloud agent, matching the deployed server's limit. See Capabilities for what each one covers.

Secret values are masked in tool results

Some MCP servers hand back more than you asked for — a browser-automation server's page snapshot, for example, inlines the live value of every form field, including anything typed into a password box. The host masks these before they go anywhere:

• Any form control that reads as a credential (by label, placeholder, or the value's own shape) is replaced with [hidden] in the tool result — detection doesn't depend on recognizing the secret, so an ordinary-looking password is hidden too.
• Once a value has been hidden once in a session, it's remembered and stripped from every later tool result, from any server — a console log line, a network body, or a direct field read.
• Masking runs on every harness result, independent of tool name, so a new MCP tool is covered automatically without a CLI update.

Refs, roles, names, and everything else in the result survive untouched, so the agent can still see and act on the field — it just never sees, echoes, or persists the value.

Next steps

→ Slash commands · Configuration