x402-discovery-mcp

Name: x402-discovery-mcp
Author: rplryan

by rplryan

Overview Schema Source Related Servers Score Discussions Admin

Python

x402 Service Discovery MCP Server

⭐ Star to help others find this — if x402Scout has saved you time, a star helps other developers find it

The community-built Bazaar for the x402 agentic economy — a continuously growing catalog of live services with real-time quality signals, facilitator-compatibility checks, and ERC-8004 trust scoring. The discovery layer that Coinbase's own PROJECT-IDEAS.md asked the community to build.

MCP Registry Smithery Score API Status Services Indexed scout_relay x402scout CLI ScoutGate License: MIT

ScoutGate — Instant x402 API Monetization

Wrap any existing API in x402 payments in under 2 minutes — no protocol knowledge required

The x402 ecosystem's biggest friction point has been supply-side: getting an API behind x402 payments requires understanding EIP-712 headers, facilitator registration, and settlement logic. ScoutGate removes all of it.

# Register your existing API (30 seconds)
curl -X POST https://x402-scoutgate.onrender.com/register \  -H "Content-Type: application/json" \  -d '{"api_url": "https://your-api.com", "wallet_address": "0xYourWallet", "price_usd": 0.01, "name": "My API"}'
# Returns: {"proxy_url": "https://x402-scoutgate.onrender.com/api/abc123", "api_id": "abc123"}

That's it. Your API is now x402-enabled, auto-listed in x402Scout, and settling on Base mainnet in real USDC. ScoutGate handles facilitator integration, EIP-712 verification, and settlement.

Fee model: 2% per transaction (min $0.002). Live at: https://x402-scoutgate.onrender.com | Register your API

Related MCP server: Tilde x402 MCP Server

Terminal CLI — x402scout

Search the full x402 service catalog from your terminal

# Install (npm)
npm install -g x402scout

# Search
x402scout search "weather data"

# Top services by trust score
x402scout top 10

# Browse by category
x402scout browse data

# Scan a URL for x402 compliance
x402scout scan https://api.yourservice.com

# Ecosystem stats
x402scout stats

See cli/README.md for full usage.

scout_relay — Autonomous Payment Router

Route, execute, and audit x402 payments in a single call

Where the Discovery MCP finds what to call, scout_relay handles calling it — discovering the best service, making the x402 payment, retrying on failure, and returning the result. One call. Fully autonomous.

# Route an intent to the best matching x402 service
curl -X POST https://x402-scout-relay.onrender.com/route \
  -H "Content-Type: application/json" \
  -H "X-Payment: <your-x402-payment-header>" \
  -d '{"intent": "blockchain analytics for wallet 0xABC", "max_budget_usd": 0.05}'

4 MCP tools — add to any MCP client:

Tool	What It Does
`scout_route`	Discover best service for an intent + execute payment
`scout_discover`	Query the discovery catalog without executing
`scout_execute`	Execute payment to a known service URL
`scout_audit`	View spend log and agent budget status

Fee model: max($0.003, 2.5% of downstream transaction value) per routed call.

Placement bids: Providers can register routing priority bids at POST /placement/bid (x402-gated, $0.01 registration fee). Bids are used as tiebreakers after trust-score filtering — merit first, always.

Endpoint	Description
`GET /health`	Service health + version
`POST /route`	Route an intent (x402-gated)
`POST /execute`	Execute to a known URL (x402-gated)
`GET /discover`	Catalog discovery (free)
`GET /audit`	Spend log (free)
`POST /placement/bid`	Register a provider placement bid (x402-gated, $0.01)
`GET /placement/bids`	View all active placement bids (public)

Live at: https://x402-scout-relay.onrender.com

What This Is (30 seconds)

x402 is Coinbase's HTTP-native micropayment standard for the agentic web. An AI agent hits an endpoint, gets an HTTP 402 challenge, pays with USDC on Base, and receives data — no API keys, no subscriptions, pure machine-to-machine.

The problem: Hundreds of x402-payable services exist across the ecosystem. The official x402.org catalog lists names. That's it. No uptime data. No latency scores. No facilitator-compatibility flags. No trust signals. An agent has no way to know which services are actually live, trustworthy, or compatible with its payment flow.

