A red-teamer's three-point checklist targets the security gaps most MCP server reviews miss

What the post says

A post on dev.to, written by someone who says they red-team LLM applications for a living, argues that the Model Context Protocol (MCP) has quietly become the standard wiring between LLM apps and tools, databases and internal APIs, while security reviews still treat that layer like an ordinary library call. The author's core claim is a distinction most reviews miss: a prompt is untrusted text, but a tool call is a capability. When a model invokes a tool it triggers a real side effect, such as a file write, a database query, an outbound request or a payment, and because the call returns a normal-looking result, the surrounding application records a success even when the action was wrong.

The post distills the problem into three failure modes the author says dominate field work, each paired with a quick check.

Tool descriptions double as instructions

MCP servers ship with natural-language descriptions for every tool, and the model reads them. According to the post, that makes the description text part of the instruction surface: a verbose or ambiguous description, or an example that is more permissive than the application intends, can steer the model toward broader use than designed. The suggested check is to read each description assuming an attacker wrote it, then work out the widest action the model could plausibly justify from that text alone.

Argument validation is the actual boundary

Descriptions accomplish nothing without enforcement behind them. The post flags any tool that accepts a path, query or URL argument and passes it straight through, because that becomes a path traversal, injection or server-side request forgery vector the model can reach from a single crafted user message. The check: for every string argument that reaches the filesystem, a query builder or an HTTP client, confirm there is an explicit allow-list or a validated scheme. The author is blunt that sanitizing model output does not count as a boundary, since the model's output is precisely the channel an attacker controls.

Success paths hide the failures

The third failure mode is logging. Per the post, applications typically record a successful tool call and move on, even if the model composed a message for the wrong recipient or included data that should not have been included, with nothing raising an alarm. The recommended fix is deliberately minimal: add a single assertion on the most sensitive field of the highest-risk tool, such as recipient, destination or amount, and fail loudly if it falls outside a narrow expected set. The stated goal is to make quiet failures noisy, starting with one test, rather than to build a full audit pipeline before shipping.

A packaged scanner, with caveats

The author also bundles eight probes from the checklist into a free scanning endpoint: point it at a tool spec or a prompt and it returns a short risk report naming the specific field it flagged. The post claims the report is deterministic and that a hash of a self-scan is published so the same input can be verified to produce the same output. It is worth noting the service is hosted on a personal Cloudflare Workers domain rather than an established vendor, and deniz.in has not verified it; teams should also weigh the risk of pasting internal tool specifications into any third-party service. The post itself frames the scanner as a quick signal, not a substitute for a real review.

The single highest-leverage step before shipping, the author writes, is to write down for each tool the one field that, if wrong, would constitute the incident, then write the one test that catches it.

Why it matters

MCP adoption has outpaced the review practices around it, and the post's central point is hard to argue with: as models gain the ability to act, prompt injection becomes action injection. The failure the industry watches for is a model saying the wrong thing, which is visible; the failure that actually bites is a model doing the wrong thing, which gets logged as success. The checklist is cheap, concrete and testable without a pentest budget, which is exactly what fast-moving MCP deployments currently lack. The advice comes from a single practitioner blog post rather than a standard or vendor guideline, so treat it as a starting point for an audit checklist rather than the last word.