Live protocol validation
Handshake, conformance, catalogue, safe execution, latency and recovery, run against the real server over the real transport, on both the handshake revisions and the stateless 2026-07-28 revision.
Open source · runs on your machine or in CI · no telemetry
Prove an MCP server is safe for your agents, with evidence anyone can check.
passmcp connects to a live MCP server the way an agent would, has 139 checks across nine phases, and ties every finding to the request that showed it. It writes an in-toto attestation that you sign with the tooling you already trust, and that a gateway, a registry or an auditor can verify offline. Nothing is uploaded and nothing is guessed.
passmcp's sample report
acme-crm 2.4.0, passmcp's deliberately flawed fixture server
5 failing checks to fix before agents rely on it
72 checks · 38 pass · 6 warn · 5 fail · 11 skipped · 12 info
69.25/ 100Grade C
- Checks in passmcp
- 139
- Protocol generations
- Both
- Bytes sent to us
- None
This is passmcp's real output, not a mock-up: the sample report is passmcp run against a fixture server with deliberate flaws, and the score, ledger, phases and evidence on this page are read from it. Generated by passmcp 0.0.9 when this page was built.
What only passmcp does
Validation you can prove, not a posture you have to trust.
Discovery and dashboards tell you what exists. passmcp tells you what a server actually does when an agent talks to it, and gives you a signed record of it.
Evidence tied to requests
Every finding cites the numbered request that produced it, and the report directory keeps the NDJSON event stream and a HAR file. A verdict you dispute is a verdict you can replay.
Offline-verifiable attestations, signed your way
passmcp writes an in-toto statement about the server. The verifier is Apache-2.0 and has no dependencies, so a gateway, registry or auditor can check it without trusting anyone's server. Sign it with cosign; passmcp deliberately neither signs nor checks signatures (ADR 0010).
A gate, not a report
Exit status 2 on a failed check, a policy file for what counts, SARIF for code scanning and JUnit for test reports. The check that gates a release is the one an engineer already ran.
Why it runs here
A tester you upload to is a tester you trust twice.
Handing an endpoint to a hosted tester means handing over whatever reaches it. For a server behind OAuth, that is a working credential. passmcp is the same test, run from inside your own trust boundary.
Your credentials stay put
passmcp authenticates from your machine with the token you already hold. Secrets are registered with the recorder before the first request and masked everywhere they appear, including tokens the server issues mid-run.
Your network is the network
A server on a private address, behind a VPN, inside a CI runner, or run as a local program over stdio, is reached exactly as your agents reach it.
Read-only by default
Only tools that declare readOnlyHint are called. A tool with no annotation is destructive by the specification's default, so it is skipped and the report says so. Mutations are an explicit opt-in.
How it compares
Use the right tool for the question.
The Inspector is for exploring by hand; static scanners read metadata and code; hosted agent-security platforms inventory what exists across your SaaS. passmcp answers a different question: does this server behave safely, and can you prove it?
| passmcp | MCP Inspector | Cisco mcp-scanner | Snyk agent-scan | Hosted agent-security platforms | |
|---|---|---|---|---|---|
| Tests a live server's protocol behaviour, automatically | 139 checks, 9 phases | By hand | Scans metadata and code | Reads the tool catalogue | Not documented |
| Evidence you can sign and verify offline | in-toto attestation | No | No | No | Not documented |
| Every finding cites the request that showed it | Yes, with a HAR file | By hand | No | No | Not documented |
| Gates CI with an exit code, SARIF and JUnit | Yes | CLI mode, no SARIF or JUnit | Not documented | Exit code and JSON | Not documented |
| Runs where your credentials already are | Your machine or CI | Your machine | Offline or CI | Local, with a cloud API | Vendor-hosted |
| Finds agents and MCP servers across an organisation | From the sources you name: released in 0.0.1 | No | From client configurations on one machine | From client configurations | Yes |
| Maps identities, grants and reach as a graph | passmcp-graph: released in 0.0.1 | No | No | No | Yes |
| Open source | GPL-3.0-only; format Apache-2.0 | Yes | Yes | Yes | No |
Sources, as each project describes itself on 17 Oct 2026: Cisco mcp-scanner (github.com/cisco-ai-defense/mcp-scanner), Snyk agent-scan (github.com/snyk/agent-scan), MCP Inspector (github.com/modelcontextprotocol/inspector), and the public product pages of hosted agent-security platforms such as reco.ai. 'Not documented' means we found no public description of the capability, not proof that it is absent. Corrections are welcome as issues.
Scoring
Every deduction named.
A grade with no arithmetic behind it is a brand, not a measurement. These are the six categories passmcp scores, their weights, and what the sample server lost in each.
| Category | Weight | Score | Deduction |
|---|---|---|---|
| Connectivity | 10 | 100 | 0 |
| Authorization | 20 | 95 | −1 |
| Protocol | 20 | 0 | −20 |
| Catalogue | 15 | 55 | −6.75 |
| Execution | 20 | 85 | −3 |
| Performance | 15 | 100 | 0 |
Evidence
Nothing passes without a request that showed it.
Two findings from the sample report, each with the request that produced it. In the report, every finding links to its request in the HAR file and to its guidance in the manual.
req#11 · protocol.invalid_params
tools/call without a name is rejected
a tools/call with no name succeededreq#12 · protocol.unknown_tool
Unknown tool is reported
calling a non-existent tool returned successMethod
Nine phases, in the order an agent meets them.
The order matters: a catalogue check means nothing if the handshake never completed, and a latency figure means nothing if half the calls failed. When a phase blocks, every later one is recorded as skipped, with the reason.
- Connectivity
- Authorization
- Credentials
- Handshake
- Protocol
- Catalog
- Execution
- Performance
- Resilience
Where it plugs in
One verdict, used everywhere a decision is made.
passmcp never sits in your agents' traffic. It produces evidence, and the tools that do sit there can act on it.
GitHub Actions and GitLab CI
passmcp-action runs passmcp from its release image, pinned by digest, and writes the report, SARIF and an attestation. A GitLab template does the same.
Your agents, through MCP
passmcp-server exposes passmcp as three read-only tools, so an agent can evaluate a server or verify an attestation. It is listed in the MCP Registry.
agentgateway
An ExtMcp processor in passmcp-reporting lets agentgateway refuse MCP backends whose attestation is missing, invalid, about a different endpoint, below a score floor or failing in a named category, verified offline, with no call to passmcp.
Code scanning and test reports
SARIF for GitHub code scanning, JUnit XML for any CI, JSON and NDJSON for pipelines, HAR for devtools, OTLP traces for your collector.
Your package manager
Homebrew, mise, .deb and .rpm, a signed container image, or go install.
Your own code
passmcp's client, OAuth, transport and diagnostics packages are public Go packages. The attestation verifier is Apache-2.0 with no dependencies, so any consumer can embed it.
Across every agent
See which agents reach which servers, and what that exposes.
passmcp tests one server at a time. passmcp-graph reads the attestations and JSON reports passmcp writes, with your Claude Desktop, Cursor, VS Code and Zed configurations, and maps which agents reach which servers, tools and identities. It names risks a client inherits from a failing server and identities that hold more than their tools need, answers path queries, and gates CI on a policy, all offline.
Trust
Auditable the way it asks servers to be.
passmcp is software you run, not a service you send data to, so the questions that matter are about the software itself. Here is how to check each answer yourself.
Signed and attested releases
Signed tags; checksums signed with keyless cosign; SLSA build provenance; a CycloneDX SBOM per archive and per package; the container image signed with keyless cosign and its base pinned by digest.
No telemetry, ever
No account, no analytics, no phone-home. passmcp contacts the server you named and the authorization endpoints it advertises, and nothing else unless you opt in by flag, as with --osv for advisories or --model for explain. That is a recorded decision, ADR 0006.
Never in the data path
passmcp does not proxy, terminate or forward an agent's request, and no agent request waits on anything passmcp operates. ADR 0007 draws that line, and the gateway integrations respect it.
Compliance, stated honestly
passmcp holds no SOC 2 or ISO 27001 certificate; those apply to service providers, and passmcp runs on yours. Every check is mapped to the SOC 2 Trust Services Criteria, ISO/IEC 27001:2022 Annex A controls and GDPR articles it evidences, or marked as evidencing none with the reason, released in 0.0.1, so its evidence drops into your audit. Mappings, not certifications: an auditor certifies.
Why now
The dates your agent programme is working to.
Agents are moving into production while the guidance and the obligations around them arrive. Each date below links to its source.
| Date | What | What passmcp gives you |
|---|---|---|
| 20 May 2026 | NSA: MCP security design considerations | Authentication, Origin and token handling checked on the live server |
| 28 Jul 2026 | MCP 2026-07-28: the stateless revision | All nine phases on both protocol generations |
| 11 Sep 2026 | EU Cyber Resilience Act: vulnerability reporting applies | Signed releases, SBOMs and provenance for passmcp itself |
| After Jul 2027 | MCP's deprecated features become removable | protocol.deprecated_features tells you what to migrate first |
| 2 Dec 2027 | EU AI Act: Annex III high-risk obligations | Dated evidence, signable with cosign, of what the tools your agents use actually do |
The passmcp family
Nine components, one version.
The family moves in lockstep: one version across every component, released together. Each status links to its release, or to the changelog that tracks what is not released yet.
| Component | Purpose | Status |
|---|---|---|
| passmcp | The engine, every check, and the three peer surfaces: CLI, TUI and the embedded local web UI. | Released in 0.0.9 |
| passmcp-reporting | The attestation predicate, its JSON Schema and the offline verifier, as a module with no dependencies; the report schema, the renderers and the rubric as data follow when a consumer needs them. | Released in 0.0.9 |
| passmcp-server | An MCP server exposing passmcp's diagnostics as read-only tools, so an agent can evaluate a server, or check an attestation about one, from inside the editor. | Released in 0.0.9 |
| passmcp-action | The GitHub Action wrapping the published image by digest, and a GitLab CI template. | Released in 0.0.9 |
| passmcp-graph | A local graph of which agents use which MCP servers, which tools those servers expose and which identities reach them, built from passmcp's attestations, reports and MCP client configurations, queried offline and gated by policy in CI. | Released in 0.0.9 |
| passmcp-registry | The tooling for a signed public scorecard of the remote servers in the MCP Registry: each checked read-only and without credentials by a pinned passmcp release, every result an offline-verifiable attestation, and anything that would expose a vulnerability withheld for its owner first. No run has been published yet. | Released in 0.0.9 |
| passmcp-lsp | A language server over MCP artefacts — server.json, tool schemas, client configuration, passmcp policy and attestation files — with check-id hover from the guidance catalogue. | Released in 0.0.9 |
| passmcp-census | The reliability census of the MCP Registry's remote servers: the methodology, the disclosure log and the command that reproduces the figures. No edition has been published yet. | Released in 0.0.9 |
| satellion.com | The public site at satellion.com, built with SSG against passmcp's latest release: the home page, the manual and a sample report passmcp generates. | Released in 0.0.9 |
Questions
The things people ask before installing.
Short answers. Longer ones are in the manual.
How is this different from the official MCP Inspector?
The Inspector is an excellent place to explore a server by hand: click a tool, read a response, debug an OAuth flow. passmcp is the non-interactive counterpart. It runs up to 139 checks, scores the result, cites its evidence, writes an attestation and returns an exit code. Most teams use both.
How is it different from static MCP scanners?
Scanners such as Cisco's mcp-scanner read tool metadata and source code. passmcp talks to the running server over its real transport, so it sees what the server does: whether it rejects a bad token, validates arguments, honours Origin, recovers a session. passmcp also reads the catalogue for hidden instructions and poisoning, so the two overlap on text but not on behaviour.
Does it support the stateless 2026-07-28 revision?
Yes. All nine phases run on either generation. passmcp settles which revision a server speaks before first contact, because the shape of the first request depends on the answer.
Is it safe to run against production?
It is designed for it. Only tools that declare readOnlyHint are called, and requests are throttled. Conformance probes are sent (an invalid token, an unknown method, malformed JSON, a session id the server never issued) to see how the server handles them, and nothing else adversarial. It is a diagnostic, not a penetration test.
Does it test stdio servers?
Yes. passmcp check --stdio --
What does it cost, and what does it send back to you?
It is free and open source: the engine is GPL-3.0-only and the attestation format and verifier are Apache-2.0. It sends nothing back, and there is no telemetry, account or analytics.
Can I verify an attestation without trusting you?
Yes. passmcp verify checks a statement offline, and the verifier is a dependency-free Apache-2.0 Go package you can read, vendor or reimplement. Sign statements with the tooling you already trust, such as cosign, and verify the signature before you act on the verdict.
Get started
One command, and no account to make.
Install it, point it at a server, read the verdict. Everything below runs on your machine; passmcp makes requests only to the server you name and the authorization servers it advertises.
Install
Then point it at a server:
That is the whole first run. No account, no config file, no signup. Add a credential when the server needs one:
Or open the same diagnostic in a browser, still running locally:
Verify
Every run can write an attestation. Check the one behind the sample report yourself; passmcp verify works offline and trusts nothing but the bytes:
A gateway or registry does the same with the Apache-2.0 verifier in passmcp-reporting, without running passmcp at all.
In a pipeline
passmcp exits non-zero when a server fails, so it gates a merge without any extra plumbing:
The report directory holds the JSON verdict, SARIF, JUnit, the attestation, the NDJSON event stream and a HAR archive of every exchange. Attach it to the build and the question "how do you know?" has an answer that outlives the person who ran it.
What it checks
Connectivity and TLS. How the server asks to be authorized, and whether it refuses a bad token. The MCP handshake, and which generation of the protocol it speaks; passmcp supports both the handshake revisions and the stateless 2026-07-28 one. Protocol behaviour on the edge cases an agent will hit. The tool catalogue, as a model reads it: descriptions, schemas, annotations, and whether $ref and $defs resolve. Safe calls, with results checked against the contracts the tools declare. Latency under repeat and parallel calls. Recovery from a lost session, or from a server that turns out not to be as stateless as it claims.
What it will not do
It calls only tools that declare readOnlyHint unless you say otherwise. It throttles itself. It sends protocol conformance probes (an invalid token, an unknown method, malformed JSON, a session id it never received, a foreign Origin) to see how the server handles them, and nothing adversarial beyond that (ADR 0008). It is a diagnostic, not a penetration test, and the difference is deliberate.
It also will not phone home. There is no telemetry, no account and no analytics: passmcp contacts only the server you named and the authorization servers it advertises, plus anything you opt into by flag.