Security profile

SkillSpector was built for small skill folders. Pointed at a whole MCP server repository it reports a lot: an HTML comment in a README counts as a hidden instruction, the string .env in a .gitignore counts as credential access, every outbound API call counts as exfiltration. Its own risk score puts Microsoft's Playwright MCP at 100, CRITICAL. That is why MCPVault does not publish a score. It keeps every finding and turns the ones that matter into a profile:

1. Findings are classified by the file they sit in. Shipped code and agent-facing instruction files count. README, other docs, configuration, CI and test files are recorded as notes and left out.
2. Each remaining finding maps to a capability, the plain-language statement of what the code can do. Several findings can back one capability; the profile shows how many places it was seen.
3. Dependencies with known advisories are listed separately by package, version and identifier, straight from OSV.dev.
4. Eight core capabilities are named even when absent, so a quiet profile still says something concrete.

The capabilities a profile can contain:

The profile carries one summary word, its exposure level, so a listing can be read at a glance. Exposure describes how much of the machine and its secrets the code reaches. It is derived only from which capabilities are present, never from a risk score, and it does not say whether that reach is justified. A terminal tool is Limited because it runs commands; an editor integration is Broad because it writes into the editor's config folder. Both are doing their jobs.

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. The owner dashboard lists them; the public profile shows only their count.

There is no score. An internal weighting exists so MCPVault staff can sort a queue for review, but nothing on the site ranks or colours a server by it, and the exposure level above does not use it.

Start with the detected list and ask whether each item fits what the server is for. A filesystem server that runs shell commands is doing its job; a weather server that reads environment variables in bulk deserves a look at the file it happens in. Then read the hosts line, because that is where your data can go. Then check the dependency list; an old lockfile is the most common and most fixable item.

The "not detected" line is the other half of the story. A server with nothing detected is one where the scanner found none of the patterns it knows. It is not proof of safety, but it is a concrete statement you can hold the code to.

Your dashboard shows every item with the file, the line, the matched snippet and a fix, plus the notes that were excluded. Nothing in the profile penalises you for claiming: the same code reaches the same things whether or not the listing is yours, and an honest profile next to a verified badge is what makes users comfortable installing.

Refreshing a lockfile clears the advisories on the next weekly run. For capabilities that are by design, a sentence in your README explaining why the server needs them helps users more than anything the scanner can say. If the profile reads unavailable, the repository URL on the listing is private, renamed or too large to snapshot; fix it from your listing editor and the next run retries.

This is static, pattern-based analysis. It finds things that look like known patterns; 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. That is why every item carries its file and line, so you can check it yourself.

The profile complements verification. Verification proves the server runs and answers. The profile 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, and neither replaces your client's tool approval prompts.