This MCP server solves it. Connect any Claude, Cursor, or Windsurf agent directly to the x402 Service Discovery API — a continuously-updated catalog with real quality signals on every entry. Find services, check health, verify facilitator compatibility, and register new endpoints — all from inside your AI workflow.

MCP Tools (5 discovery + 4 relay = 9 total)

Discovery Tools

Tool	What It Does	Cost
`x402_discover`	Semantic search across the live catalog by keyword, category, max price	$0.010 USDC (pays via x402)
`x402_health`	Real-time uptime + latency check for any registered service	$0.001 USDC (pays via x402)
`x402_register`	Register a new x402 service (HTTPS-only, rate-limited)	Free
`x402_attest`	ERC-8004 trust score and reputation signals for a service	Free
`x402_scan`	Full x402 compliance scan: live config, trust score, mismatch detection	$0.010 USDC (pays via x402)

Relay Tools (via scout_relay)

Tool	What It Does	Cost
`scout_route`	Discover best service for an intent + execute x402 payment	max($0.003, 2.5%)
`scout_discover`	Query discovery catalog without executing	Free
`scout_execute`	Execute x402 payment to a known service URL	max($0.003, 2.5%)
`scout_audit`	View agent spend log and budget status	Free

Quickstart — 30 Seconds to Discovery

Option A: Docker (recommended)

Add to your claude_desktop_config.json, Cursor MCP settings, or Windsurf config:

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

Option B: npx (no Docker required)

{
  "mcpServers": {
    "x402-discovery": {
      "command": "npx",
      "args": ["-y", "@rplryan/x402-discovery-mcp"]
    }
  }
}

Option C: Direct API

The Discovery API is publicly accessible — no authentication required:

# Search for services
curl "https://x402scout.com/discover?query=blockchain+analytics&max_price_usd=0.01"

# Full catalog
curl "https://x402scout.com/.well-known/x402-discovery"

Why This Matters

The Discovery Gap in x402

The x402 protocol solves payment. It does not solve discovery. When hundreds of services exist but agents can't find, evaluate, or route to them intelligently, the protocol's full value is unrealized.

This project fills that gap with three layers:

Discovery — Find x402 services by capability, category, price ceiling
Quality signals — Uptime %, latency (ms), facilitator compatibility, ERC-8004 trust score
Execution — scout_relay discovers, pays, retries, and returns results autonomously

What Makes This Different from x402.org/ecosystem

Capability	x402.org/ecosystem	This Project
Service listings	✅ Names + URLs	✅ Full metadata
Uptime monitoring	❌ None	✅ Live health checks
Latency data	❌ None	✅ Per-service ms scores
Facilitator compatibility	❌ None	✅ Per-service flag
ERC-8004 trust signals	❌ None	✅ Reputation scoring
Agent-native usage prompts	❌ None	✅ `llm_usage_prompt` per service
Auto-updated catalog	❌ Manual	✅ Scans every 6 hours
MCP integration	❌ None	✅ 9 tools, registry-published
Semantic search	❌ None	✅ Keyword + category + price
Autonomous execution	❌ None	✅ scout_relay — discover + pay + retry
Agent integration hints	❌ None	✅ `howToUse` block per service — exact x402 payment steps

Live Catalog Stats

Total Services:      Live — check https://x402scout.com/catalog
Auto-scan interval:  6 hours
Scan sources:        x402.org/ecosystem, awesome-x402, GitHub search
Categories:          data, compute, agent, utility
Facilitator-compat:  Flagged per service
Trust signals:       ERC-8004 per service
Primary URL:         https://x402scout.com
Trust scores:        0-100 per service (ERC-8004 based)
Payment metadata:    x402Config (address, asset, version) per service
Router:              Live at https://x402-scout-relay.onrender.com

Catalog Sample

Category	Count	Notable Services
data	Live	CoinGecko, Einstein AI, DJD Agent Score, Ordiscan, Nansen, Zapper, AdEx AURA
utility	Live	dTelecom STT, Pinata, Tip.MD, Cybercentry, Trusta Attestation, AsterPay
compute	Live	BlockRun.AI, X402Engine, AurraCloud, AiMo, QuickSilver
agent	Live	Questflow, Ubounty, Bitte Protocol, Farnsworth, SerenaI

