Why MCP server security scanning is different from code scanning

What SAST was designed for

Static Application Security Testing tools — Semgrep, CodeQL, Bandit, ESLint security plugins, FindBugs — were designed to analyze programs whose behavior is determined entirely by their source code. Their operating model is simple: given an input, the program follows code paths that can be traced from source to sink. A SAST tool finds exec(userInput), marks userInput as tainted, and flags the path as a command injection vulnerability. This works because the program is deterministic — the same input always produces the same code path.

MCP servers break this model at their architectural foundation. An MCP server is not called directly by a human or a deterministic system. It is called by an LLM, and the LLM decides which tools to call, with which arguments, based on its interpretation of tool descriptions, conversation context, and instructions that exist nowhere in the server's source code. The attack surface is not just the code. It is the code plus the model plus everything in the model's context window at the moment the tool is invoked.

The five gaps that SAST cannot cross

Gap 1 — Tool descriptions as an attack surface

A tool description is a natural-language string in an MCP server's manifest or schema that tells the LLM what a tool does, when to call it, and how to format its arguments. From a SAST perspective, it is a string constant — harmless. From a security perspective, it is a policy document that the LLM treats as authoritative.

SkillAudit's LLM-assisted scan reads tool descriptions as the model will, red-teaming them for embedded instructions, misleading capability claims, and authority escalation language. No static analysis tool has a rule for this category because the attack surface is semantic, not syntactic.

Gap 2 — Capability pairing amplification

A single MCP server that provides read_file and send_http_request tools is not particularly dangerous in isolation. read_file reads files. send_http_request sends requests. Both look harmless when analyzed independently.

Together, they compose an exfiltration primitive. An LLM instructed (by a malicious tool description, a user prompt injection, or a compromised system prompt) to "back up the project" can call read_file on ~/.ssh/id_rsa and then send_http_request to an attacker-controlled endpoint. Neither tool contains a vulnerability in its own code. The vulnerability is in their combination, and combinations are not something SAST tools enumerate.

SkillAudit's permission hygiene check specifically looks at the cross-product of declared capabilities. An MCP server that exposes both read_* and network-egress tools without path restrictions, domain allowlists, or per-tool permission scoping is flagged — even if every individual function is clean. This is the same analysis described in our permission scope patterns guide.

Gap 3 — Trust boundary violations that span runtime layers

Traditional web applications have a clear trust model: the server trusts its own code, distrusts user input, and the security boundary is the parser that reads that input. SAST tools are trained on this model. Taint flows from sources (HTTP parameters, headers, cookies) to sinks (SQL queries, shell invocations, file writes).

MCP servers have three trust boundaries, not one, and two of them do not correspond to any concept in traditional SAST:

• Caller → server: The LLM sends tool arguments. This is analogous to user input, and SAST can reason about it — though it rarely has MCP-specific rules for tool argument validation.
• Tool description → model: The server's manifest shapes how the LLM will invoke the tools. This is a trust boundary that flows backward — from the server to the model — and has no analogue in SAST's source/sink model.
• Server → backend: The server calls databases, filesystems, or external APIs. SAST can find some of these sinks, but only if the upstream data (LLM-generated arguments) is correctly modeled as tainted — which requires MCP-specific source definitions.

A SAST tool running on an MCP server without MCP-specific rules will treat LLM-generated tool arguments the same way it treats a compiled-in constant: clean, trustworthy, not a taint source. Every sink that receives LLM arguments without validation will be missed.

Gap 4 — Context-window data exfiltration

The LLM's context window at tool invocation time may contain the user's previous messages, system prompts, other tools' outputs, and injected instructions from prior tool calls. An MCP server can exfiltrate this context not through any detectable code pattern, but by returning a crafted response that the LLM echoes into subsequent tool calls — or by including instructions in a tool response that prompt the model to transmit data.

