Most MCP demos look the same. A tool is registered. A client calls it. The tool returns the expected data. Everyone nods.
That demo tells you the tool can work. It tells you nothing about what happens when the tool is given the wrong tenant ID, or when it declares scope it should not have, or when it is about to reach users who did not write it.
I built a preflight scanner for exactly that gap. This post is about what a bounded preflight can actually check, and what it honestly cannot.
An MCP tool is a capability. Some capabilities are safe to hand out freely. Others are not.
Common risky declarations:
filesystem:* or network:* scope when it only needs to read one directory.
These are not exotic. They show up in real MCP servers being shipped right now.
The scanner I built runs two kinds of checks: static and behavioral.
Static rules look at the tool metadata: name, description, declared scopes, and any command patterns. Four rules cover the common cases:
MCP-001: unsafe command declaration. Anything that runs a shell or takes a free-form command string.MCP-002: excessive filesystem or network scope. Anything that declares network:egress when the tool clearly does not need it.MCP-003: secret-like value in tool metadata. Anything that looks like an API key, token, or password embedded in a description or default config.MCP-004: untrusted input reaching a sensitive operation. Anything where user input flows into a command, a file path, or a URL without an obvious boundary.
Behavioral checks actually call a local fixture server and observe what happens:
Each check produces a pass, fail, blocked, or incomplete status. Nothing is reported as a pass if it was not actually run.
One run produces both a Markdown report and a JSON report. Each finding has:
The point is that a finding becomes an engineering task, not a vague warning.
It is not a penetration test. It is not a certification. It is not a scan of a real customer environment. It does not replace a real security review.
It is a bounded, repeatable first pass. It catches the obvious things before they ship, and it does so without pretending to be more than it is.
A preflight can tell you that a tool declares too much scope. It cannot tell you that the scope is intentional and appropriate for the business. That is a decision for the team.
A preflight can tell you that a write tool ran without an approval. It cannot tell you whether the approval was correctly granted in a real workflow. That is a process question.
The scanner is a filter. It narrows the surface for the human review that still has to happen.
The code is at github.com/glatinone/mcp-security-preflight. If your team is about to expose MCP tools to users or internal agents and wants a bounded first pass, I take short sprints on exactly this. kielltampubolon.id