Security grades for the tool servers you install
You installed a tool server. Nobody read what it tells your model to do
A tool description is not documentation. It is instructions the model follows. MCP Audit grades every server in your registry and publishes the results, so installing one stops being an act of faith.
The problem
The supply chain moved into the prompt and nobody moved the review with it
Installing a package gets a lockfile, a CVE feed and a dependency scanner. Installing a tool server gets a copy-pasted config block. Yet the server ships text that goes straight into the model context with your permissions attached, and a malicious description does not need a CVE — it just needs a sentence.
The insight
The registry is the product, not the scanner
The detector is the same one Injection Range runs; pointing it at installed servers rather than a pull request changes who cares about the answer. A team choosing between four calendar servers wants a grade before they install, not a CI failure afterwards. That grade is only credible if it is public, reproducible and applies the same correction to everyone — which is why the methodology is published and the corpus is open.
Per-server scan across every tool description it exposes, scored against a benign first-party corpus for empirical p-values and BH-corrected within the server, then graded on the surviving findings weighted by the scopes the server requests.
How it works
Four steps, no data science team
Every MCP server your team has installed, with the tools each exposes.
Findings that survive correction, weighted by what the server is allowed to touch.
A server that was clean can ship a new description tomorrow. Re-graded on every version bump.
The public registry is free. Your private servers stay private.
Who it is for
The platform lead who owns what gets installed
Platform teams who have let engineers install tool servers, and now need to say something defensible about which ones are safe.
Pricing
- –Public grades
- –Open corpus
- –Version history
- –Private server scanning
- –Version-bump alerts
- –Policy gate
- –Scope-weighted grading
- –Self-hosted
- –Install-time gate
- –SIEM export
- –Custom policy
Competition
What exists, and what it does not do
| Who | What they do | The gap |
|---|---|---|
| Package scanners and SCA | Grade npm and PyPI dependencies for known vulnerabilities. | They look for CVEs in code. A malicious tool description has no CVE and is not code. |
| Official and community registries | List available servers, sometimes with download counts. | Popularity is not safety, and none of them inspect what the tool descriptions actually say. |
| Runtime guardrails | Filter what reaches the model at request time. | Useful, and too late to inform the install decision. You still chose the server blind. |
| Reading it yourself | What a careful engineer does for the first server and not the twelfth. | Does not scale, is not repeatable, and nobody re-reads on a version bump. |
This may be a public good rather than a business: the registry is the valuable part and the registry is free. The paid tier depends on teams having enough private servers to care, which is true today at large companies and may never be true at small ones. There is also a real chance the official registry adds grading and makes the free tier redundant overnight — the hedge is that the corpus and the correction methodology are the asset, and those travel. Being early and being cited is worth more here than being first to charge.
Market
The registry is distribution rather than revenue; the paid tier attaches to the platform-security budget
Narrower than it looks in dollars and wider than almost anything else here in reach. A public grade cited in install decisions is the cheapest audience-building available, and the audience overlaps exactly with the buyers for Keyring and Injection Range.