mcpm

mcpm — MCP security guard and package manager

Block prompt injection, tool poisoning, rug-pulls and credential theft in Model Context Protocol (MCP) servers -- at runtime, on your machine. Your AI agent trusts every MCP server it talks to; mcpm scores each install, verifies its supply chain with Sigstore, pins every tool definition, and inspects every tool call through a local relay -- with an opt-in OS sandbox on macOS. No cloud, no account, no LLM in the enforcement path.

Everything runs on your machine. No account, no mcpm backend, no telemetry -- the guard is a local stdio relay, and trust scores are computed locally with no model and no remote verdict (the 40-point static-scan bucket is deterministic regex/structural checks you can read yourself; the rest is a reserved health-check bucket (not run by current commands), registry metadata, and an external scanner only if you name one). Commands that resolve, audit or re-verify a server do reach the public MCP registry and npm -- nothing reaches an mcpm server.

---

The risky part of an MCP server doesn't show up at install -- it shows up while your agent is running: prompt injection hidden in a tool's output, a server that quietly rewrites its tools after you approved them, a sampling request that smuggles instructions into your model. Being listed in a registry is not a safety signal -- in 2026 a proof-of-concept poisoned server was accepted by 9 of 11 public registries and marketplaces. So mcpm scores every install for hardcoded secrets, prompt injection, and typosquatting -- then runs a live guard between your AI client and each server, pinning tool definitions against rug-pulls and blocking injection before it reaches the model.

You don't have to take our word for any of that. Guards are easy to claim and hard to check, so the measuring stick is public: mcp-guardbench is a guard-agnostic benchmark -- versioned attack and benign cases, an open schema, and a runner that scores *any* MCP guard through its own published CLI. mcpm is scored the same way as everyone else, by shelling out to mcpm guard inspect, never by importing its own engine.

The corpus isn't mcpm's own test fixtures anymore. As of corpus v5 (57 cases: 33 attack, 20 benign, 4 warn-and-forward) it includes seven cases rebuilt from real, publicly disclosed CVEs in third-party MCP servers, plus three cases reproducing Deadbugz, an active in-the-wild MCP supply-chain campaign -- the third contributed externally by @vguillaume8 (see below). The published top row: @getmcpm/cli@0.43.0 scores 86.5% recall / 0.0% false-positive rate / 100% precision; every mcpm row is measured through that exact version's published CLI. That is a baseline, not a boast -- mcpm's misses are published on the same page as its wins, including all three Deadbugz-derived cases (below).

