What can you do with this server?

This read-only MCP server helps agents discover, rank, and route to live x402 pay-per-call endpoints without holding keys or making payments. * Search live x402 endpoints by text, chain, category, max price, minimum score, sort order, and limit. * Route a request to the single best-scored matching endpoint, returning target URL, method, price, 1% router fee, and total without paying or calling it. * Retrieve registry statistics such as total/live counts, live counts by chain, median price, last crawl time, and router health. * Get the x402 payment requirements for the paid route without paying.

Which integrations are available for this server?

Supports discovering and routing x402 pay-per-call endpoints on Solana, including filtering endpoints by the Solana chain and returning payment requirements that accept Solana USDC for paid route access.

x402 Router

by camerxnduff

Overview Schema Source Related Servers Discussions Admin

Python

Remote

x402 Router: MCP server + free API to find and pay the right x402 endpoint

MCP x402 Chains USDC License: MIT Docker build

20,700+ LIVE x402 pay-per-call endpoints across 3,100+ services, probed every 3 hours and scored 0-100 for reliability. Agents don't need to know which x402 API is up. Ask the router.

Keywords: x402, MCP, MCP server, AI agents, agent payments, pay-per-call APIs, USDC, Base, Solana, x402 discovery, x402 router, x402 registry, HTTP 402.

Live router: https://router-production-ab89.up.railway.app (OpenAPI: /openapi.json · x402 discovery: /.well-known/x402 · health: /health)
Dashboard / registry: https://dashboard-production-4344.up.railway.app
For LLMs: https://dashboard-production-4344.up.railway.app/llms.txt

Quick start (MCP, 30 seconds)

The server is read-only: it holds no keys and never pays. It exposes four tools: search_x402_endpoints, route_x402_request, get_registry_stats, get_paid_route_requirements.

Option A: uvx (no clone, no PyPI needed)

Claude Desktop (claude_desktop_config.json) or Cursor (~/.cursor/mcp.json):

{
  "mcpServers": {
    "x402-router": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/camerxnduff/x402-router-mcp#subdirectory=mcp-server", "x402-router-mcp"]
    }
  }
}

Option B: Docker

{
  "mcpServers": {
    "x402-router": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "ghcr.io/camerxnduff/x402-router-mcp:latest"]
    }
  }
}

Or build it yourself: docker build -t x402-router-mcp . and use x402-router-mcp as the image name.

Option C: from source

git clone https://github.com/camerxnduff/x402-router-mcp
cd x402-router-mcp/mcp-server
python3 -m venv .venv && . .venv/bin/activate
pip install -r requirements.txt
python test_client.py   # calls the live router, read-only

{"mcpServers":{"x402-router":{"command":"/abs/path/x402-router-mcp/mcp-server/.venv/bin/python","args":["/abs/path/x402-router-mcp/mcp-server/server.py"]}}}

Streamable HTTP: python server.py --http 8000 serves http://localhost:8000/mcp. Env overrides: X402_ROUTER_URL, X402_DASHBOARD_URL.

Related MCP server: x402-discovery

Try it with no install (curl)

# best live Base endpoint for a category (free preview)
curl -s -X POST https://router-production-ab89.up.railway.app/route \
  -H 'content-type: application/json' -d '{"category":"Finance","chain":"Base"}'

# search the registry
curl -s 'https://dashboard-production-4344.up.railway.app/api/endpoints?q=weather&chain=Base&limit=5'

Why

Thousands of x402 endpoints exist, and many are dead, misconfigured or slow. The router probes every one, checks that its 402 body is valid (version, scheme, network, payTo, asset, amount), and ranks by uptime and latency, so an agent gets a working endpoint with a known price.

HTTP API

Endpoint	What
`GET /api/endpoints?q=&chain=&category=&max_price=&min_score=&sort=&limit=` (dashboard)	Search LIVE endpoints, best first
`GET /api/summary` (dashboard)	Counts by chain, category, source
`GET /api/registry` (dashboard)	Full registry (gzip)
`POST /route` (router)	Best single match, free preview
`POST /route/paid` (router)	Same result, x402-paid: $0.01 USDC on Base (Solana accepted)

Examples: examples/ (curl, Python, TypeScript).

Payments

/route/paid speaks x402 v2: Base USDC first, Solana USDC as fallback, settled through the PayAI facilitator. The router adds a 1% routing fee on routed calls. The MCP server itself never pays; your agent's x402 client does.

