This server provides AI agents with access to Verdict Finance's institutional DeFi ratings, featuring letter grades and composite scores for 7 entity types: protocol, chain, token, oracle, vault, organisation, and bridge. No API key required — anonymous, rate-limited access (120 req/min, 20k/day).
Key capabilities:
Search ratings: Find entities by name/keyword, optionally filtered by entity type. Returns matching entities with their letter grade and composite score.
Get a full rating: Retrieve a specific entity's detailed free-tier rating (slug or UUID). Includes letter grade (AAA–D), composite score (0–100), public metadata, and dependency-drag provenance when a weak dependency affected the grade.
Browse/list ratings: Browse rated entities of a given type, filtered by category (e.g., lending) or chain (e.g., Ethereum). Results are sorted best-rated first, with customizable limit (default 25, max 50). Unrated entities are marked.
Additional details: Ratings are built from 300+ criteria; every response includes a Verdict attribution link. (Roadmap includes parametric cover, audit firm blind bids, watchlists/alerts, and frontend pentests.)
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@verdict-finance-mcp What's Verdict's rating for Uniswap?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Verdict is the due-diligence house for DeFi: independent ratings, rating-priced cover, security testing and continuous monitoring, plus a security partner marketplace for audits, monitoring and pen testing, across seven entity types. This Model Context Protocol server lets AI agents call that house directly.
Live today: Ratings. Letter grade (AAA to D) plus a composite score (0 to 100) built from 300+ criteria across the full dependency graph, for protocols, chains, tokens, oracles, vaults, organisations and bridges. Plus post-quantum readiness for chains, and a live feed of DeFi hack incidents (confirmed by default).
Keyless by default. It wraps Verdict's live anonymous API, so there is no signup and no API key. Each user runs it locally and queries from their own IP. Bring your own key if you want the per-domain breakdown behind a grade (see below).
Add to your MCP client config (Claude Desktop: claude_desktop_config.json;
Claude Code: .mcp.json):
{
"mcpServers": {
"verdict-finance": {
"command": "npx",
"args": ["-y", "verdict-finance-mcp"]
}
}
}That is it. No key needed to read ratings. (Requires Node 20+.)
Related MCP server: safeagent-token-safety
Tool | What it does |
| Find entities by name or keyword. Omit |
| Letter grade, composite score and public metadata for one entity, by slug ( |
| Browse a set, best-rated first (default 25, cap 50). Category filters are lowercase, e.g. |
| Post-quantum cryptographic readiness for chains (QRI 0-100, readiness band, migration stage, hybrid-signature status), data by LayerQu. Omit |
| DeFi hack incidents, newest first (default 25, cap 200). Confirmed by default; |
| The published methodology: criteria counts and domains per entity type, and the AAA to D grade scale with the composite band each grade needs. |
| The per-domain scores behind one entity's grade, plus its intrinsic (pre-dependency) pair. Needs an API key; see Bring your own key. |
| Ask Verdict to rate an entity it does not cover yet. Returns a reference id. The resulting rating is public either way; requesting coverage never buys or moves a grade. |
Every rating response ends with an attribution line linking back to the rating on verdict.finance.
Ratings are free to read: the tools above work with no key at all. Set
VERDICT_API_KEY and the server authenticates every call, which adds
get_rating_breakdown (per-domain scores). Keys come from the Verdict
dashboard at verdict.finance; plans are at
verdict.finance/pricing.
{
"mcpServers": {
"verdict-finance": {
"command": "npx",
"args": ["-y", "verdict-finance-mcp"],
"env": { "VERDICT_API_KEY": "your-key" }
}
}
}Without the variable the server behaves exactly as it always has: no header is
sent, and nothing about the keyless path changes. The key is never logged,
echoed, or included in tool output. Called without a key,
get_rating_breakdown answers with where to get one rather than failing.
Agent-native micropayment access (x402) is the announced direction. It is not shipped, and nothing here is behind a paywall today.
Quantum-readiness data is provided by LayerQu and is companion data only. It never feeds a Verdict grade; chain ratings simply carry an extra LayerQu line when a reading is available.
The incident feed carries hack incidents across DeFi (confirmed by default), including ones at protocols Verdict does not rate. Two things are worth knowing when reading it. Matching to a rated protocol happens when an incident is received, and re-runs when an incident escalates and its payload improves, so matched_protocol reads as of the incident's current tier. It is still never retroactive when Verdict's own coverage grows. And an incident is a signal to look, never an automatic downgrade: a matched entity may be flagged under review, but re-rating is always a human decision.
"What does Verdict rate Aave?" runs get_rating({ entity_type: "protocol", identifier: "aave-v4" })
"Search Verdict for Chainlink." runs search_ratings({ query: "chainlink" })
"List the chains Verdict rates." runs list_ratings({ entity_type: "chain" })
"Is Ethereum quantum-ready?" runs quantum_readiness({ chain: "ethereum" })
"Any DeFi hacks this week?" runs get_recent_incidents({ limit: 10 })
"How does Verdict score a bridge?" runs get_methodology({})
"What dragged Aave's grade down?" runs get_rating_breakdown({ entity_type: "protocol", slug: "aave-v4" })
"Get my protocol rated." runs request_coverage({ entity_name: "...", entity_type: "protocol", contact_email: "..." })
Aave V4 — BBB (78/100) · protocol · chains: Ethereum · categories: lending · https://www.verdict.finance/products/ratings#protocol-aave-v4
Rating by Verdict — https://www.verdict.finance/products/ratings#protocol-aave-v4 · Methodology + deeper analysis at https://www.verdict.financeEntities that are not yet rated render as unrated. When a rating was pulled
down by a weak dependency, the response says which one.
Verdict's diligence lifecycle is Assess, Rate, Cover, Secure, Monitor. Ratings are the first module agents can call. As the rest of the house becomes callable, this server grows a module per product:
Cover: rating-priced parametric cover on rated protocols.
Audit Marketplace: hand over a repo, receive blind bids from vetted audit firms.
Monitoring Marketplace: watchlists, live alerts and webhooks on rated entities.
Pen Test Marketplace: engage penetration tests through vetted partner firms, scoped and priced per engagement by the partner.
The rating function stays structurally separate from what the marketplace sells: buying a service never moves a grade.
Tool names are module-scoped (search_ratings, get_rating, list_ratings)
so new modules arrive without breaking existing agents.
Verdict's read API is anonymous and rate-limited per IP (120/min, 20k/day). This server:
lists and looks up entities via GET /{type}s and GET /{type}s/{identifier},
fetches each entity's latest published scorecard
(GET /{type}s/{id}/scorecards) for the grade + composite score,
reads the published methodology from GET /methodology,
reads per-domain scores from GET /{type}s/{slug}/domains (the one route that
needs a key), and
submits coverage requests to POST /contacts, the same public endpoint the
"Get rated" form on verdict.finance posts to.
The API base is https://api.verdict.finance/api/v1 and can be overridden with
the VERDICT_API_BASE environment variable (used for testing). Set
VERDICT_API_KEY to authenticate; leave it unset to stay keyless. The full API
surface is documented at
api.verdict.finance/openapi.json.
Rate limits and outages are handled gracefully. Tools return a friendly text message, never a crash.
Ratings and methodology are © Verdict. This tool surfaces the public ratings and the published methodology; the deeper analysis lives at verdict.finance. The code is Apache-2.0; the Verdict name and branding are not licensed by it.
npm install
npm run build # tsc -> dist/
npm test # vitest (unit tests, HTTP client mocked)
# optional live smoke against the real API:
VERDICT_LIVE_SMOKE=1 npx vitest run test/live.smoke.test.ts
# the smoke's one keyed case (get_rating_breakdown) skips unless a key is set:
VERDICT_LIVE_SMOKE=1 VERDICT_API_KEY=... npx vitest run test/live.smoke.test.tsApache-2.0. Copyright 2026 Verdict Capital.
Get the full free-tier Verdict rating for one DeFi entity (letter grade + composite score 0-100 + public metadata). Identify it by slug (e.g. 'aave') or UUID. Example: get_rating({ entity_type: 'protocol', identifier: 'aave' }).
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | The entity's slug (e.g. 'aave' or 'ethereum') or UUID. | |
| entity_type | Yes | The kind of entity: protocol, chain, token, oracle, vault, organisation, or bridge. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return values (letter grade, composite score, metadata) and input format. No annotations provided, so description carries burden. Lacks disclosure of rate limits, auth needs, or side effects, but adequate for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first states purpose and output, second shows example. No wasted words, front-loaded key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return values. Input schema well-documented. Lacks usage guidance against siblings, but otherwise complete for a simple get tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by specifying identifier can be slug or UUID and providing example usage, which aids correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Get', resource 'full free-tier Verdict rating', and scope 'one DeFi entity'. Distinguishes from sibling tools (search_ratings, list_ratings) by implying single entity lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Example provided but does not compare with siblings. Usage is implied by the tool's function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse Verdict's DeFi ratings for one entity type, optionally filtered by category or chain. Returns entities with their letter grade + composite score, best-rated first. Example: list_ratings({ entity_type: 'protocol', category: 'lending' }).
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Optional chain filter by chain slug, e.g. 'ethereum' or 'base'. | |
| limit | No | Max results (default 25, cap 50). | |
| category | No | Optional category filter, lowercase, e.g. 'lending'. | |
| entity_type | Yes | The kind of entity to browse: protocol, chain, token, oracle, vault, organisation, or bridge. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses that results are sorted best-first and include letter grade and composite score. However, it does not state that the operation is read-only, idempotent, or safe, which is a gap for a browse tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences and an example), front-loaded with the main purpose, and every sentence adds information. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return format. It covers the main use case and parameters. However, it lacks mention of pagination or error handling, which would be expected for a list tool with a limit parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value with an example usage showing real parameter values and explains the return format (letter grade + composite score). This goes beyond what the schema provides, earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it browses DeFi ratings for one entity type, with optional filters. The verb 'browse' and resource are specific. However, it does not explicitly differentiate from sibling tools like 'search_ratings' or 'get_rating', which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use (to browse ratings by entity type with optional filters) but provides no explicit guidance on when not to use or when to prefer alternatives. Sibling tools exist but are not mentioned for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Verdict's DeFi ratings by name or keyword across all 7 entity types (protocol, chain, token, oracle, vault, organisation, bridge). Pass entity_type to narrow the search. Returns matching entities with their letter grade + composite score. Example: search_ratings({ query: 'aave' }).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Name or keyword to search for, e.g. 'aave' or 'chainlink'. | |
| entity_type | No | Optional: restrict to one entity type. Omit to search all 7 types at once. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that it searches across all entity types, returns matching entities with grade and score, and gives an example. No hidden behaviors are expected, but it lacks details on pagination or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, followed by usage guidance and an example. Every sentence adds value and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no annotations), the description is complete: it explains what it does, how to use it, and what it returns. No gaps in information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have descriptions in the schema. The description adds an example and clarifies narrowing, but does not provide significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches Verdict's DeFi ratings by name or keyword across all 7 entity types. It also mentions narrowing by entity_type and the return format. However, it does not explicitly differentiate from sibling tools like get_rating or list_ratings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides some guidance on when to use (by keyword, optionally narrow by entity_type) but does not mention alternatives or when not to use. Sibling tools exist but are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_ratinglist_ratingssearch_ratingsScored across 3 tools
Each tool has a distinct purpose: search across types, get a specific entity, and list by type/filters. No overlap.
All three tools follow a consistent 'verb_noun' pattern: search_ratings, get_rating, list_ratings.
Three tools cover the core operations for a DeFi ratings server: search, get, and list. The number feels appropriate.
Covers search, detail retrieval, and listing. Missing features like rating history filters, but core workflows are complete.
Evidence-backed crypto due diligence with sources, freshness, and a runtime receipt on every call.
Read-only smart-contract security intelligence for autonomous agents.
Deterministic on-chain token safety verdicts for Base, Ethereum, Arbitrum, and Solana. No LLM — pure on-chain data including Clanker CREATE2 resolution, Pump.fun bonding curve detection, Raydium LP checks, and a pro tier with Farcaster social signals and holder growth velocity. Also includes /verdict/pump — a fast Pump.fun specific verdict optimised for HFT at 474ms p50, covering bonding curve SOL reserve, graduation status, and deployer age. Solana only, $0.02 USDC."
Evidence-first trust verdicts for AI-agent services — query one before you transact.