How this differs. Microsoft APM is the closest analog -- an npm-style installer and lockfile for MCP servers (and skills/prompts/plugins) across 9+ clients -- but its own docs say it produces no signed attestation for its install/audit gates, list Sigstore verification as out of scope until v0.2, and give its policy schema no fields for runtime permissions or agent sandboxing. Smithery, acquired by Arcade.dev (2026-08-05), is a hosted-execution lane, not a local CLI. OSS runtime proxies like McpVanguard and MCP Firewall inspect and enforce policy at runtime, and MCP Firewall also offers containment -- but neither adds install-time trust scoring or Sigstore-verified supply-chain checks. (mcp-guardbench carries a McpVanguard row, but its own README says that row is not comparable to the mcpm rows and should not be quoted as a head-to-head: it drives one offline harness layer rather than McpVanguard's real proxy deployment, and abstains on roughly half the corpus.) What mcpm combines is a trust score, offline Sigstore provenance verification, and a runtime relay with pin/drift plus OS confinement in a single local, account-free tool.

Quick start

Install with the package manager you already use:

Requires Node `^22.22.2 || ^24.15.0 || >=26.0.0` — that is 22.22.2+, 24.15.0+ or 26+, the intersection of what every runtime dependency itself supports. Everything else is excluded, 23.x and 25.x included. npm warns EBADENGINE and fails outright under --engine-strict; pnpm installs silently and exits 0 unless you set engine-strict=true, so there an unsupported Node surfaces as a runtime error rather than an install one.

The binary is mcpm. Heads up: the mcpm Homebrew formula is a *different, unrelated* project (mcpm.sh) — install this mcpm via npm/npx/pnpm/mise above (all resolve the scoped @getmcpm/cli package, so there's no name collision). A dedicated Homebrew tap is deferred; see docs/DISTRIBUTION.md.

mcpm search filesystem

mcpm info io.github.domdomegg/filesystem-mcp mcpm install io.github.domdomegg/filesystem-mcp

Features

Search the MCP registry

Query the official MCP Registry and see results with trust indicators.

$ mcpm search filesystem

Name Description Version Transport Status io.github.domdomegg/filesystem-mcp File system access via MCP 1.4.0 stdio active io.github.Digital-Defiance/mcp-filesystem Read-only filesystem server 0.9.2 stdio active ...

Search shows registry lifecycle status, not a trust score -- it is a fast discovery list and does not run the scanner per result. Computed trust lives in mcpm why, info, install, and audit.

Install with trust assessment

Every install runs a metadata-based trust assessment before writing config.

$ mcpm install io.github.domdomegg/filesystem-mcp

███████████████░░░░░ 57/80 CAUTION ├─ Health check: not yet run ├─ Tool descriptions: score 32/40 ├─ Package: publisher verification passed └─ External scan: not available (set MCPM_EXTERNAL_SCANNER for deeper analysis)

Install to Claude Desktop? (Y/n)

Audit installed servers

Scan everything you have installed. Get a trust report.

$ mcpm audit

┌─────────────────────────────────────────────┬─────────────────────────┬─────────────────┬──────────┐ │ Server │ Score │ Level │ Findings │ ├─────────────────────────────────────────────┼─────────────────────────┼─────────────────┼──────────┤ │ servers-filesystem │ ████████░░ 62/80 │ clean · not run │ 0 │ ├─────────────────────────────────────────────┼─────────────────────────┼─────────────────┼──────────┤ │ servers-github │ ████████░░ 60/80 │ caution │ 1 │ ├─────────────────────────────────────────────┼─────────────────────────┼─────────────────┼──────────┤ │ servers-fetch │ ███████░░░ 52/80 │ caution │ 2 │ ├─────────────────────────────────────────────┼─────────────────────────┼─────────────────┼──────────┤ │ some-sketchy-server │ ██░░░░░░░░ 16/80 │ risky │ 5 │ └─────────────────────────────────────────────┴─────────────────────────┴─────────────────┴──────────┘ 4 servers scanned, 0 safe, 1 clean · not run, 2 caution, 1 risky

audit never executes a server, so the 30-point health-check bucket scores a flat 15 and 62/80 is the ceiling — no server can be rated safe here. A server that cleared every check that actually ran reads clean · not run instead. servers-github scores 60 because an npx -y launcher draws one low install-script finding, which is also why it reads caution rather than clean · not run: that label requires the scan to have found *nothing*, not merely a top-band score.

audit also does not apply the release-age cooldown finding that why, install, up and lock do (src/scanner/cooldown.ts is an install-gate signal — it exists to arm install --min-release-age / policy.minReleaseAgeHours, and re-penalising an *already-installed* server for being young is not a decision audit is making). For a release under 24 h old that is a medium, so mcpm audit can read 5 points higher than mcpm why for the same server at the same moment. Neither number is wrong; they answer different questions.

Cross-IDE support

One tool for all your AI clients. mcpm reads and writes the correct config format for each.

$ mcpm list

Client Server Name Status Command/URL Claude Desktop servers-filesystem active npx -y servers-filesystem Claude Desktop servers-github active npx -y servers-github Cursor servers-fetch disabled npx -y servers-fetch

Doctor: check your MCP setup health

Find misconfigurations, missing runtimes, broken servers, and plaintext secrets pasted into client config.

$ mcpm doctor

mcpm doctor

✓ Claude Desktop — config found, 3 servers ✗ Claude Code — config not found ✓ Cursor — config found, 1 server ✗ VS Code — config not found ✗ Windsurf — config not found ✗ Gemini CLI — config not found

Runtimes: ✓ npx available ✓ uvx available ✓ docker available

Cross-client (advisory): ⚠ servers-filesystem — in claude-desktop; missing in cursor ⚠ servers-github — in claude-desktop; missing in cursor Run mcpm sync --check for the full matrix (advisory, not a failure).

Plaintext secrets (advisory): ⚠ claude-desktop · servers-github · env 'GITHUB_TOKEN' — GitHub token Move env secrets to the encrypted store: mcpm secrets set or re-install with --secrets keychain.

No critical issues found.

The plaintext-secret scan reports the key name and label only — never the value — and skips values already stored as mcpm:keychain: placeholders. It's advisory (never fails doctor).

Client lifecycle compatibility

Cursor and Gemini enable/disable retain the definition in an mcpm-owned parking