Example: Agent Workflow

Discovery only

# 1. Agent needs blockchain analytics under $0.01
result = x402_discover(
    query="blockchain analytics whale tracking",
    max_price_usd=0.01,
    category="data"
)
# Returns: ranked list with price, uptime %, latency, llm_usage_prompt

# 2. Scan for compliance + trust before paying
scan = x402_scan(url=result[0]["url"])

# 3. Check live health before committing
health = x402_health(url=result[0]["url"])

Full autonomous execution via scout_relay

# One call — discovery + payment + retry handled automatically
result = scout_route(
    intent="blockchain analytics for wallet 0xABC",
    max_budget_usd=0.05
)
# Returns: {result: {...}, provider: "...", fee_usd: 0.003, trust_score: 82}

Payments use EIP-712 signed TransferWithAuthorization via the x402 HTTP protocol — not direct ERC-20 transfer. Signature verified server-side; on-chain settlement via receiveWithAuthorization.

CDP Builder Grant Context

This project is a direct implementation of two items from Coinbase's own public roadmap:

From PROJECT-IDEAS.md in coinbase/x402:

"Dynamic Endpoint Shopper — An agent that discovers an MCP registry, pays for access, chains results from multiple services"

From the CDP x402 facilitator roadmap:

"A discovery layer for buyers (human and agents) to find available services (Bazaar)"

We built the community Bazaar. It's live. It has quality signals the official page doesn't. And it uses x402 payments itself — x402_discover costs $0.010 USDC, paid via the protocol it serves. scout_relay extends this: it routes and executes x402 payments autonomously, charging its own x402 fee for the service.

What We've Shipped (11 days)

Deliverable	Status
x402 Service Discovery API v3.7.0	✅ Live on Render
x402 Discovery MCP Server	✅ Docker + GitHub MCP Registry
x402 RouteNet v1.0.0 (smart routing)	✅ Live on Render
x402 Payment Harness v1.0.0 (EOA testing)	✅ PyPI `pip install x402-payment-harness`
Continuously growing catalog with quality signals	✅ Auto-updating every 6h
ERC-8004 trust layer	✅ Per-service trust scoring
Facilitator compatibility layer	✅ Pre-payment compatibility check
Full HTTP 402 protocol flow proven on Base	✅ EIP-712 sign → X-PAYMENT header → 200
x402scout CLI v1.0.0	✅ `npm install -g x402scout`
scout_relay v2.1.0 (payment router)	✅ Live on Render
Provider placement bids (POST /placement/bid)	✅ Live — x402-gated, self-serve
x402Config payment metadata in catalog	✅ payment_address, asset_contract, x402Version per service
`/scan` compliance endpoint (paid)	✅ Live — compliance grade, mismatch detection, trust score
`howToUse` integration blocks	✅ Per-service exact x402 payment steps in /discover results
Landing page (x402scout.com)	✅ NVG green design, live stats, code snippets
Endpoint security hardening	✅ SSRF guard, rate limiting, HTTPS-only on /register
Smithery score	✅ 100/100
GitHub MCP Registry	✅ Published: `io.github.rplryan/x402-discovery-mcp`
ScoutGate v1.0.0 (x402 API monetization gateway)	✅ Live on Render — wrap any API in x402 payments in 30 seconds

Architecture

┌─────────────────────────────────────────────────────┐
│              AI Agent (Claude / Cursor / Windsurf)  │
│                                                     │
│  x402_discover → x402_health → x402_attest         │
│  x402_scan → x402_register → x402_health           │
│                                                     │
│  scout_route → scout_execute → scout_audit          │
└──────────┬──────────────────────────┬───────────────┘
           │ MCP (stdio/Docker)       │ REST / MCP
