Skip to main content
Glama
QuincyGB

route-verdict-mcp

route-verdict-mcp

Standalone home: This server was split out of QuincyGB/token-verdict-tools so 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

resource_url

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

AGENT_PRIVATE_KEY

for paid calls

EVM private key (0x...) of a wallet holding USDC on Base. Used locally to sign the x402 EIP-3009 authorization.

AGENT_KEY_FILE

alternative

Path to a file containing that key.

ROUTE_VERDICT_URL

no

Service base URL override (default: production).

ROUTE_VERDICT_MAX_AMOUNT_UNITS

no

Spend guard per call in USDC micro-units (default 50000 = $0.05, the known price). The client refuses to sign anything priced above it.

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):

  1. POST /v1/check unpaid → HTTP 402, challenge base64-encoded in the payment-required header.

  2. Pick the exact / eip155:8453 entry from accepts.

  3. 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).

  4. Retry the identical POST with the payload in the PAYMENT-SIGNATURE header. The service verifies and settles through its facilitator (PayAI) server-side; the settlement receipt comes back in the payment-response header.

Tests

pip install -e ".[dev]"
pytest

All 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 tool
route_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.
NameRequiredDescriptionDefault
resource_urlYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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. 1 tool updatev0.1.1
    • First observedroute_check

TDQS

A4.5/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count3/5

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.

Completeness4/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables 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
  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables 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
  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables 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 npm
    MIT