- A database server. The agent can read the schema and access policies and see tables left readable without them, rather than guessing from responses.
- A hosting or infrastructure server. Deployments, domains and environment variable names tell it what is really running, so it tests what exists instead of what it discovered by crawling.
- An issue tracker. Known and accepted risks stop the agent re-reporting findings you already triaged.
- A logging server. Reading logs lets it confirm an exploit attempt actually landed instead of inferring it from a status code.
Setup
Create the file~/.strix/mcp-servers.json. It holds a JSON list of the servers you want the agent to reach. Each entry is either a local stdio server that Strix launches as a subprocess, or a remote http server.
Create the directory if it does not exist, then write the file:
~/.strix/mcp-servers.json. The example below shows one of each transport: a local filesystem server over stdio and a remote GitHub server over http with a bearer token:
command, args, url, and token to match your own servers.
Fields
string
required
A short label for the connection. Each server’s tools are namespaced by
name (for example local_fs_read_file), so two servers can offer the same
tool name without colliding.string
stdio for a local subprocess server, or http for a remote server.string
For
stdio servers: the executable Strix launches (for example npx).array
For
stdio servers: the arguments passed to command.string
For
http servers: the server endpoint URL.object
For
http servers that need a bearer token:
{ "kind": "bearer", "token": "your-token" }.array
Restrict which tools the agent can call. Omit it to expose every tool the
server offers, or set it to a list of tool names to allow only those. Strix
does not decide for you which of a server’s tools only read and which change
things, so run the server in its own read-only mode if it has one.
string
Free-text notes for the agent about what this connection is and how you want
it used, for example “Staging analytics database, read-only, prefer aggregate
queries.” When set, the notes are given to the agent at the start of the run
as a description of the connection.
Choosing connections per run
By default every connection in the file is used on each run. To narrow it for a single run without editing the file, use either flag (both repeatable):--mcp-server keeps only the connections you name; --mcp-exclude drops the
ones you name. Connection names must be unique in the file; if two entries share
a name, the first is kept and the rest are ignored.
Pointing at a different file
To read the config from another path instead of~/.strix/mcp-servers.json, either pass --mcp-config <path> on the command line:
STRIX_MCP_CONFIG environment variable to that path. The flag takes precedence when both are given.
Startup confirmation
When servers are configured, Strix prints a one-line summary at scan startup, for exampleMCP: connected 1 server (14 tools): local_fs, so you can confirm your servers connected.
Seeing the calls
Each call the agent makes to one of your servers is shown with its own icon and labelled with the connection it went out to, in the terminal and in the run viewer (strix view), so a call that left Strix for a server you connected is
easy to pick out of a transcript. The terminal shows the call and its arguments;
results can be large and arbitrary, so read them in the viewer, which shows a
preview you can expand.
Behavior
- The config file is optional. Without it, a run simply gets no MCP tools.
- A server that fails to connect is skipped and logged, and the run continues without it.
- A single malformed entry is skipped without blocking the valid ones.