Auditing an MCP server

Why you should audit an MCP server before installing it

An MCP server is not a passive data source — it is an active participant in your agent's reasoning. The Model Context Protocol is an open JSON-RPC 2.0 protocol introduced by Anthropic: when a host connects, it runs one MCP client per server, performs a capability handshake, then discovers the server's tools, resources and prompts and reads their names, descriptions and JSON schemas straight into the model's context. It later reads tool outputs back as data. Both of those channels carry text the model can interpret as instructions, so an untrusted server is an attack surface, not just a dependency.

That makes 'install first, trust later' the wrong default. A server you have never reviewed can ship hidden instructions in a tool description (tool poisoning), leak a hardcoded secret embedded in a schema, expose a destructive tool with no confirmation, or concentrate the lethal trifecta — untrusted-content ingestion, sensitive-data access and an outbound path — on a single server. None of that is visible in a one-line marketing description.

Auditing is the step that closes the gap between 'this server looks useful' and 'this server is safe to give my agent.' The goal of this page is defensive: explain what to check and how to verify a server, not how to attack one.

What to check when you audit an MCP server

Start with the protocol surface. Confirm the server completes a clean MCP handshake over its declared transport — stdio for local servers, Streamable HTTP (or legacy HTTP+SSE) for remote ones — that it negotiates a sane protocol version, and that it returns well-formed JSON-RPC 2.0 errors. A server that cannot even handshake correctly is a reliability and trust red flag before you reach any security check.

Then read the capabilities the server exposes: every tool, resource and prompt. For each tool, inspect the full definition — name, description, every parameter (including defaults and examples) and the input/output schema — because the agent ingests all of it. You are looking for instruction-like text where only documentation should be, credential-shaped strings sitting in schemas or examples, and destructive verbs (delete, drop, send, transfer) that lack any confirmation gate.

Finally, reason about capability combinations, not just individual tools. The danger is combinatorial: a single server that can fetch untrusted content, reach sensitive data, and exfiltrate or destroy holds all three legs of the lethal trifecta, and the same trifecta can form across several servers loaded into one agent. Inventory which server contributes which capability before you deploy.

How to scan an MCP server for vulnerabilities: static vs runtime

Auditing has two complementary layers. Static analysis reads the published tool list, schemas and protocol behavior without any side effects. It is fast and safe, and it catches the risks that ship in the declaration: poisoning planted in a description, a secret hardcoded in a schema, a destructive tool missing its confirmation, and risky capability mixes. Most of the OWASP MCP Top 10 can be checked this way, and it is the right place to start because it requires no execution.

Runtime (behavioral) analysis is needed for the attacks a static scan cannot see — namely instructions or exfiltration vectors delivered in a tool's response rather than its schema. The safe way to do this is to invoke only read-only tools with benign canary inputs and inspect what comes back, never calling mutating tools such as create, delete, send or execute. A clean-looking server can still relay attacker-authored text from a web page or email it fetched, which is exactly why exercising real responses matters.

A single audit certifies a server only as it was at probe time. Because a trusted server can silently change its tools afterwards (an MCP rug pull), a complete program treats the one-time audit as a baseline and re-checks the server over time — diffing the tool set against that baseline and re-running the same security checks against whatever the server now returns.

How to verify a server with a reproducible score

Reading every schema by hand does not scale, and it is easy to miss an injection buried in a parameter default. The practical answer is to run the audit through a tool that applies the same checks consistently and gives you a reproducible, explainable result instead of a yes/no verdict you cannot inspect.

CheckMCP turns the audit into one number with the reasoning attached: a 0-100 MCP Score and an A-F grade, broken down by weighted pillar, with the cause of every deduction stated as measure to mechanism to effect. Hard floors make the serious cases unambiguous — a secret in a tool schema caps the grade at D, and a failed handshake caps it at F — so a server cannot buy back a real security failure with polish elsewhere.

You can run the audit from the command line with 'uvx checkmcp <url>' (open-source, MIT, stdlib-only), from the web app at checkmcp.dev by pasting a URL, or in CI with the GitHub Action ('uses: H129hj/checkmcp@v1') to fail a build when a score regresses or a rug-pull appears. For higher assurance, the behavioral evals add the runtime layer, and the in-band Gateway plus drift monitoring keep watching an approved server after it passes.

Auditing an MCP server — FAQ

Related