Skip to main content
Glama

x402-list-mcp

by com.x402-list

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 a directory of 500+ 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

TableJSON 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.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already signal readOnlyHint and openWorldHint, and the description adds useful behavioral detail beyond that: it explains pagination ('up to 100 compact summaries a page'), the kind of output returned (price, uptime, status, verification), and the candidate-narrowing workflow. 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.

Conciseness5/5

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

Two dense, front-loaded sentences cover purpose, filters, sorting, result size, output content, and the follow-up tool. There is no filler or repetition of schema details; every clause earns its place.

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 10-parameter, no-output-schema search tool, the description is largely complete: it explains when to use it, what it filters/sorts by, page limits, and what to do next. Minor gaps remain around exact pagination metadata and the full list of compact summary fields, but the schema compensates for parameter-level details.

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

Parameters3/5

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

The schema has 100% parameter description coverage, so the baseline is 3. The description correctly summarizes the filter dimensions and sort options, but it does not add meaningful detail beyond the schema's per-parameter descriptions, such as exact filtering behavior or response shape details.

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 uses a specific verb and resource: it 'narrows a directory of 500+ listed services to candidates' and is explicitly positioned as 'your first call' when the target service is unknown. It clearly distinguishes itself from x402_get_service, which is described as the follow-up for the full record.

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?

It provides a clear when-to-use condition ('when you do not know which x402 service exists for a job') and points to x402_get_service as the natural next step for full records. It does not explicitly cover when not to use this tool versus other siblings like x402_find_best_service, but the context is strong.

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