Shadow MCP Server

shadow-mcp

Discover and risk-grade the MCP servers actually present on this machine.

Most MCP security tooling assumes you already have a list of servers to audit. On a real developer machine you don't: servers are scattered across Claude Code, Codex, Claude Desktop, project-local .mcp.json files, DXT extensions, and live processes that bind no port. shadow-mcp finds them first, then grades them.

This is the local-first answer to OWASP MCP09:2025 — Shadow MCP Servers.

What it does

discover  ->  inventory  ->  risk-grade  ->  report

1. Discover (read-only) MCP servers from supported configuration and runtime sources: Claude Code (~/.claude.json, user + project scope), claude mcp list (catches remote + plugin servers no file contains), Codex (~/.codex/config.toml + profiles), project .mcp.json, Claude Desktop config + DXT extension manifests, and the live process table.
2. Inventory: merge sightings into one entry per logical server, even when a server appears under different names across hosts (personal-ops vs personal_ops), tracking every provenance.
3. Risk-grade by delegating to the existing engines rather than reimplementing them:
   • MCPAudit for a 0-10 capability composite + injection findings
   • mcp-trust for an authoritative A-F danger grade (when known)
   • a thin local layer for the config-shaped OWASP dimensions the engines under-cover (secrets/MCP01, supply-chain provenance/MCP04, transport exposure/MCP07).
4. Report: a ranked terminal table, a machine-readable JSON inventory, or markdown — plus a Shadow & attention section for the deltas that matter (running-but-unconfigured, broad blast radius, capable-but-ungraded).

The risk model and its OWASP mapping live in docs/risk-model.md.

Install

From this repository root, use uv:

make setup

The grading engines (mcp-audits and mcp-trust) are runtime dependencies resolved from PyPI, not editable sibling checkouts or an engines group. The installed mcp-trust package supplies its seed catalog; --registry-db or SHADOW_MCP_MCPTRUST_DB selects an explicitly chosen local registry instead.

Use

uv run shadow-mcp scan                      # full pipeline, terminal report
uv run shadow-mcp scan --json out.json      # machine-readable inventory
uv run shadow-mcp scan --format markdown    # markdown report
uv run shadow-mcp discover                  # inventory only, no grading
uv run shadow-mcp sources                   # per-collector counts
uv run shadow-mcp grade-missing             # A-F for servers the registry hasn't scanned
uv run shadow-mcp deep-scan cost-tracker    # connect to a server, grade its real tools

Useful flags: --no-processes (skip the live process scan), --no-cli (skip claude mcp list), --no-mcpaudit (inventory + mcp-trust only), --home PATH (point discovery at a fixture tree).

Static vs connected grading

By default grading is static (config-only): no server is spawned, so grades reflect what's visible in the config. That's safe but coarse — a server's real capability only shows once you connect and list its tools.

shadow-mcp scan --connect (or deep-scan [names...]) spawns each stdio server and enumerates its real tools, delegating to MCPAudit's connected engine for a capability grade that actually differentiates (a filesystem server jumps from a static A to a connected D). This is opt-in because connecting executes the server; remote endpoints are never spawned (that's the network-scan tier), and a server that needs real secrets to start falls back to its static grade.

Development and safe verification

The committed uv.lock fixes the PyPI runtime and development graph. From the repository root, run:

make check

The suite uses synthetic homes. Keep SHADOW_MCP_RUN_CONNECT unset: the explicitly opted-in connected test is a separate server-execution lane. CI runs the same aggregate gate on Python 3.11 through 3.15; see the workflow. make build creates the wheel and sdist used by the release workflow.

Do not use the normal scan, discover, sources, grade-missing or MCP tool calls as a development smoke: they inventory the machine by default. CLI deep-scan and scan --connect additionally execute servers. For changed JSON or Markdown reports, check the corresponding fixture tests (tests/test_report.py) and inspect synthetic output; this CLI has no browser UI. Actual workstation or connected behavior requires its own explicitly authorized qualification.

Safety

• Read-only discovery. Collectors parse configs, invoke claude mcp list (unless --no-cli is set), and list processes; nothing they find is ever mutated. (--connect/deep-scan is the one path that executes servers, and only when you explicitly ask.)
• Secrets stay out. We record env variable names (to flag secret-bearing servers per MCP01) but never their values. Inline credentials in command arguments, URLs, and process parent commands are redacted before storage. A captured inventory still contains local paths and hostnames, so treat *.inventory.json as private (it is git-ignored by default).

Use as an MCP server

shadow-mcp can serve its own inventory tools as an MCP server so an agent can query your local MCP surface without leaving the conversation.

Tools

Run the server

# directly from a local checkout
uv run shadow-mcp mcp-serve

# via uvx (once published to PyPI)
uvx shadow-mcp mcp-serve

LOCAL only. MCP tools read local configs and the process table, skip claude mcp list, and never connect to hosted MCP endpoints or spawn servers. Grading is static (config-based); connect=False is enforced unconditionally.

Scope

This is the local-first tool: it inventories one machine from its configs and processes. A later network-scan expansion (probing hosts/ports for remote MCP endpoints, org-wide fleet inventory, typosquat-distance provenance checks) is deliberately out of scope here — see the bottom of docs/risk-model.md and the project notes for what that would add.

Status

Stack

Python 3.11+; uv-managed locked dependencies; Ruff, mypy, and pytest checks; Hatchling wheel and sdist builds.

Known risks

• The minimum Python version remains 3.11 pending an owner decision about raising it to 3.12.
• The MCP tool name deep_scan remains unchanged pending an owner decision; the similarly named CLI command can connect to servers.
• Identity collisions in identity and inventory matching.
• Process sightings are deduplicated by name before owner classification.
• Grading evidence is limited to eight findings, and critical ranks below low.
• Collector failures can be silent.
• --json is ignored by sources and grade-missing.
• Report writes are not atomic.
• Markdown and Rich output escaping differs.
• Dependency major upgrades, moving off Hatchling, a coverage threshold, package publishing, tags, and releases remain out of scope.

Next steps

Resolve the Python floor and MCP tool naming decisions, then address the listed behavior risks in a follow-up wave.