M8ven Verification
Transparency is what makes a trust score credible. Here is exactly what we check, how we score, and what we cannot detect.
We parse the MCP server's tool manifest — what tools it declares, what input fields each tool asks for, and what permission hints it sets.
We inspect the MCP's published source and compare what the code does against what the tool descriptions claim. The goal is to catch the gap between declared capability and actual behavior.
Beyond security, we check whether the repo follows basic engineering practices.
npm test actually passesWhen you embed our badge, every load checks the latest commit on the linked repo against the verified version. If the code has changed, the badge automatically updates to show a stale state.
Every MCP gets a letter grade, A through F. Grades reflect the full trust pyramid: code, verification depth, and reputation. Code findings subtract from the grade, with claim-vs-code dishonesty and hardcoded secrets weighted heaviest. Reputation caps it: a brand-new project with flawless code caps at C until adoption is earned. B needs real-world usage (stars, contributors); A needs sustained adoption and zero failing checks. An entry with an open failing check caps at B until it is fixed, no matter how widely adopted. Sustained monitored history contributes to a publisher's reputation. The underlying 0-100 score is shown on each listing for transparency, but the grade and its reason are the verdict.
Next to each grade is the reason it is not higher, worst news first:
Deep verification, clean findings, and earned adoption. The full pyramid.
Clean code and honest claims, but not yet widely adopted. The grade is capped by reputation, not by any finding. Not a warning.
Nothing bad found, but our analysis could not see deeply enough to say more. The limit is ours, not theirs.
We found specific issues worth reviewing before use. Listed on every detail page.
A serious finding: undisclosed data flows, claim-vs-code deception, or known-bad patterns.
Code Verified is a separate stamp, independent of the grade: it means our honesty checks ran and what the code does matches what the tool descriptions claim. An honest low-grade MCP can earn it; a high-grade MCP whose claims we could not verify does not.
A small curated allowlist of well-known publishers (the "Recognized" label) identifies repos on official vendor GitHub orgs. It is recognition, not verification, and does not bypass scoring.
A high score does not guarantee security. Verification narrows the unknowns — it doesn't eliminate them. Here's what stays beyond reach, and why we list it anyway: naming the limits is what makes the score mean anything.
Code that behaves normally for N days before activating malicious behavior.
Malicious code that only activates on specific operating systems, credential patterns, or data inputs.
If the agent calls a backend API, we can see the call but not what the server does with the data once it arrives.
We flag obfuscated code as a red flag in itself, but cannot always deobfuscate.
Without source code we can only verify what is observable from outside (publisher identity, tool list, metadata).
An agent that uses its declared permissions in ways the user did not intend.
Verification isn't a one-time label. We're working toward keeping every entry current as code, behavior, and publisher claims evolve over time — so a Verified badge reflects the MCP as it stands today, not the day it was first checked.