Review an MCP Server's Tools Before an Agent Touches Your Runs

You connect an MCP server for your experiment tracker so the agent can read past runs. The same server may also expose tools that tag, overwrite or delete runs. The agent now has every tool on that list, whatever your prompt says about read-only.

The Claude Code MCP documentation starts from trust: "Verify you trust each server before connecting it." It adds that servers fetching external content can expose you to prompt injection. One more detail matters for eval harnesses and nightly jobs. In non-interactive mode (claude -p, the Agent SDK, cloud sessions), Claude Code loads project-scoped servers from .mcp.json without asking. An unattended run gets the whole list.

The check.

1. Run claude mcp list, then claude mcp get <name> for each server. Inside a session, /mcp shows each connected server's tool count.
2. Write down every tool and sort it into read or write. Anything that changes shared state, including tags and notes on a run, counts as a write.
3. Deny the writes you do not need. In permission rules, MCP tools are named mcp__<server>__<tool>, so a deny rule for mcp__tracker__delete_run covers exactly one tool.
4. Ask a synthetic question whose answer you already know. Confirm which tool was called. Then ask it to delete a test run, and confirm the rule refused it, not the model's good judgment.

The credentials behind the server set the ceiling on what any tool can do. A token scoped to read one project is a stronger boundary than any deny rule sitting on top of an admin token. Record which token each server uses next to the tool list, and you have an access review you can hand to a colleague.

External tools with MCP makes the same argument from the protocol side: the protocol connects, and the application decides.

Claude Code documentation.