I scanned 10 MCP servers – here's what agents can't know before connecting

A new tool called mcp-trustcard scans Model Context Protocol (MCP) servers before agents connect, grading them on installability, protocol compliance, tool schema validity, destructive capabilities, authentication, secret exposure, and latency. The project aims to improve security and quality verification in the rapidly growing MCP ecosystem, where clients currently connect blind to servers that may have exploitable weaknesses.

The "npm audit" for MCP servers. A trust card for every Model Context Protocol server — before you connect. Every day, agents connect to MCP servers they've never met. They don't know whether the server installs, whether it speaks the current protocol, whether its tool schemas are valid, whether it exposes destructive tools, or whether it leaks secrets — until something breaks or something leaks. mcp-trustcard gives every MCP server a public trust card in one command: npx mcp-trustcard @modelcontextprotocol/server-github MCP Trustcard: github-mcp-server @modelcontextprotocol/server-github ──────────────────────────────────────────────────────────────────────── Installability PASS @modelcontextprotocol/server-github@2025.4.8 Protocol handshake PASS github-mcp-server 0.6.2 · 717ms Tool schema validity PASS 26 tools, all schemas valid Destructive capabilities PASS no destructive verbs; 11 write/exec tool s Authentication PASS no auth required to list tools Secret exposure UNKNOWN no secrets seen in this run single probe Protocol version WARN negotiated 2024-11-05 latest is 2025-06-18 Latency & failure rate PASS 1ms avg, 0% failure ──────────────────────────────────────────────────────────────────────── Score 86/100 The MCP registry is growing fast. Security and quality verification are not. Recent research has found widespread exploitable weaknesses across MCP servers — tool poisoning, prompt injection via tool descriptions, shadowing, and secret leakage. Clients currently connect blind. This project is a public ranking surface . If maintainers argue with a score, that's traction. If they ask how to improve, that's a product. If teams want private scanning, that's a company. | Check | Pts | What it probes | |---|---|---| | Installability | 15 | Does the package resolve and install from npm? | | Protocol handshake | 25 | Does it respond to initialize over stdio JSON-RPC? | | Tool schema validity | 15 | Are tools/list schemas well-formed JSON Schema? | | Destructive capabilities | 10 | Does it expose delete/drop/kill/overwrite tools? | | Authentication | 10 | Is auth required, absent, or unknown? | | Secret exposure | 10 | Do tool descriptions or errors leak secret-shaped strings? | | Protocol version | 10 | Does it negotiate the latest protocol version? | | Latency & failure rate | 5 | Handshake latency + 3-ping failure rate | Each check returns PASS / WARN / FAIL / UNKNOWN and a partial-credit score. The total is the headline number. Scanned 2026-07-14. Servers are probed as a naive client — npx -y <pkg with no extra args or env. This is exactly what an agent does on first contact. Servers that require configuration fail the handshake, which is the point: clients can't discover that requirement before connecting. | | Server | Score | Handshake | Tools | Proto | Destructive | Notes | |---|---|---|---|---|---|---|---| | 1 | @playwright/mcp | 87/100 | PASS · 838ms | 24 | 2025-06-18 | WARN | 6/24 destructive browser actions | | 2 | chrome-devtools-mcp | 87/100 | PASS · 1021ms | 29 | 2025-06-18 | WARN | 5/29 destructive | | 3 | @modelcontextprotocol/server-filesystem | 87/100 | PASS · 768ms | 14 | 2025-06-18 | WARN | 3/14 destructive write/delete | | 4 | @modelcontextprotocol/server-github | 86/100 | PASS · 717ms | 26 | 2024-11-05 | PASS | Lags latest protocol version | | 5 | @modelcontextprotocol/server-memory | 85/100 | PASS · 789ms | 9 | 2025-06-18 | WARN | 3/9 destructive delete | | 6 | @upstash/context7-mcp | 85/100 | PASS · 997ms | 2 | 2025-06-18 | WARN | Heuristic flagged descriptions | | 7 | @eslint/mcp | 85/100 | PASS · 915ms | 1 | 2025-06-18 | WARN | 1 tool lint-files | | 8 | @modelcontextprotocol/server-brave-search | 33/100 | FAIL | 0 | — | UNKNOWN | Needs BRAVE API KEY env — undocumented to client | | 9 | @modelcontextprotocol/server-puppeteer | 28/100 | FAIL | 0 | — | UNKNOWN | Handshake timeout needs config/launch args | | 10 | @storybook/mcp | 28/100 | FAIL | 0 | — | UNKNOWN | Handshake timeout needs project context | 4 of 10 recognizable MCP servers cannot complete a protocol handshake when invoked the way an agent invokes them. There is no machine-readable way for a client to learn why before connecting. That gap is the wedge. npm install -g mcp-trustcard or just: npx mcp-trustcard <server-spec single server, text report npx mcp-trustcard @modelcontextprotocol/server-github single server, JSON npx mcp-trustcard --json @modelcontextprotocol/server-memory batch scan JSON array of specs mcp-trustcard --batch servers/official.json --json-out results.json Exit code is non-zero when the score is below 50, so it drops straight into CI. - uses: davidnichols-ops/trustcard@v0.1 with: server: @modelcontextprotocol/server-github min-score: "50" json-out: reports/github.json The action fails the job when the score drops below min-score . See .github/workflows/healthcheck.yml for a full matrix that scans all 10 servers on every push and on a daily cron for drift detection. npm view <spec — resolve the package installability .- Spawn npx -y <spec as a child process with stdio JSON-RPC. - Send initialize with the latest protocol version, measure latency. - Send notifications/initialized , then tools/list . - Validate each tool's inputSchema as JSON Schema. - Scan tool names + descriptions for destructive verbs and secret-shaped strings. - Probe 3 quick tools/list pings for failure rate. - Score and print the trust card. No dependencies. Pure Node stdlib. The whole probe runs in seconds. Single probe. Secret exposure is UNKNOWN unless a secret surfaces in one run. A real audit needs fuzzing and traffic replay. Naive invocation. Servers that need args/env fail the handshake. That's a feature, not a bug — it surfaces the discovery gap — but maintainers can fairly argue their server works fine with documented config. Good. Let's have that conversation in the scorecard metadata. Heuristic destructive detection. Flagging is keyword-based and will have false positives e.g. a description that mentions "delete" in passing . v2 will use call-site analysis. No auth flow testing. We detect that auth seems required; we don't exercise OAuth. stdio only. HTTP/SSE transports are next. This repo ships with a proposal for a standard mcp.health metadata field that servers can publish so clients can render a trust card before connecting. See . The tracker issue is filed against the spec registry. /davidnichols-ops/trustcard/blob/master/PROPOSAL.md PROPOSAL.md Scores are disputable — that's the point. To get your server scanned or to contest a score: - Open an issue with the server spec. - Optionally include a mcp.health snippet see PROPOSAL.md so we can verify declared vs. observed behavior. If you want to add a check, the scorecard is in lib/checks.js and is deliberately small. MIT