# Configure MCP Servers in Agent Assurance > For the full site index for AI agents, see [llms.txt](https://www.testmuai.com/support/docs/llms.txt). Rook uses MCP primarily as an evidence source. A judge can call an approved read-only tool to confirm that a ticket, refund, pull request, or other effect exists, rather than trusting the tested agent's claim. Exploration also records MCP servers declared by the target agent. These declarations are evidence about the target, and Rook never silently replaces or rewrites them. ## List Servers Launch `rook` in the workspace and enter these commands in its interactive TUI: ```text /mcp /mcp list ``` Headless: ```bash rook mcp list rook mcp list --json ``` Each row reports the server name, origin, transport, state, source, and connection or tool status when available. This actual first-use capture has no MCP servers: the triage sample is reached by HTTP, not MCP. It is an empty configuration, not a failed connection. After adding a server, repeat `/mcp list` and inspect it with `/mcp get ` before approving or using it. Declaring a server alone does not prove its tools work. ## MCP Origins and Precedence | Origin | Storage | Visibility | Approval required | |---|---|---|---| | `local` | Per-project section of `~/.testmuai/rook/settings.json` | Current project, private | No | | `project` | `/.testmuai/rook/mcp.json` | Current project, committable | Yes | | `user` | `~/.testmuai/rook/mcp.json` | Every project, private | No | | `discovered` | Target agent's recorded MCP materials | Active agent | Yes | Configured definition precedence is `local > project > user` by server name. The repository-root `.mcp.json` belongs to the agent under test. Rook reads it as evidence and never writes its own configuration there. Put project configuration in `.testmuai/rook/mcp.json`. ## Add a Stdio Server Local scope is the default: ```bash rook mcp add github -- npx -y @modelcontextprotocol/server-github ``` Add a project or user definition: ```bash rook mcp add github --scope project \ --env 'GITHUB_TOKEN=${GITHUB_TOKEN}' \ -- npx -y @modelcontextprotocol/server-github rook mcp add github --scope user \ --env 'GITHUB_TOKEN=${GITHUB_TOKEN}' \ -- npx -y @modelcontextprotocol/server-github ``` Everything after `--` is the stdio command and its arguments. You can repeat `--env`. Keep secret references in configuration. Rook expands `${VAR}` only when resolving a server to run, and displays the raw unexpanded definition. ## Record a Remote Server ```bash rook mcp add notion \ --transport http \ --url https://mcp.example.com/mcp \ --header 'Authorization: Bearer ${NOTION_TOKEN}' ``` **Remote transport status** Since 0.1.14, Rook connects to HTTP servers over Streamable HTTP, after the same approval as a stdio server. Each request has a 20-second deadline and an 8 MiB limit, and redirects are refused. SSE and WebSocket definitions are still accepted, stored, and listed for forward compatibility, but appear as `unsupported-transport`. ## Inspect a Definition ```bash rook mcp get github rook mcp get github --json ``` Rook leaves `${VAR}` references unexpanded in display output so tokens do not leak to the terminal, model context, browser, or transcript. For an HTTP server, `rook mcp get` and `rook mcp approve` also print `sends the value of VAR to ` for each variable the server receives, and values of 8 or more characters expanded from `${VAR}` are removed from everything the server sends back. ## Approve Repository-Controlled Servers A project or discovered stdio definition can execute a command from a cloned repository, and an HTTP definition can send credentials to its host, so either stays inert until a person approves its exact fingerprint. Changing an HTTP server's host asks for approval again. Interactive: ```text /mcp approve ``` Headless: ```bash rook mcp approve ``` When a project and discovered definition share the name, specify which one: ```bash rook mcp approve --origin project rook mcp approve --origin discovered ``` Rook prints the command before writing the approval. Review the: - Executable - Arguments - Environment references - Working assumptions - Package source Approval is pinned to the raw definition, not only the server name. If the command, arguments, or environment references change, the server returns to `pending-approval` and is marked as changed since approval. Rotating the value of the referenced secret does not require reapproval. ## Enable, Disable, or Remove ```text /mcp enable /mcp disable ``` Headless: ```bash rook mcp enable rook mcp disable rook mcp remove --scope local ``` Disabling applies to every origin with that name. Removing deletes the definition only from the selected scope. ## Name Collisions and Shadowing When a configured server and a discovered target server share a name: - The configured entry is used for invocation once it resolves as enabled. - The discovered entry remains visible as evidence and is marked shadowed. - The target's declaration is not overwritten. - A pending or rejected configured entry does not hide an otherwise usable discovered entry. Approval never guesses between two same-named definitions. ## MCP and Scenario Runnability A scenario can require a verifier: ```yaml verification_requires: - type: mcp server: github op: issues.get ``` If the server cannot be called, Rook names it in the skip reason. The next run recomputes MCP capability, so enabling a server can make the scenario runnable without regenerating it. Observing the tested agent's own MCP calls is a separate concern that you configure through the profile. The two gates are independent, and both may apply: - **Registry availability:** whether Rook can call a server. - **Profile observation:** whether Rook can see the target's calls. ## Permission Prompts Still Apply An enabled registry entry does not grant every use. Starting a server, listing its tools, and calling a tool each still pass through Rook's permission gate with specific subjects such as: ```text mcp_call(billing.get_refund_status) ``` Only approve a state-changing MCP call when the test explicitly requires that real effect. ## Troubleshoot MCP State | State | Meaning | Action | |---|---|---| | `enabled` | Definition is eligible to start | Inspect connection status or tools if calls still fail | | `disabled` | Disabled for this project | Run `rook mcp enable ` if intentional | | `pending-approval` | Repository-controlled definition is not trusted or changed | Review and approve the exact definition | | `rejected` | The definition was refused | Re-review and explicitly approve only if the decision changed | | `unsupported-transport` | Definition uses HTTP, SSE, or WebSocket | Use a stdio bridge or wait for transport support | | `malformed` | Required command data is absent or invalid | Fix the source configuration | Malformed scope files and duplicate discovered names are reported with their source rather than silently dropped. ## Review MCP Evidence in Either UI Use `rook ui --local` for workspace records or `rook ui` for uploaded results. In either redesigned interface, open **run → scenario**, inspect the acceptance criteria, then choose **Response**, **Verdict**, or **Artefacts** in **Evidence** to open the drawer. Both can show MCP-related evidence only when it was actually recorded; declaring a tool or verifier does not prove it was called. See the [earlier local layout](/support/docs/rook-web-ui/#earlier-local-ui) if your CLI still has scrolling sections. Neither UI starts, approves, or edits an MCP server. Resolve missing verification access with the CLI commands above, then inspect the resulting evidence. The [local and hosted walkthrough](/support/docs/rook-web-ui/#choose-your-ui) shows both review layouts. ### Local UI: Where to Inspect Verification Evidence {#local-ui-example} Open **agent → Runs → run → scenario** and read **Acceptance criteria**, then inspect **Evidence → Response** and **Verdict**. This saved CommerceCare demo locates the review controls; it does not demonstrate an MCP invocation or configuration. For an MCP-backed test, inspect that run's actual calls and verification gaps here. ### Hosted Web UI: Where to Inspect Uploaded Calls {#hosted-ui-example} Open **run → scenario → Evidence → Response** for the recorded exchange and observed calls, then check **Verdict** and **Artefacts** in the drawer. This separate hosted HTTP triage sample is not MCP-specific evidence. An MCP tool declaration or connection status alone cannot establish what the tested agent actually did.