mirror of
https://github.com/usestrix/strix.git
synced 2026-08-22 11:02:08 +02:00
132 lines
5.3 KiB
Plaintext
132 lines
5.3 KiB
Plaintext
---
|
|
title: "MCP Servers"
|
|
description: "Connect your own MCP servers and expose their tools to the agent"
|
|
---
|
|
|
|
Strix can connect to [Model Context Protocol (MCP)](https://modelcontextprotocol.io) servers you list and expose their tools to the agent during a run. Use this to let the agent read how your system is actually built instead of inferring it from the outside.
|
|
|
|
A few things it pays off for:
|
|
|
|
- **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:
|
|
|
|
```bash
|
|
mkdir -p ~/.strix
|
|
```
|
|
|
|
Paste the servers you want into `~/.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:
|
|
|
|
```json
|
|
[
|
|
{
|
|
"name": "local_fs",
|
|
"transport": "stdio",
|
|
"command": "npx",
|
|
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/project"]
|
|
},
|
|
{
|
|
"name": "github",
|
|
"transport": "http",
|
|
"url": "https://api.githubcopilot.com/mcp/",
|
|
"auth": { "kind": "bearer", "token": "your-token" },
|
|
"allowed_tools": ["list_issues"]
|
|
}
|
|
]
|
|
```
|
|
|
|
Strix reads this file at the start of each run. There is no default file, so no MCP tools are loaded until you create it. Edit `command`, `args`, `url`, and `token` to match your own servers.
|
|
|
|
## Fields
|
|
|
|
<ParamField path="name" type="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.
|
|
</ParamField>
|
|
|
|
<ParamField path="transport" type="string">
|
|
`stdio` for a local subprocess server, or `http` for a remote server.
|
|
</ParamField>
|
|
|
|
<ParamField path="command" type="string">
|
|
For `stdio` servers: the executable Strix launches (for example `npx`).
|
|
</ParamField>
|
|
|
|
<ParamField path="args" type="array">
|
|
For `stdio` servers: the arguments passed to `command`.
|
|
</ParamField>
|
|
|
|
<ParamField path="url" type="string">
|
|
For `http` servers: the server endpoint URL.
|
|
</ParamField>
|
|
|
|
<ParamField path="auth" type="object">
|
|
For `http` servers that need a bearer token:
|
|
`{ "kind": "bearer", "token": "your-token" }`.
|
|
</ParamField>
|
|
|
|
<ParamField path="allowed_tools" type="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.
|
|
</ParamField>
|
|
|
|
<ParamField path="notes" type="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.
|
|
</ParamField>
|
|
|
|
## 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):
|
|
|
|
```bash
|
|
strix --mcp-server github -t ... # use only the named connection(s)
|
|
strix --mcp-exclude staging-db -t ... # use everything except the named one(s)
|
|
```
|
|
|
|
`--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:
|
|
|
|
```bash
|
|
strix --mcp-config ./mcp-servers.json -t ...
|
|
```
|
|
|
|
or set the `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 example `MCP: 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.
|