M8ven Verification

How verification works

Transparency is what makes a trust score credible. Here is exactly what we check, how we score, and what we cannot detect.

The 4 layers of analysis

Layer 1: Declarative

no execution required

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.

  • Tool names and descriptions
  • Input schemas (what data each tool collects)
  • Read-only and destructive annotations
  • Mismatch between description and tool behavior

Layer 2: Source inspection

what the code actually does

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.

  • Where it reaches: which hosts and external services the code contacts
  • What it touches: filesystem access, including sensitive paths (SSH keys, credentials, wallets)
  • What secrets it handles: which environment variables are read, and whether any flow from secrets into outbound calls
  • What processes it spawns: shell or subprocess execution
  • Claim-vs-code match: tools declared read-only are checked for write operations; tool descriptions are compared against declared capabilities
  • Known vulnerabilities: declared package versions checked against public CVE data
  • Obfuscation: code that's been deliberately made hard to read
  • Supply-chain hooks: install-time scripts that could run code outside the tool surface
  • Basic handler hygiene: input validation and error handling in each tool

Layer 3: Repository hygiene

code quality signals

Beyond security, we check whether the repo follows basic engineering practices.

  • README documentation present
  • License file present
  • Test files exist
  • Tool coverage in tests (% of declared tools referenced)
  • npm test actually passes
  • TypeScript with tsconfig.json
  • Uses official MCP SDK

Layer 4: Continuous monitoring

verification stays current

When 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.

Scoring

Every check contributes to a 0-100 trust score. Failures subtract more than warnings. Annotation dishonesty (tools claiming read-only but containing write operations) and hardcoded secrets are weighted heaviest.

80-100
Trusted
Code, claims, hygiene align
60-79
Caution
Minor findings, review before use
0-59
Concern
Significant risk findings

What we cannot detect

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.

Time-bomb malware

Code that behaves normally for N days before activating malicious behavior.

Environment-triggered behavior

Malicious code that only activates on specific operating systems, credential patterns, or data inputs.

Server-side logic

If the agent calls a backend API, we can see the call but not what the server does with the data once it arrives.

Heavy obfuscation

We flag obfuscated code as a red flag in itself, but cannot always deobfuscate.

Closed source agents

Without source code we can only verify what is observable from outside (publisher identity, tool list, metadata).

Social engineering via legitimate tools

An agent that uses its declared permissions in ways the user did not intend.

Where we're heading

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.

Have questions or found an issue with a verification? Email us.