License

MIT

Available Tools

4 tools

get_paid_route_requirementsA

Return the x402 payment requirements of the paid route (/route/paid) without paying.

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden. It does disclose the most important trait - that this call does not incur payment - and it hardcodes the route path, but says nothing about auth requirements, rate limits, or what happens if the route is unregistered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with zero waste, leading with the return value and the non-payment guarantee. Nothing could be removed without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-param probe tool with no output schema, the agent still lacks the shape of the returned requirements (fields, currency/amount format) and whether the endpoint is public. Adequate but leaves notable gaps given nothing else documents the response.

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?

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The fixed '/route/paid' target is stated in the text, reinforcing that no input is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Return') and resource ('x402 payment requirements of the paid route /route/paid'), and the 'without paying' clause implicitly separates it from route_x402_request. It never names the siblings, so differentiation is inferred rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'without paying' hints at inspecting requirements before committing to a paid call, which implies a workflow position relative to route_x402_request. But there is no explicit when-to-use/when-not statement or named alternative, so the guidance is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_registry_statsA

Registry summary: total/LIVE counts, LIVE by chain, median price, last crawl time, router health.

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. The name and summary imply a read-only stats operation, and 'last crawl time' conveys freshness, but it does not explicitly state side effects, auth needs, caching, 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence listing the returned metrics with no wasted wording. It is appropriately sized for a zero-parameter summary tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple no-parameter stats tool with no output schema, the description sufficiently enumerates what will be returned. It could be stronger by explicitly confirming read-only behavior and freshness semantics.

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?

There are zero parameters, so the baseline is 4 under the rubric. The description adds value by enumerating the kinds of statistics returned, though no parameter semantics are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource as a registry summary and enumerates the specific metrics returned: total/LIVE counts, LIVE by chain, median price, last crawl time, and router health. It clearly differs from the search/route/requirements siblings, though it does not explicitly name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'Registry summary': call this when aggregate registry statistics are needed. It does not state when not to use it or compare it with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

route_x402_requestA

Ask the x402 Router for the single best-scored LIVE endpoint matching filters (free POST /route). Returns target URL, method, price, 1% router fee and total. Does not pay or call the target.

Name	Required	Description	Default
`q`	No
`agent`	No
`chain`	No
`category`	No
`max_price`	No

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden and does well by disclosing that the route call is free, that it returns target URL, method, price, router fee, and total, and that it does not pay or call the target. It leaves out auth/rate-limit behavior, so it is strong but not complete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two tight sentences, front-loads the core action, and then adds the return shape and the key non-action boundary. Every sentence provides useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the return fields and the important fact that it does not execute payment or call the target, which helps compensate for the lack of an output schema. However, for a tool with five entirely undocumented optional parameters, it is not complete enough on input semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for five parameters, so the description needs to compensate. It only says results are 'matching filters' and does not explain what q, agent, chain, category, or max_price mean or how they affect routing.

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?

The description states a specific operation: asking the x402 Router for the single best-scored LIVE endpoint matching filters. The 'single best-scored' framing distinguishes it from the sibling search_x402_endpoints tool, which implies a broader search/list operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by saying this returns a routing recommendation and explicitly notes it does not pay or call the target. However, it does not explicitly state when to choose this over search_x402_endpoints or get_paid_route_requirements, nor does it name alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_x402_endpointsA

Search LIVE x402 (HTTP 402 pay-per-call) endpoints. Filters: q (text), chain (Base, Solana...), category, max_price (USDC), min_score (0-100), sort (score|price|latency|newest), limit (1-50).

Name	Required	Default
`q`	No
`sort`	No	score
`chain`	No
`limit`	No
`category`	No
`max_price`	No
`min_score`	No

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses scope ('LIVE' endpoints only) and the semantics of sort/price/score values, but says nothing about pagination, result ordering guarantees, auth requirements, or what the response contains — gaps that matter for a 7-param discovery tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, then a dense enumerated filter list. No filler words and no redundancy with the schema's parameter names alone.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all seven optional filters with units, ranges, and enum values, which is most of what an agent needs to construct a call. Missing pieces are behavioral rather than parametric: no indication of result contents (no output schema exists to cover this) or pagination behavior.

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%, so the description must compensate and largely does: it gives the unit for max_price (USDC), the valid range for min_score (0-100) and limit (1-50), and the allowed sort values (score|price|latency|newest), plus an example chain set. Only defaults (limit=10, sort=score) are left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Search LIVE x402 (HTTP 402 pay-per-call) endpoints' — and clarifies the domain jargon (HTTP 402, pay-per-call) an agent may not know. It does not explicitly contrast with the sibling route_x402_request, so sibling differentiation is inferred rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The word 'LIVE' and the filter set imply 'use this to discover callable endpoints,' but there is no explicit when-to-use, no statement of what to do next (e.g. call get_paid_route_requirements before routing), and no named alternative. Usage is only implied.

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.

