cli

<p align="center">
  <picture>
    <source media="(prefers-color-scheme: dark)" srcset="./assets/banner-dark.svg">
    <source media="(prefers-color-scheme: light)" srcset="./assets/banner-light.svg">
    <img alt="mcpm — MCP security guard and package manager for Model Context Protocol servers" src="./assets/banner-light.svg" width="680">
  </picture>
</p>

# 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 local health check, 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.

[![npm version](https://img.shields.io/npm/v/@getmcpm/cli)](https://www.npmjs.com/package/@getmcpm/cli)
[![license](https://img.shields.io/github/license/getmcpm/cli)](./LICENSE)
[![tests](https://img.shields.io/github/actions/workflow/status/getmcpm/cli/ci.yml?label=tests)](https://github.com/getmcpm/cli/actions)
[![Known Vulnerabilities](https://snyk.io/advisor/npm-package/@getmcpm/cli/badge.svg)](https://snyk.io/advisor/npm-package/@getmcpm/cli)

---

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](https://www.ox.security/blog/mcp-supply-chain-advisory-rce-vulnerabilities-across-the-ai-ecosystem/). 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**](https://github.com/getmcpm/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](https://github.com/getmcpm/mcp-guardbench#corpus-v5---the-first-live-in-the-wild-campaign-case-deadbugz) (56 cases: 32 attack, 20 benign, 4 warn-and-forward) it includes seven cases rebuilt from real, publicly disclosed CVEs in third-party MCP servers, plus two cases reproducing Deadbugz, an active in-the-wild MCP supply-chain campaign (see below). The published top row: `@getmcpm/cli@0.38.0` scores 88.9% 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 both new Deadbugz cases (below).

**How this differs.** [Microsoft APM](https://github.com/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](https://github.com/microsoft/apm/blob/main/docs/src/content/docs/enterprise/governance-guide.md) for its install/audit gates, list Sigstore verification as [out of scope until v0.2](https://github.com/microsoft/apm/blob/main/docs/src/content/docs/specs/openapm-v0.1.md), and give its policy schema [no fields for runtime permissions or agent sandboxing](https://github.com/microsoft/apm/blob/main/docs/src/content/docs/enterprise/apm-policy.md). Smithery, [acquired by Arcade.dev](https://www.arcade.dev/blog/smithery-joins-arcade/) (2026-08-05), is a hosted-execution lane, not a local CLI. OSS runtime proxies like [McpVanguard](https://pypi.org/project/mcp-vanguard/) and [MCP Firewall](https://github.com/evalops/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.

<p align="center">
  <img src="./assets/demo.gif" alt="mcpm demo" width="680">
</p>

## Quick start

Install with the package manager you already use:

| Method | Command |
|---|---|
| **npm** (global) | `npm install -g @getmcpm/cli` |
| **npx** (no install) | `npx @getmcpm/cli <command>` |
| **pnpm** | `pnpm add -g @getmcpm/cli` |
| **mise** | `mise use -g npm:@getmcpm/cli` |

**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](https://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`](docs/DISTRIBUTION.md).

```bash
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.

### 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