route-verdict-mcp
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., "@route-verdict-mcprun a trust and liveness check on https://api.example.com/paid"
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.
route-verdict-mcp
Standalone home: This server was split out of
QuincyGB/token-verdict-toolsso each MCP server has its own GitHub repository for directory ingestion and maintenance. The PyPI package name (route-verdict-mcp), version, and install command are unchanged.
An MCP server (stdio transport) that exposes RouteVerdict as a native tool for any MCP host — Claude Desktop, Cursor, or your own agent runtime.
RouteVerdict is a pay-per-call trust and liveness check for x402 endpoints: send any paid resource URL, get back a verdict (TRUSTED / CAUTION / AVOID), a 0–100 trust score, an itemized deduction list, a live 402 probe of the target, its published terms, discovery-schema quality, catalog presence in the CDP Bazaar and PayAI indexes, and a diff against the last check of the same URL. It costs $0.05 USDC per check on Base, paid via the x402 protocol — no accounts, no API keys; the payment is the authentication. The target endpoint is probed, never paid.
The tool
route_check — one tool, the service's real contract:
Input | Type | Notes |
| string (required) | Full URL of the x402 resource to audit |
Output is the service's check JSON: resource_url, checked_at,
verdict, score, reasons (itemized deductions), liveness,
terms, schema_quality, catalog, and diff.
Related MCP server: crosscheck
Install
pip install route-verdict-mcp
# Or from a checkout of this repository:
pip install .Requires Python ≥ 3.10. The server pins the MCP v1 SDK API
(mcp>=1.2,<2).
Configuration
All configuration is the operator's own environment — whoever runs this server supplies their own wallet. No key material ships in this package, and the package author never sees your key.
Env var | Required | Purpose |
| for paid calls | EVM private key ( |
| alternative | Path to a file containing that key. |
| no | Service base URL override (default: production). |
| no | Spend guard per call in USDC micro-units (default |
Without a signer configured the tool never pays. On a 402 it
returns the parsed challenge as a structured error — error: "payment_required" with the full accepts array (scheme, network,
asset, amount, payTo) — so the calling agent can see the price and
decide what to do, or settle the challenge with its own x402 client.
MCP host configuration
Claude Desktop (claude_desktop_config.json) — same shape for other
stdio MCP hosts:
{
"mcpServers": {
"route-verdict": {
"command": "route-verdict-mcp",
"env": {
"AGENT_PRIVATE_KEY": "0xYOUR_OWN_WALLET_KEY"
}
}
}
}From a checkout instead of an install:
{
"mcpServers": {
"route-verdict": {
"command": "python",
"args": ["-m", "route_verdict_mcp"],
"env": {
"PYTHONPATH": "/path/to/route-verdict-mcp/src",
"AGENT_KEY_FILE": "/path/to/your/agent.key"
}
}
}
}Prefer AGENT_KEY_FILE over inlining a key in a config file when your
host setup allows it.
How payment works
The client mirrors the standard x402 v2 flow (the same flow used for the fleet's own live cataloging payments):
POST /v1/checkunpaid → HTTP 402, challenge base64-encoded in thepayment-requiredheader.Pick the
exact/eip155:8453entry fromaccepts.Build an EIP-3009
TransferWithAuthorization(validAfter: 0,validBefore: now + maxTimeoutSeconds, random 32-byte nonce) and sign it as EIP-712 typed data against the USDC domain the challenge advertises (extra.name/extra.version).Retry the identical POST with the payload in the
PAYMENT-SIGNATUREheader. The service verifies and settles through its facilitator (PayAI) server-side; the settlement receipt comes back in thepayment-responseheader.
Tests
pip install -e ".[dev]"
pytestAll payments mocked (httpx MockTransport, throwaway signer generated
at test time). The 402 fixture is the real challenge captured from
production; the paid-flow test verifies the EIP-712 signature actually
recovers to the signer address.
Security notes
Your private key is read from your environment at runtime and used only to sign payment authorizations locally. It is never transmitted — the x402 payload contains a signature, not a key.
The spend guard caps any single call at the configured amount (default: exactly the $0.05 price).
Run this with a dedicated agent wallet holding only working funds, the same way you would fund any agent.
Available Tools
1 toolroute_checkA
Audit an x402 endpoint's trust and liveness before paying or relying on it.
Calls RouteVerdict (POST /v1/check, $0.05 USDC on Base via x402).
Returns a verdict (TRUSTED / CAUTION / AVOID) with a 0-100 trust
score, an itemized deduction list, a live 402 probe of the target
(the target is never paid), its published terms, discovery-schema
quality, catalog presence in the CDP Bazaar and PayAI indexes, and
a diff against the last check of the same URL.
Args:
resource_url: Full URL of the x402 resource to audit.
| Name | Required | Description | Default |
|---|---|---|---|
| resource_url | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it discloses the paid cost ($0.05 USDC on Base via x402), the underlying endpoint and method, and the crucial safety fact that the target endpoint is probed with a live 402 but never paid. It also describes the diff-against-last-check behavior, which an agent could not infer from the schema.
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?
Front-loaded with the purpose, then the cost/mechanics, then the return payload, then the single argument — a sensible ordering with no filler. The return-value enumeration is dense and somewhat overlong given an output schema already exists, but every clause is informative rather than redundant.
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?
An output schema exists, so return semantics needn't be spelled out, yet the description still summarizes the verdict categories and score, which helps an agent decide downstream actions. Combined with disclosed pricing, probe safety, and the single required argument, nothing needed to invoke the tool correctly is missing.
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 0% and the single property has no description, so the description must compensate; it explains the parameter as the 'Full URL of the x402 resource to audit,' which clarifies both format (full URL) and what must be supplied (an x402 resource). It does not state format constraints, schemes, or error behavior for malformed URLs, keeping it from a 5.
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?
Opens with a specific verb+resource+scope: 'Audit an x402 endpoint's trust and liveness.' It names the actual backend call (RouteVerdict, POST /v1/check) and the deliverable (a TRUSTED/CAUTION/AVOID verdict), so an agent knows exactly what it gets. No siblings exist that it needs to be distinguished from.
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?
'before paying or relying on it' gives a clear triggering condition for the tool. There are no sibling tools to route against, so no alternatives or exclusions are needed, but it stops short of stating when NOT to run it (e.g. non-x402 URLs, already-verified endpoints in the same session).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.1- First observed
route_check
TDQS
Scored across 1 tool
With a single tool there is no possibility of confusion or misselection. The purpose (audit an x402 endpoint before paying) is clearly articulated and distinct from anything else in the surface.
The lone tool, route_check, follows a clean verb_noun (domain_verb) pattern that is readable and predictable. There are no competing conventions to clash with.
One tool is thin for a server, even a narrowly scoped one; it maps to a single paid endpoint, so a minimal surface is defensible, but agents have no complementary operations (e.g. batch check, fetch cached verdict without paying) to work with.
The tool returns a rich, self-contained result (verdict, score, deductions, live probe, terms, catalog presence, diff vs. last check), which covers the core audit workflow well. Minor gaps exist: no way to retrieve a prior verdict without a new paid call, and no batch or list operations.
Maintenance
Related MCP Connectors
Audits any remote agent or MCP URL for JSON-RPC compliance, latency SLA, OpenAPI schema, and HTTP.
Scan any website or MCP server for agent-trust-readiness; returns a signed, verifiable scorecard.
Paid website audits for agents: flat JSON, HTML report, deep audit. USDC via x402.
Audits any URL for HTTP 402 x402 V2 compliance, PAYMENT-REQUIRED headers, Bazaar schema, and MCP.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to run full on-page SEO audits for any URL or up to 10 URLs at once, returning 0-100 scores, meta tag and heading checks, schema/image/link analysis, load time, and prioritized fixes via pay-per-call x402 micropayments.MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to obtain an independent review of their drafts, returning a pass/fail verdict with specific issues and suggested fixes, plus a signed receipt. Payments are made per check over x402, with no account or API key needed.MIT
- AlicenseNot gradedqualityCmaintenanceEnables auditing any URL for AEO and AI-search readiness, including direct-answer citability, JSON-LD validity, llms.txt compliance, E-E-A-T signals, agentic crawlability, citation simulation, and competitor score comparisons.224 npmMIT
- AlicenseNot gradedqualityCmaintenanceEnables agents to submit a storefront URL and receive an A–F conversion-readiness grade across 20 weighted checks, including specific failing checks. Calls are paid per use in USDC via x402, requiring no accounts or API keys.MIT