4 tool updatesv0.1.0Oct 25, 2026
- First observedget_paid_route_requirements
- First observedget_registry_stats
- First observedroute_x402_request
- First observedsearch_x402_endpoints

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-10-25 08:20 across 4 tools

Disambiguation4/5

search vs route is clearly differentiated (list vs best single match), and stats is distinct. get_paid_route_requirements overlaps somewhat with the routing tools since it examines the paid route without invoking it, but the description adequately clarifies it.

Naming Consistency5/5

All four tools use a consistent snake_case verb_noun pattern (search_, route_, get_, get_). The convention is uniform and predictable.

Tool Count5/5

Four tools is well-scoped for a small router/registry service; each tool (search, route, stats, payment requirements) covers a distinct facet with no filler.

Completeness3/5

Discovery and routing are covered, but there is no tool to actually invoke or pay for an endpoint—route_x402_request explicitly does not pay or call the target, and get_paid_route_requirements only returns requirements. The paid flow has a dead end within the surface.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

PayAPI Market A
market.payapi
Search settlement-verified x402 APIs for free. Pay providers in USDC on Base, Solana or Algorand.
Blockchain Web3 & Decentralized Tech Payments & Billing
41
https://payapi.market/mcp
Pocket Network Agentic Marketplace A
network.pocket
Search and call pay-per-request data services, paying in USDC on Base with x402.
Cryptocurrency Payments & Billing Web3 & Decentralized Tech
31
https://agent.pocket.network/mcp
AgentPay — Pay-per-call AI Microservices B
help.agentpay
34 pay-per-call AI and data tools over x402; USDC on Base; no API keys.
AI & Machine Learning Payments & Billing Blockchain
341
https://agentpay.help/mcp
Ontario Protocol B
com.ontarioprotocol
Find live x402 APIs for any task (0.005 USDC, no match no charge); Base balance, tx and gas reads.
Web3 & Decentralized Tech Payments & Billing Security
201
https://ontarioprotocol.com/mcp

Related MCP Servers

x402search
Search Blockchain Web3 & Decentralized Tech
x402-index
A
license
A
quality
F
maintenance
Search 14,000+ x402-enabled HTTP APIs by keyword. Agents pay $0.01 USDC per search via x402 micropayments on Base mainnet — no API keys or accounts required.
Updated 7 months ago (2026-03-29 07:38 UTC)
1
24 npm
3
MIT
x402-discovery
Blockchain Cryptocurrency Autonomous Agents
rplryan
A
license
Not graded
quality
D
maintenance
Discovers and queries x402-payable APIs at runtime — enables autonomous agents to find, evaluate, and pay for services via USDC micropayments on Base without API keys or subscriptions.
Updated 3 months ago (2026-08-04 12:33 UTC)
MIT
@1ly/mcp-serverofficial
Blockchain Cryptocurrency Payments & Billing
1lystore
A
license
Not graded
quality
F
maintenance
Enables AI agents to discover, pay for, and sell APIs using crypto on Solana and Base networks, with support for automated x402 payments.
Updated 8 months ago (2026-03-05 15:10 UTC)
97 npm
3
MIT
Base Intel Search
Search Browser Automation
jakemaxsigal-creator
A
license
Not graded
quality
D
maintenance
Pay-per-call web search for AI agents, settled in USDC on Base via the x402 protocol. No API key or subscription required; users fund a wallet and get a web_search tool.
Updated 5 months ago (2026-06-09 18:30 UTC)
8 npm
1
MIT

x402 Router: MCP server + free API to find and pay the right x402 endpoint

Quick start (MCP, 30 seconds)

Option A: uvx (no clone, no PyPI needed)

Option B: Docker

Option C: from source

Try it with no install (curl)

Why

HTTP API

Payments

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

@1ly/mcp-serverofficial