┌──────────▼──────────┐    ┌──────────▼──────────────┐
│  x402 Discovery     │    │  scout_relay v2.1.0      │
│  MCP Server         │    │  x402-scout-relay        │
│  ghcr.io/rplryan/   │    │  .onrender.com           │
│  x402-discovery-mcp │    │  Fee: max($0.003, 2.5%)  │
└──────────┬──────────┘    └──────────┬───────────────┘
           │ HTTPS                    │ HTTPS
           └──────────────┬───────────┘
                          │
┌─────────────────────────▼───────────────────────────┐
│     x402 Discovery API (Render, v3.7.0)             │
│     https://x402scout.com                          │
│                                                     │
│  • Growing catalog  • Auto-scan every 6h            │
│  • Health checks  • Facilitator compat flags        │
│  • ERC-8004 trust • llm_usage_prompt per service    │
└─────────────────────────────────────────────────────┘

Project	Description	Status
x402 Discovery API	REST backend powering this MCP server	Live v3.7.0
scout_relay	Autonomous x402 payment router — discover + execute + audit in one call	Live v2.1.0
x402 RouteNet	Smart routing across discovered services	Live v1.0.0
x402 Payment Harness	EOA-based Python library + CLI for x402 payment testing	PyPI v1.0.0
ScoutGate	Wrap any existing API in x402 payments in 30 seconds — no protocol knowledge required	Live v1.0.0

Register Your Service

If you're building an x402-enabled service, add it to the catalog:

curl -X POST https://x402scout.com/register \
  -H "Content-Type: application/json" \
  -d '{
    "name": "My Service",
    "url": "https://myservice.example.com/api",
    "price_usd": 0.010,
    "category": "data",
    "description": "What your service does",
    "network": "base-mainnet"
  }'

Or use the x402_register MCP tool from inside Claude/Cursor/Windsurf.

Want routing priority? Register a placement bid at POST https://x402-scout-relay.onrender.com/placement/bid (x402-gated, $0.01 registration fee). Your service gets weighted as a tiebreaker after trust-score filtering — merit first, always.

License

MIT

Built on Coinbase x402 protocol | Base Network | ERC-8004 | Model Context Protocol

Available Tools

5 tools

x402_attestA

Read-onlyIdempotent

