Security scan

SkillSpector was built for small skill folders. Pointed at a whole MCP server repository, its own score saturates: an HTML comment in a README counts as a hidden instruction, every outbound API call counts as exfiltration, and a dozen medium findings add up to 100. Microsoft's Playwright MCP scores 100 CRITICAL that way. So MCPVault keeps every SkillSpector finding but applies its own MCP-server policy.

1. Findings are classified by the file they sit in. Shipped code and agent-facing instruction files are scored. README, other docs, configuration, CI and test files become notes.
2. Each rule gets a weight that reflects what it means for someone installing an MCP server. A subprocess call is often the whole point of the tool; harvesting the entire environment is not.
3. Per-rule diminishing returns: the first occurrence counts in full, the second half, the third a quarter, and later ones not at all. A pattern repeated a hundred times cannot drown one serious finding.
4. Known-vulnerable dependencies score per package (12 critical, 8 high, 4 medium, 2 low) and are capped at 30 points, so an old lockfile reads as "update these" rather than "do not install".

Points add up to a 0 to 100 score, lower is better: 0 to 20 low risk, 21 to 50 caution, 51 to 80 high risk, 81 and up critical. The raw SkillSpector score is stored alongside for transparency. Some example weights:

Before the scan runs, the snapshot is pruned to what a user actually installs: tests, CI workflows, docs folders, examples, build output and vendored dependencies are removed. Pattern matches that remain in documentation or configuration are recorded as notes with a one-line reason and left out of the score.

Outbound requests are not scored either, because an MCP server that wraps an API has to call that API. Instead the card lists the hosts the code talks to, so you can see where data goes before you grant the server anything.

The score box shows the number and a label. Below it: how many scored findings, vulnerable dependencies, external hosts and notes. Vulnerable dependencies list the package, the version and the advisory identifiers. Findings show the rule, the pattern, the file and line, and what it means. The public card shows the top findings; the owner dashboard shows all of them with fixes.

A low score means the scanner found nothing that looks like credential theft, exfiltration or hidden instructions in the shipped code. It does not mean the server is safe to give root. Read the Talks to line and the tool list, and keep the client-side permission prompts on.

Your dashboard shows every scored finding with the snippet that matched and a remediation, plus the notes that were excluded. Fix what is real, and the next weekly run picks up the new commit automatically. Updating a vulnerable dependency is usually the fastest way to move a score.

A false positive you cannot change, such as a safety notice that trips the harmful-content rule, is worth a note in your README so users understand it. If the card says unavailable, the repository URL on the listing is private, renamed or too large to snapshot. Fix the URL from your listing editor and the next run retries.

This is static, pattern-based analysis. It finds things that look like known problems; it does not prove the absence of unknown ones and it is not a penetration test. A string that looks like a credential path can be a comment; a subprocess call can be the feature. That is why every finding shows its file and line, so you can check it yourself.

The scan complements verification. Verification proves the server runs and answers. The scan tells you what the code reaches for while it does. Neither replaces reading the source before you give a server access to your files, keys or shell.