Skip to main content
Glama

x402-list-mcp

by com.x402-list

Assess x402 services (paid)

x402_assess_services

Call this when the free signals have run out: you hold 2 to 8 finalists from x402_search_services or x402_find_best_service, their stored fields do not separate them for YOUR stated need, and choosing wrong costs more than a quarter. It buys one fresh AI assessment reasoned against your question, not a cached grade; reading an already-computed assessment stays free via x402_get_service. Price: a one-time $0.25 USDC on Base, over two calls. Call once WITHOUT payment_signature_b64 to receive the x402 payment challenge verbatim (accepts[], amount, payTo, and a base64 PAYMENT-REQUIRED header); sign accepts[0] client-side with your own wallet; call again with the SAME question and services plus payment_signature_b64 to receive the report and a base64 PAYMENT-RESPONSE settlement receipt. This server holds no keys, never signs and never settles: it only relays the challenge. Optionally add probe { slug, endpoint_path? } to have one listed service paid and called for real and its answer analyzed: the challenge is then priced at $0.25 plus that endpoint price X, and the report gains a probe_report block with a verdict and truncated extracts, never the verbatim third-party body. When live probing is not armed the probe is ignored. Caveats: read the amount to sign from accepts[0].amount, never from a fixed figure, since a probe changes it; probe fees are non-refundable whatever the verdict; if the fresh run cannot be produced the server answers before settling, so you are never charged for nothing; there is no refund. Prices are US dollars.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
probeNoOptional 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.
questionYesThe need to assess the shortlist against (1 to 1000 characters).
servicesYesService slugs to compare for the need (1 to 8; find them with x402_search_services or x402_find_best_service).
payment_signature_b64NoBase64 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.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false / idempotentHint=false / openWorldHint=true, and the description goes far beyond them: two-call payment protocol, price ($0.25 USDC on Base plus probe endpoint price X), the server's no-keys/no-signing/no-settlement relay role, non-refundable probe fees, and settle-only-after-success behavior. This is exactly the operational context an agent needs that annotations do not provide.

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?

Long but highly informative; every sentence carries a distinct operational fact. The trigger condition is front-loaded, then the what, then the two-call mechanics, then probe and caveats. Minor redundancy ('non-refundable' and 'there is no refund') keeps it from a 5, but the density is justified by the tool's complexity.

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?

For a paid multi-step tool with nested probe objects and no output schema, this is remarkably complete: it covers the challenge contents (accepts[], amount, payTo, PAYMENT-REQUIRED header), the report trigger, probe behavior and cost, and failure/refund edges. Nothing an agent needs to execute the two calls 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 100%, so the schema already documents all four parameters well. The description adds operational meaning the schema lacks: the omit-then-set protocol for payment_signature_b64 requiring 'the SAME question and services', and the probe's price-inflation and probe_report implications beyond the schema's structural description.

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?

States a specific verb+resource ('buys one fresh AI assessment reasoned against your question') and explicitly contrasts itself with x402_get_service ('not a cached grade... stays free via x402_get_service') and with the search tools that produce the finalists. An agent can immediately tell this is the paid fresh-assessment tier and not a search or cached-read sibling.

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

Usage Guidelines5/5

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

Gives an explicit trigger condition ('when the free signals have run out: you hold 2 to 8 finalists... and choosing wrong costs more than a quarter') and names the alternative for the cheaper case ('reading an already-computed assessment stays free via x402_get_service'). The qualification criteria are concrete enough to route correctly.

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

All x402-list-mcp toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool targets a distinct action: searching, retrieving full records, ranking, paid assessment, health checks, change monitoring, and volume tracking. Even search vs find_best_service are clearly separated by purpose (list vs ranked recommendation).

Naming Consistency5/5

All tools follow a consistent x402_verb_noun pattern (e.g., search_services, get_service, find_best_service). Snake_case is used uniformly, and verbs are descriptive and distinct.

Tool Count5/5

Seven tools is well-scoped for a directory/evaluation service. Each tool serves a distinct phase in the user workflow: discovery, comparison, health verification, and paid assessment, with no redundancy.

Completeness4/5

The surface covers discovery (search, find_best), detailed lookup (get_service), health checks, change monitoring, and even the paid assessment workflow. Minor gap: no explicit bulk list or category browsing, but search with filters covers that. No dead ends.

Resources