Fetch a signed discovery attestation (EdDSA JWT) for a registered x402 service. The attestation contains cryptographically signed quality measurements: uptime %, avg latency, health status, and facilitator compatibility. Verify the signature offline using the JWKS at GET /jwks. Part of the ERC-8004 coldStartSignals spec (coinbase/x402#1375).

ParametersJSON Schema

Name	Required	Description	Default
`service_id`	Yes
`raw`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already provide readOnlyHint=true and destructiveHint=false. Description adds valuable context: the attestation is a JWT with specific fields (uptime, latency, health, compatibility) and references offline verification via JWKS. No contradictions with annotations.

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?

Three sentences packing essential info (purpose, content, verification, spec reference). Front-loaded with verb 'Fetch' and noun. Could be slightly improved by mentioning the raw parameter briefly.

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?

Given annotations and output schema exist, description covers verification and content but omits explanation of the raw parameter and prerequisites for service_id. Incomplete for a tool with 0% schema description coverage.

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%, yet the description does not clarify the semantics of the two parameters (service_id and raw). It fails to add meaning beyond the schema's basic type and required status.

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?

Description clearly states the tool fetches a signed discovery attestation (EdDSA JWT) for a registered x402 service. It specifics the content (quality measurements) and verification method, distinguishing it from sibling tools like x402_browse or x402_register.

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 for obtaining attestations for registered services but does not explicitly state when to use vs alternatives, nor does it provide conditions or exclusions.

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

x402_browseA

Read-onlyIdempotent

Browse all registered x402 services, optionally filtered by category. Free, no payment required. Returns full catalog with quality signals.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Adds 'Free, no payment required' and 'Returns full catalog with quality signals' beyond annotations (readOnly, destructive, idempotent, openWorld). Provides cost model and output characteristics.

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?

Three sentences: action, cost, output. Efficient and front-loaded with essential information. No wasted words.

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?

With one optional parameter and an existing output schema, the description fully covers purpose, cost, and output nature, leaving no significant gaps.

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?

Single parameter 'category' has no schema description (0% coverage). Description clarifies it as optional filter, adding meaning beyond schema's minimal title.

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?

Description clearly states verb 'browse', resource 'registered x402 services', and optional filter by category. Distinguishes from sibling tools like x402_attest, x402_discover, etc.

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?

States 'Free, no payment required' as a usage condition. Implicitly context for browsing vs. other operations, but no explicit when-not or alternatives beyond tool names.

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

x402_discoverA

Read-onlyIdempotent

Find x402-payable services by capability or keyword. Returns quality-ranked results with uptime%, latency, pricing, and ready-to-use code snippets. This tool itself costs $0.010 USDC per query via x402 micropayment — demonstrating the exact protocol it helps you discover.

ParametersJSON Schema

Name	Required	Default
`query`	Yes
`capability`	No
`max_price_usd`	No
`min_quality`	No	unverified

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already indicate read-only, non-destructive, idempotent, and open-world behavior. The description adds transparency by disclosing the $0.010 USDC cost per query, which is a behavioral trait not captured in annotations.

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, each adding value, with front-loaded purpose and key details. No wasted words.

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?

Description covers return content (quality-ranked results, uptime%, latency, pricing, code snippets) and cost. With annotations and output schema likely providing further detail, it is mostly complete, though error handling and pagination are not mentioned.

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 coverage is 0% with no parameter descriptions. The description mentions 'capability or keyword' hinting at query and capability params, but fails to explain max_price_usd and min_quality. Insufficient detail for a 4-parameter tool.

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 clearly states the tool finds x402-payable services by capability or keyword, specifying the resource and action. It distinguishes itself from sibling tools with different purposes like attest, browse, health, and register.

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 for discovering services but does not explicitly state when to use this tool over alternatives or provide exclusions. No guidance on prerequisites or when not to use it.

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

x402_healthB

Read-onlyIdempotent

Check real-time health status of any registered x402 service. Free, no payment required.

ParametersJSON Schema

Name	Required	Description	Default
`service_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already declare readOnly and idempotent hints. The description adds 'real-time' and 'no payment required,' which are minor behavioral clarifications. It does not disclose any additional traits like rate limits or result details.

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 only two sentences, each adding distinct value: the first states the primary function, the second clarifies cost. No unnecessary words or repetition.

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

Completeness2/5

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

Despite the presence of an output schema, the description does not mention the parameter or what the health status response contains. For a tool with one required parameter and no schema description, the description should provide more context to be complete.

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

Parameters1/5

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

The input schema has 0% description coverage for the single parameter 'service_id,' and the description does not explain its meaning or format. The parameter's purpose is left entirely to inference from the tool name.

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 clearly states the tool checks real-time health status of x402 services, which is a specific verb and resource. It distinguishes from sibling tools like x402_register or x402_browse which have different purposes.

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 mentions 'Free, no payment required,' hinting that other tools may incur costs, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. The purpose is implicit but not directive.

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

x402_registerA

Register a new x402 service with the discovery index. Free. Your service will appear in the catalog and be discoverable by agents.

ParametersJSON Schema

Name	Required	Default
`name`	Yes
`endpoint_url`	Yes
`description`	Yes
`price_per_call`	Yes
`capability_tags`	Yes
`wallet_address`	Yes
`network`	No	base

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=false and openWorldHint=true, which align with the 'Register' action. The description adds useful behavioral context: the service will appear in the catalog and be discoverable, and it is free. No contradictions. It does not detail side effects beyond creation, but the disclosure is adequate for the tool's simplicity.

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 concise sentences, front-loaded with the action verb 'Register'. No redundant or filler content; every sentence adds distinct value.

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?

While the outcome (service appears in catalog) is mentioned, the description omits details about the response (though an output schema exists), required prerequisites, or parameter constraints. Given 7 parameters and a creation operation, the description is minimally complete but leaves gaps.

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%, and the description provides no information about any of the 7 parameters (name, endpoint_url, etc.). The description entirely fails to add meaning beyond the schema, leaving the agent to infer from parameter names alone.

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 clearly states 'Register a new x402 service with the discovery index,' specifying the exact verb and resource. It also distinguishes itself from sibling tools like x402_browse or x402_discover by focusing on registration.

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?

The description provides context on when to use the tool ('Register a new x402 service') and states that it is free, implying cost is not a concern. However, it does not explicitly mention when not to use it or suggest alternatives, lacking exclusionary guidance.

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. Dates show when Glama detected each change.

5 tool updatesv0.1.0Apr 6, 2026
- First observedx402_attest
- First observedx402_browse
- First observedx402_discover
- First observedx402_health
- First observedx402_register

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: attest fetches signed attestations, browse lists services, discover searches with payments, health checks status, and register adds new services. The descriptions explicitly differentiate their functions, eliminating any ambiguity.

Naming Consistency5/5

All tools follow a consistent 'x402_' prefix with descriptive suffixes (attest, browse, discover, health, register), using snake_case uniformly. This pattern is predictable and enhances readability across the set.

Tool Count5/5

With 5 tools, this server is well-scoped for its discovery and registration domain. Each tool serves a specific, non-redundant function, making the count appropriate and manageable for the intended purpose.

Completeness5/5

The tool set provides complete coverage for x402 service discovery and management: browse for listing, discover for searching, health for monitoring, register for adding services, and attest for verification. There are no apparent gaps, supporting full lifecycle operations.

Maintenance

ActivityInactive

ResponsivenessWithin a week

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

x402-list-mcp A
com.x402-list
Find and vet x402 payment APIs before your agent pays one: uptime, price, on-chain volume.
Developer Tools
7230
aegis B
com.borisinc
Trust layer for the x402 economy - check any service before you pay. Scores, discovery, routing.
Payments & Billing E-commerce & Retail Agent Orchestration
72
blindoracleOAuth
io.github.craigmbrown
The trust layer for the x402 agent economy: verifiable agent identity, payment & audit.
Blockchain Finance Autonomous Agents
2
XGuard — Payment Decision & Discovery A
io.github.moelayyan90
Payment decisions, durable evidence, x402 resource discovery and live gateway status for AI agents.
Autonomous Agents Payments & Billing App Automation
1

Related MCP Servers

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 a month ago (2026-08-04 12:33 UTC)
MIT
Tilde x402 MCP Server
Blockchain Payments & Billing Search
Gordian-Labs
A
license
Not graded
quality
D
maintenance
Enables AI agents to discover and pay for x402-enabled services using natural language, with multi-chain support for Solana and EVM payments.
Updated 10 months ago (2025-11-13 06:10 UTC)
5
1
MIT
x402-list-mcp
Payments & Billing Cryptocurrency
mcccsm
A
license
A
quality
B
maintenance
Enables AI agents to discover x402 payment services and query on-chain-verified settlement volumes per facilitator through the Model Context Protocol.
Updated 7 days ago (2026-09-01 19:30 UTC)
7
294
30
MIT
@hpp-io/x402-mcp-bridgeofficial
Cryptocurrency Autonomous Agents Payments & Billing
hpp-io
A
license
Not graded
quality
B
maintenance
Enables AI agents to autonomously pay for and discover services using HPP USDC.e over the x402 protocol, without API keys or manual signing.
Updated 20 days ago (2026-08-20 01:23 UTC)
148
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rplryan/x402-discovery-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

x402 Service Discovery MCP Server

ScoutGate — Instant x402 API Monetization

Terminal CLI — x402scout

scout_relay — Autonomous Payment Router

What This Is (30 seconds)

MCP Tools (5 discovery + 4 relay = 9 total)

Discovery Tools

Relay Tools (via scout_relay)

Quickstart — 30 Seconds to Discovery

Option A: Docker (recommended)

Option B: npx (no Docker required)

Option C: Direct API

Why This Matters

The Discovery Gap in x402

What Makes This Different from x402.org/ecosystem

Live Catalog Stats

Catalog Sample

Example: Agent Workflow

Discovery only

Full autonomous execution via scout_relay

CDP Builder Grant Context

What We've Shipped (11 days)

Architecture

Related Projects

Register Your Service

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

@hpp-io/x402-mcp-bridgeofficial

Latest Blog Posts

MCP directory API