This attack class appears in our deep-dive on prompt injection anatomy. It requires a tool that scans tool response content for embedded natural-language instructions — a category that no traditional SAST rule set covers because SAST does not understand natural language.

Gap 5 — Maintenance-grade security drift

A SAST scan reflects the security posture of the code at the moment it was run. It does not track whether a dependency has been abandoned, whether a CVE was published against a library the server depends on three months after the last commit, or whether the maintainer archived the repository.

Maintenance-grade drift is a major source of MCP server risk. Our 30-day rescan delta analysis found that maintenance and dependency findings were the two most common regressions across rescanned servers — even servers that were clean on first audit. A server with no code vulnerabilities on day 1 can become a high-risk installation by day 90 purely due to dependency CVEs and maintainer inactivity, neither of which a point-in-time SAST scan will detect.

What traditional SAST does catch in MCP servers

This is not an argument that SAST is useless for MCP servers. SAST catches the same classes of code-level vulnerabilities it always has, and those vulnerabilities absolutely exist in MCP server code:

The composability problem

One of the most important differences is composability. A traditional web API exposes endpoints that are called in a sequence determined by application code that you control. An MCP server exposes tools that are called in a sequence determined by an LLM, based on an instruction that may come from a user, a system prompt, another tool's output, or a maliciously crafted document the LLM was asked to summarize.

This means the security posture of an MCP server cannot be evaluated by looking at each tool in isolation. The tools form a capability surface, and the LLM is a policy engine that operates over that surface with very different semantics than a human programmer would expect. A server that looks safe tool-by-tool may be dangerous in combination — and the combinations that matter are the ones an adversary will construct, not the ones the developer intended.

Security analysis for MCP servers therefore requires enumerating dangerous compositions, not just dangerous functions. This is closer to attack-path analysis in a network security scanner than to SAST. The analogy: SAST checks that your firewall rules are syntactically valid; a network scanner checks whether an attacker can actually reach your database through the firewall. MCP-specific scanning does the same for capability surfaces.

Documentation completeness as a security signal

There is a category of MCP server risk that is entirely overlooked by SAST: documentation quality. A tool with an ambiguous or missing description is not just a usability problem — it is a security problem. An LLM filling in missing information about what a tool does and when to call it will make inferences based on its training, not on the tool author's intent. Those inferences can be wrong, and wrong inferences about when to call a destructive tool (delete_resource, send_message, transfer_funds) have consequences.

Well-documented tools with explicit behavioral contracts — "this tool only reads; it never writes", "this tool must not be called with user-provided paths" — constrain the LLM's interpretation and reduce the attack surface. SkillAudit's documentation completeness check evaluates whether tool descriptions provide the behavioral contracts that safe LLM invocation requires, not just whether the README has a Getting Started section.

Running SAST and MCP-specific scanning together

The right answer is both, not either. SAST catches code-level vulnerabilities that have well-understood patterns. An MCP-specific scanner catches the LLM-layer vulnerabilities that SAST was not designed for. The handoff between the two layers looks roughly like this:

Neither layer replaces the other. A server with a green SkillAudit badge and no SAST in its CI pipeline has uncovered SQL injection and path traversal. A server with passing Semgrep and no MCP-specific scan has uncovered prompt injection and capability composition risks. Both layers are needed because the attack surface spans two different models of program behavior — deterministic code paths and probabilistic LLM policy execution.

The practical implication for publishers

If you are publishing a Claude skill or MCP server to a directory — Anthropic's official directory, MCP Market, or an awesome-mcp list — reviewers are not running Semgrep. They are looking at whether your tool descriptions are safe for LLMs to interpret, whether your capability surface creates dangerous compositions, and whether your server will still be maintained in six months. Those are the checks that differentiate an audited server from an unaudited one, and they require an MCP-specific scan to surface reliably.

The security checklist in our MCP server security checklist walks through the manual version of this analysis. SkillAudit automates it into a grade that other developers and team leads can trust without spending an hour reading source code they did not write.