Rules and Coverage

Aevrin scans MCP servers and the agents that install them. It is not a general-purpose source-code scanner: there are no findings about Dockerfile style, CI configuration, branch protection, repository badges, or fuzzing status. If your MCP server's repository also has an unrelated bug in its web handler, Aevrin will not tell you about it.

Every finding comes from one engine, run against a live server. Aevrin starts the server, completes the MCP handshake, reads what it offers, and analyses that. A repository is only ever a way of finding out which server to start - it is not itself the thing being assessed.

A finding is usually about one tool, but it does not have to be. It can also be about a prompt, the server as a whole, the way it is configured and launched, its code, or one of its dependencies. Those findings name no tool.

Rule groups

The engine has 75 rules. Each rule id reads MCP-<GROUP>-NNN, and the group says what kind of problem it is.

A rule has no fixed severity. The engine sets the severity of each finding when it reports it, so the same rule can produce findings of different severities. The OWASP column below is the OWASP MCP Top 10 category Aevrin files each rule under.

Every rule

Authentication

Configuration

Dependencies

Runtime behaviour (not run today)

Execution

Files

Injection

Network

Permissions

Tool poisoning

Privilege

Protocol

Quality

Scope

Secrets

Shadowing

SQL

Source code

What Aevrin no longer reports

Repository security is not MCP security, and mixing the two buried the findings that matter. Aevrin does not report on a repository as a whole: no dependency CVEs across its whole tree, and nothing about Dockerfiles, CI configuration, branch protection or repository badges. Where a rule reads code or packages, it asks an MCP question about the server being scanned, such as whether tool input reaches a system command (MCP-EXEC-002).

Supply-chain coverage comes from the MCP-DEP rules (a known malicious package, a typosquatted name, an install script, a loose dependency) and the MCP-CFG rules about how the server is installed (an unpinned package or Docker image, an install from a URL or git repository). None of the 75 rules looks up published vulnerabilities (CVEs) in dependencies.

Evidence

Every finding carries the specific facts that made its rule fire: where it was found and what matched. It also explains itself: why it matters, how it could be used against you, and how to fix it.

The engine checks its own findings. A finding it marks as a likely false positive, or suppresses, adds nothing to its score, and Aevrin drops it from the report.

Identical verdicts from one rule across several tools are shown as one finding with every affected tool listed. A server with twenty-four tools that all lack safety annotations has one problem, not twenty-four. Critical findings are never grouped: a critical is read individually, by name. A finding about several tools at once, or about no tool, is shown as it is. Grouping changes how the report reads, never the grade.

Stages

A scan has five stages, and each one is a real step:

1. Resolving - work out the command that starts this server.
2. Launching - start it, in an isolated container.
3. Enumerating - complete the MCP handshake and read its tools.
4. Analyzing - run the rules over what was read.
5. Grading - the engine grades the whole server, and Aevrin writes the summary.

A scan that stops at any of them is incomplete and receives no grade at all, with the reason attached. A server that will not start, or that returns no tools, has not been shown to be safe: it has not been assessed. See Concepts.

The grade is for the whole server, not for each tool, because you install the whole server. The engine works out a risk score from 0 to 100, where higher is worse, and turns it into a letter: A at 0, B below 15, C below 35, D below 60, F at 60 or more. An F also needs at least one validated high or critical finding; a high score alone is not enough. See Risk score and grade.

Deliberate limits

• Only servers that can actually be started can be graded. A server needing API keys, a browser, or a private registry is reported as unassessed rather than guessed at.
• Dynamic checks are off today. The engine does not call a server's tools, so nothing is tested at run time: the MCP-DYN rules and MCP-INJ-004 never fire. A tool whose description and code look unremarkable but which misbehaves when called is outside what this scan can see.
• That includes prompt injection in live tool responses (MCP08). Aevrin does not test it, and every report says so explicitly.
• A grade describes one version at one moment. Reinstalling later can get different code.

Aevrin records these as limitations; it does not manufacture coverage for tests that did not run.