Skip to main content
Glama
Sign In

x402-list-mcp

by com.x402-list
OverviewDiscussionsAdmin

Search x402 services

x402_search_services
Read-only

Your first call when you do not know which x402 service exists for a job: it narrows the directory of listed services to candidates. Filter by free-text query, category, network, live status, and whether the last observed 402 envelope is signable by a standard x402 client; sort by newest, uptime, cheapest, or endpoints. Returns up to 100 compact summaries a page: price in decimal USD, uptime, status, verification. Then x402_get_service for the full record.

Input Schema

NameRequiredDescriptionDefault
qNoFree-text search across name, description, category, base_url.
pageNo1-based page index into the filtered result set (see meta.total_pages).
sortNoServer-side sort order.newest
fieldsNoResponse detail: 'compact' (default) = lean summaries (identity, price, status, uptime, verification, networks, compliance grade), 'full' = every field including the per-service assessment block. Compact keeps a directory sweep small enough to not truncate.compact
statusNoFilter by live monitoring status.all
networkNoNetwork name or abbreviation, e.g. 'Base' or 'BSE'; any network code returned by /api/v1/networks is accepted. Omit for all.
categoryNoExact category name (see categories context). Omit for all.
per_pageNoServices per page, 1 to 100 (default 25). Higher values return larger results; with fields='full' a large page can be very heavy, so prefer compact when raising it.
signableNoFilter on the signability of the last observed 402 envelope: true = no EVM route of the service was observed missing the EIP-712 domain parameters (extra.name and extra.version) that a standard x402 client requires in order to sign a payment, false = at least one such route was observed. It describes the payment envelope on the wire, not the merit of the service. A service whose latest assessment has not measured that check yet matches NEITHER value, so omit this parameter to include it. Filtered server-side, so the result total covers the whole filtered set.
verified_onlyNoIf true, return only verified services. Filtered server-side, so the result total covers the whole verified set, not just this page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / page / maximum
      Added value: +9007199254740991
  2. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds real value beyond them by disclosing page size limits ('up to 100 compact summaries a page'), the compact-vs-full payload tradeoff that avoids truncation, and the subtle signable semantics including the case where an unmeasured service matches neither value.

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, front-loaded with the 'call this first' trigger, then capabilities, then the handoff. No filler and no repetition of the schema's enum values beyond what is needed to signal the available axes.

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 no output schema, the description carries the return-value burden and does so ('price in decimal USD, uptime, status, verification', paginated to 100), plus a clear next-step pointer. Nothing an agent needs to call a 10-parameter read-only search 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 baseline is 3; the description still earns credit by summarizing the filter axes (query, category, network, live status, signable), the four sort orders, and the field-detail switch in prose. It adds interpretation ('price in decimal USD') rather than duplicating the enum lists verbatim.

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 concrete verb and resource ('narrows the directory of listed services to candidates') plus the exact scope of what can be filtered and sorted. It explicitly routes the follow-up to x402_get_service for full records, so an agent can separate it from that sibling without opening a schema.

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?

'Your first call when you do not know which x402 service exists for a job' is explicit about when to reach for it, and the closing sentence names the next step (x402_get_service). It stops short of contrasting with find_best_service or assess_services, which are the other plausible choices for a service-discovery task.

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
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources