x402-list-mcp
Server Details
x402-list directory MCP: services, facilitator volume, ranked picks, paid assessments.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- mcccsm/x402-list-mcp
- GitHub Stars
- 0
- Server Listing
- x402-list-mcp
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 6 of 6 tools scored.
Each tool targets a distinct operation on the service directory: searching, health checking, recommendation, paid assessment, detailed retrieval, and facilitator analytics. There is minimal overlap; even 'find_best_service' and 'assess_services' differ in mechanism (free vs. paid AI assessment).
All tool names follow a consistent verb_noun pattern with underscores, using clear verbs like 'search', 'get', 'check', 'find', 'assess'. The naming is predictable and easy to navigate, with no mixed conventions.
With 6 tools, the server covers the main functionalities of a service directory without being too sparse or bloated. Each tool serves a clear purpose and earns its place.
The set covers discovery, health monitoring, recommendations, detailed inspection, and paid assessments. A minor gap is the lack of an explicit tool to list available categories or networks, but these are implicitly available via search filters, so the surface is nearly complete.
Available Tools
6 toolsassess_servicesAInspect
Run a fresh, PAID AI assessment comparing a shortlist of already-listed x402 services for a stated need. It charges a one-time $0.25 USDC on Base (x402) for the fresh reasoning only; reading an already-computed assessment stays free via get_service. This tool is a pure pass-through: it never holds keys, never signs, and never settles. Call it once WITHOUT payment_signature_b64 to receive the x402 payment challenge (accepts[], amount, payTo, and a base64 PAYMENT-REQUIRED header) verbatim; sign accepts[0] client-side with your own wallet; then call again with the SAME question and services plus payment_signature_b64 to receive the assessment report and a base64 PAYMENT-RESPONSE settlement receipt. Optionally include a probe target as probe { slug, endpoint_path? } to also test one listed service live: when the server has live probing armed, after the fresh reasoning it makes a real x402 payment to that endpoint and analyzes what it returns, and the challenge is then priced at $0.25 plus that endpoint price X (probe fees are non-refundable regardless of outcome); the report then carries a probe_report block with a verdict and truncated extracts, never the verbatim third-party response, and when live probing is not armed the probe is ignored. If the fresh run cannot be produced the server answers before settling, so the caller is never charged, and there is no refund. Prices are US dollars.
| Name | Required | Description | Default |
|---|---|---|---|
| probe | No | Optional live-probe request: pay one listed service for real and analyze what it returns. When the server has probing armed the price becomes $0.25 plus that endpoint price X (non-refundable); the report gains a probe_report block with a verdict and truncated extracts, never the verbatim third-party body. Ignored when probing is not armed. | |
| question | Yes | The need to assess the shortlist against (1 to 1000 characters). | |
| services | Yes | Service slugs to compare for the need (1 to 8; find them with search_x402_services or find_best_service). | |
| payment_signature_b64 | No | Base64 PAYMENT-SIGNATURE for the x402 payment, produced by signing the accepts[0] challenge client-side. Omit on the first call to receive the challenge; set it on the retry to run the paid assessment. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description covers payment ($0.25 USDC), pass-through nature (no key holding), two-step process, probe behavior, no charge if run fails, and non-refundable probe fees. Highly transparent.
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?
Long but well-structured: purpose, payment details, two-call procedure, probe, no-charge policy. Every sentence adds value, could be slightly more concise.
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?
Comprehensive for a complex tool with payment and probe. Covers workflow, edge cases, and result summary. Lacks output schema but describes report contents briefly.
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 covers all 4 parameters with descriptions (100% coverage). Description adds context on payment flow and probe usage, enriching beyond 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?
Clearly states it runs a fresh paid AI assessment comparing listed services. Distinguishes from siblings like get_service (free) and search_x402_services (finding services).
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?
Explains the two-call workflow (first without payment signature to get challenge, then with to run assessment) and optional probe. Does not explicitly state when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_healthAInspect
Check live health of x402 services. With no slug, returns a directory-wide snapshot (counts of online/degraded/offline/unknown plus per-service status). With a slug, returns that service's status, uptime windows, response time, consecutive failures, and recent daily uptime snapshots. No money fields.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Service slug for a single-service health report. Omit for the whole directory. | |
| uptime_period | No | Daily uptime snapshot window for single-service mode. | 30d |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool is read-only (checking live health), returns per-service status, uptime windows, response time, consecutive failures, and daily snapshots. It also notes 'No money fields'. Missing details like auth requirements or rate limits, but these are less critical for a health check.
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?
Three sentences, front-loaded with purpose, each sentence adds value. No redundant 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?
For a relatively simple tool with 2 params and no output schema, the description fully covers both modes, returned fields, and constraints. Missing error handling details but acceptable for a health check.
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 the description adds significant meaning: it explains the effect of slug (directory vs single service) and uptime_period default and purpose. It also adds context like 'No money fields', which is not in 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 the tool checks live health of x402 services, distinguishing between directory-wide snapshot (no slug) and single-service detail (with slug). It specifies returned fields (status, uptime, response time, failures) and explicitly mentions 'No money fields', differentiating from siblings like get_service or find_best_service.
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 provides clear context for when to use without slug (directory snapshot) vs with slug (single service details). However, it does not explicitly mention alternatives among sibling tools or specify when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_best_serviceAInspect
Recommend the best x402 service(s) for a need. Ranked mostly on per-service reliability (live status, verification, uptime, response time), x402 compliance, and price (USD), filtered by category and network, with a SMALL (~10%) weight on on-chain traction: settlement volume, transaction count, and unique buyers measured per service over its known payTo addresses via recognized settlers (a conservative undercount, not an estimate). Traction never dominates; a service whose payTo is shared across services has its traction attributed PRO-QUOTA (volume and buyers divided by the number of services sharing the payout), so sharing neither rewards nor spam-clones a service. A service on a network not yet measured, or a shared member whose probe has been failing, carries no traction term (the other weights are renormalized). Traction also requires recent settlement: with no on-chain settlement in the last 30 UTC days the term is 0. Each recommendation also reports top_buyer_share_30d, the 30d volume share of the single largest buyer, as a published concentration signal for the reader; it does not enter the score. Optionally attach ecosystem facilitator-volume context separately.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text need description to match against name/description. | |
| limit | No | How many ranked recommendations to return. | |
| prefer | No | Tie-breaking emphasis for the ranking weights. | balanced |
| network | No | Required network name or abbreviation, e.g. 'Base' or 'BSE'; any network code returned by /api/v1/networks is accepted. | |
| category | No | Desired service category. | |
| max_price_usd | No | Cap on min_price_usd in US dollars; cheaper or equal passes. | |
| require_verified | No | If true, only verified services are eligible. | |
| include_facilitator_context | No | If true, also return top facilitators by 7d settlement volume as separate ecosystem context (NOT per-service). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses ranking behavior: weight distribution, neutral traction term, conservative undercount, and reporting of top_buyer_share_30d. It clarifies that traction never dominates and handles shared payTo addresses transparently.
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 verbose, with detailed ranking explanation that could be condensed or deferred. However, it is front-loaded with the purpose, and every sentence provides context, though length may hinder quick parsing.
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?
The description comprehensively addresses all aspects: ranking logic, edge cases (shared payTo, unmapped networks), and output details (top_buyer_share_30d, optional facilitator context). With no output schema, this is sufficient for an agent to understand inputs and outputs.
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 the baseline is 3. The description adds minimal new meaning beyond the schema; it briefly mentions conditional behavior for include_facilitator_context but does not elaborate on parameter semantics or encode additional constraints.
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 the tool's function: 'Recommend the best x402 service(s) for a need.' It details the ranking criteria (reliability, compliance, price, traction) and distinguishes from siblings like search_x402_services, which likely returns services without ranking.
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 implies usage for ranking needs but does not explicitly contrast with siblings like search_x402_services or get_service. No 'when to use vs alternatives' guidance is provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_facilitator_volumesAInspect
Get on-chain-verified settlement volume per x402 facilitator (the core x402-list metric). Returns USD settlement volume and transaction counts for today (UTC)/7d/30d/all-time, plus a verification flag ('on-chain' when volume has been observed on-chain, else 'listed'). Note: the fields named *_24h cover today (UTC) so far, not a trailing 24-hour window, so they reset at 00:00 UTC and read near zero just after midnight; prefer 7d for a stable recent-activity read. Optionally include a daily timeseries and per-chain breakdown. All volume figures are in US dollars. This is PER-FACILITATOR, not per-service.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Length of the timeseries in days (only used when include_timeseries is true). | |
| page | No | ||
| per_page | No | ||
| timeframe | No | Drives the sort order of the returned facilitators. '24h' sorts by today (UTC) so far, not by a trailing 24-hour window. | 7d |
| include_chains | No | Include a per-chain (network/asset) volume breakdown per facilitator. | |
| include_timeseries | No | Include a daily volume_usd / tx_count series per facilitator. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the non-obvious behavior of the 24h fields (today UTC, trailing window) and the verification flag's meaning. However, it omits behaviors like pagination effects or sorting details beyond timeframe.
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 a single, well-structured paragraph with front-loaded purpose, then outputs, then a crucial behavioral note, then optionals. Every sentence adds distinct value without redundancy.
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 and 6 parameters, the description covers the main output fields, the key behavioral nuance (24h field), and optional features. It lacks explanation of pagination behavior or how pagination interacts with returned data, but overall is complete for a volume listing 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?
The description adds meaning beyond the schema: explains the timeframe '24h' behavior and the days parameter's dependency on include_timeseries. With 67% schema coverage, the description compensates for the missing param descriptions (page, per_page) by clarifying the context of optional flags.
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 the tool retrieves on-chain-verified settlement volume per x402 facilitator. It specifies the resource (facilitator volumes) and distinguishes itself from siblings by noting it is per-facilitator, not per-service, which differentiates it from get_service and other service-level tools.
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 provides within-tool usage guidance (prefer 7d over 24h for stable reads, 24h resets at midnight) and hints at inter-tool differentiation (per-facilitator vs per-service), but does not explicitly state when to choose this tool over siblings like find_best_service or search_x402_services.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_serviceAInspect
Get full detail for one x402 service by slug: live status, uptime over 24h/7d/30d/90d, average response time, accepted networks and settlement asset, and every priced endpoint with its USD price. Use after search_x402_services to inspect a specific service. Prices are in US dollars; the per-endpoint price field is a raw on-chain atomic token amount, not dollars.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Service slug, e.g. 'my-api'. | |
| include_series | No | If true, also attach this service's daily on-chain series under `series` (settlement volume and distinct buyers, one point per UTC day over the most recent 90 days, oldest first). Off by default to keep the response small. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the output fields but does not explicitly state that the tool is read-only or non-destructive. While 'get' suggests safety, a direct statement would improve transparency. Discloses important price unit nuance.
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?
Three sentences, no wasted words. Front-loaded with the tool's purpose and output details, followed by usage guidance and a critical clarification about price units. Highly efficient.
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 complexity (single parameter, no output schema), the description adequately covers what the tool returns by listing key fields and addressing price interpretation. Minor omission: no mention of error handling or performance characteristics, but acceptable for a detail lookup 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% with a clear description for slug. The description adds the phrase 'by slug' but does not provide additional semantic value beyond what the schema already offers. Baseline 3 is appropriate.
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 the tool retrieves full details for one x402 service by slug, listing specific fields (live status, uptime, avg response time, networks, asset, priced endpoints). It explicitly distinguishes itself from search_x402_services by indicating this tool is used after that one for inspection.
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?
Explicitly states 'Use after search_x402_services to inspect a specific service', providing clear sequencing context. Also clarifies price interpretation, which aids correct usage. Lacks explicit when-not-to-use or alternatives, but the positive guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_x402_servicesAInspect
Search and filter the x402-list directory of services that accept x402 payments. Filter by free-text query, category, network, and live status; sort by newest, uptime, cheapest, or endpoint count. Returns service summaries with price (USD), uptime, status, and verification. Prices are in US dollars.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text search across name, description, category, base_url. | |
| page | No | ||
| sort | No | Server-side sort order. | newest |
| status | No | Filter by live monitoring status. | all |
| network | No | Network name or abbreviation, e.g. 'Base' or 'BSE'; any network code returned by /api/v1/networks is accepted. Omit for all. | |
| category | No | Exact category name (see categories context). Omit for all. | |
| per_page | No | ||
| verified_only | No | If true, return only verified services. Filtered server-side, so the result total covers the whole verified set, not just this page. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It correctly indicates a read-only search and mentions that prices are in USD and returns include summaries with specific fields. However, it does not disclose behaviors like rate limits, authentication needs, or behavior on empty results.
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 two sentences: first states purpose and filters, second describes output. No wasted words, front-loaded with the action. Exemplary conciseness.
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 8 parameters, no output schema, and no annotations, the description covers the main functionality, filter dimensions, and return fields. It could mention pagination implications but is largely complete for a search 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 description coverage is 75%, so schema already documents most parameters. The description summarizes filter and sort options but adds little beyond that. It does provide output details (price in USD, uptime, etc.) which the schema lacks, but this is marginal for parameter semantics.
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 uses the specific verb 'Search and filter', clearly identifies the resource ('x402-list directory of services'), and lists multiple filter dimensions, effectively distinguishing from sibling tools like get_service (single service) or check_health (health check).
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 implies usage for finding services by criteria (query, category, network, status) but does not explicitly state when not to use it or mention alternatives. However, the context is clear enough for an agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.