I ran my MCP auditor on Anthropic's own reference server. It found a gap.

# I ran my MCP auditor on Anthropic's own reference server. It found a gap.

The Model Context Protocol is about eighteen months old. It's already the way Claude Desktop, Cursor, Windsurf, Cline, and most of the other AI IDE integrations actually talk to the outside world. Every developer building an MCP server is building production infrastructure that the LLM will eventually execute tool calls against.

A protocol this new has almost no dedicated security tooling. So I built one. It's called mcp-security-scanner, it's on GitHub at github.com/TreRB/mcp-security-scanner, and the one-liner is:

npx github:TreRB/mcp-security-scanner /path/to/your-mcp-server

The scanner runs five checks against an MCP server's source. Tool argument validation, shell passthrough, filesystem scoping, SSRF via fetch, and credential exposure. I wrote them based on attacks I've seen in the wild: prompt injection that triggers a tool call the user never intended, shell metacharacters sneaking into exec arguments, directory traversal inside scoped filesystem tools, fetch tools that happily hit 169.254.169.254, and credentials leaking into tool descriptions or error messages.

The first thing I did after v0.1.0 compiled was run it on Anthropic's own reference servers. Seemed like the right calibration target: these are the canonical examples every MCP server author copies from. If the reference is clean, other implementations probably inherit its patterns. If it isn't, the pattern propagates.

#What the scanner found

Running against anthropics/mcp-servers on the server-memory implementation, the scanner fired check MCS1 (tool argument validation) with MEDIUM severity. The specific finding:

> create_entities tool accepts an observations: string[] input with no schema-enforced length cap or content validation. A malicious client can inject arbitrarily long strings or control characters that end up persisted in the knowledge graph.

This is not a critical vulnerability. It doesn't give an attacker RCE. It's a schema hardness gap: the tool's JSON Schema uses array of string without length constraints, pattern validators, or content filters. In practice that means a prompt-injection attack that reaches create_entities can write whatever it wants into the memory graph, including strings that round-trip into the model's context on the next query and bias future tool calls.

The pattern matters more than the specific finding. JSON Schema's default stance is permissive: if you don't declare constraints, the field accepts anything. For MCP tools that persist state or make downstream decisions, permissive defaults are the wrong defaults.

#Why this propagates

I checked a handful of third-party MCP servers after seeing this in the reference. The same pattern showed up in most of them. Tool inputs declared as string or array with no length or content constraints. Many of them run tools that write to databases, call external APIs, or spawn processes. A permissive schema on those is the difference between "the model can use this tool" and "the model can be tricked into using this tool in ways the author didn't anticipate."

MCP isn't unique. Every RPC protocol has this problem. What MCP does have is a direct pipeline from an attacker-influenced LLM output to a server-side tool call, with fewer intermediate trust boundaries than the usual HTTP + REST + frontend stack. That amplifies the consequences of schema permissiveness.

#What the fix looks like

For any MCP tool whose inputs persist state or reach downstream systems, the schema should declare:

• maxLength on string fields that get stored or rendered
• pattern regex constraints on fields that should match a known format (UUIDs, identifiers, URL slugs)
• maxItems on arrays and maxProperties on objects
• enum for fields that accept a known finite set of values

For server-memory specifically, the fix would be adding maxLength: 10000 and maxItems: 100 to the observations schema, and probably a pattern that strips control characters. The tool author knows the intended shape of the data. The schema should express it.

#Running the scanner on your own MCP server

If you maintain an MCP server, run the scanner on it:

npx github:TreRB/mcp-security-scanner /path/to/your/server

It takes a few seconds, produces a SARIF 2.1.0 output for GitHub code scanning, and flags the five check categories. Zero runtime deps beyond Node 20+. The five checks are:

• MCS1 Tool argument validation: finds tool schemas that are permissive about input shape
• MCS2 Shell passthrough: finds tools that call exec or spawn with user-supplied arguments
• MCS3 Filesystem scope: finds tools that accept paths without checking for .. or absolute-path escapes
• MCS4 SSRF via fetch: finds tools that fetch URLs without a host allowlist or metadata-endpoint block
• MCS5 Credential exposure: finds API keys or tokens leaked into tool descriptions, error messages, or example arguments

I'll keep adding checks as new attack patterns come out of Anthropic's own guidance and from the MCP community. If you find a pattern the scanner misses, open an issue.

The companion tool is mcp-client-inspector at github.com/TreRB/mcp-client-inspector. Where mcp-security-scanner is a static audit of an MCP server's source, mcp-client-inspector is an evil-server harness that tests whether your MCP client (Cursor, Claude Code, etc.) defends against malicious servers. Different half of the same problem.

Both are free, MIT-licensed, and have no hosted component. Everything runs locally.

#Why I wrote both

Every security product in MCP's adjacent space is either a SaaS with gated features or a proof-of-concept that the author abandoned. Developers building MCP integrations need something they can run in CI today, with no signup, no account, and no rate limits. That's the tool I wanted to exist.

Shipping it is how I find out whether my five checks are the right five. Running it on Anthropic's own reference server was a calibration exercise. It found something. It found the right something. That's the only reliable way to know whether a new security tool is good enough to trust.

Try the scanner. Tell me what it misses. If it catches something real in your codebase, send me a note at tre@valtikstudios.com.