/mcp-risk-review

name: mcp-risk-review
description: Use when an MCP server is about to be enabled, added to agent config, or upgraded -- a staged server config is a candidate for activation, a third-party server is proposed from a registry, or an existing entry changes transport, credentials, or tool surface.

Purpose

Triage the risk of an MCP server before it gains access to the session. An enabled server's tools execute with real filesystem, network, and credential reach; the review happens before enablement, not after the first incident.

When to Use

• A staged MCP server config is a candidate for enabling
• A third-party MCP server is proposed from outside the repo
• An existing server entry changes transport, credentials, or tool surface
• A long-enabled server is due a periodic re-review

For filesystem-server path boundaries in depth, continue with the filesystem-mcp-guardrails skill after this triage.

Inputs

• The server config entry: command, args, env, transport
• The server's declared tool list (from its manifest or a smoke run)
• What the session can reach if the server misbehaves

Workflow

1. **Launch vector.** Pinned, locally installed binaries beat remote latest-version execution:

   rg -n 'npx -y|@latest|curl .*\| *sh' <config-file>

Unpinned remote execution is a P1 by default — the server reviewed today is not necessarily the server that runs tomorrow.

2. **Transport and exposure.** A local stdio process is the conservative default. Network transports must answer: who can connect, is it loopback-only, is there authentication.

3. **Credentials and environment.** Hardcoded secrets in the config are P0. Environment pass-through should name specific variables — never forward the whole environment.

4. **Tool surface.** Enumerate the tools the server actually declares. Write, exec, and delete capabilities raise the bar; a read-only server with three tools is a different risk class from a shell-capable one with thirty.

5. **Scope boundaries.** Paths bounded to the workspace, method filtering configured, timeouts set.

6. **Repo-native checks, then approval.** For staged Agent Powerups configs, run the availability checks, then stop for explicit user approval before enabling:

   apx mcp check <name>
   apx mcp smoke <name>

These verify availability and declared dependencies only — they are not a substitute for the review above, and passing them does not authorize enablement.

Output

• A risk verdict: enable, constrain-then-enable, or reject
• Findings with level (P0 secret or unbounded exec, P1 unpinned or over-broad, Note) and a concrete remediation each
• Unanswered questions stated as open risks when information was unavailable

Verification

• [ ] Launch vector, transport, credentials, tool surface, and boundaries were each explicitly assessed
• [ ] The tool list came from the server's actual declaration, not an assumption
• [ ] Availability checks were run for staged configs
• [ ] No server was enabled without explicit user approval after the verdict

Failure Modes

• **Smoke-test-as-review** — a passing smoke run proves the server starts, not that it is safe.
• **Trusting the README tool list** — enumerate from the server's declared tools; docs drift.
• **Wildcard env pass-through** — handing the whole environment to a subprocess leaks every credential the session holds.
• **Enable-then-review** — once tools are live, the first malicious call has already happened.