git:20260504.824f64a to git:20260606.835b58a

+ 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:

+

+ ```sh

+ 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:

+

+ ```sh

+ 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.