Skip to main content
Glama

Settled

by tools.settled
OverviewDiscussionsAdmin

Find live x402 endpoints

settled_find_endpoints
Read-onlyIdempotent

Free up to 50 calls/day per client (a pass allows 1,000). Ranked live endpoints by keyword, network and max price (sort by quality, price, latency or payers), each with payability and delivery verification. Use when: you need an x402 endpoint for a capability and want candidates that are live, payable and, where possible, proven to deliver. Not for: verifying one known URL (settled_check). After: run settled_check or settled_preflight on the one you pick before paying.

Input Schema

NameRequiredDescriptionDefault
qNoKeywords to match in endpoint names, descriptions and URLs, e.g. weather or gift cards
passNoSettled day pass token: lifts the free daily cap; or send it as the x-settled-pass header
sortNoOrder of results: quality (default), price, latency or payers
limitNoHow many endpoints to return, 1-50 (default 20)
statusNoOnly endpoints with this status; live (default) or any for every status
networkNoOnly endpoints on this network, as a CAIP-2 id, e.g. eip155:8453 for Base
max_priceNoHighest price per call in USD, e.g. 0.01
payer_tokenNoA Settled payer token (x4t_…, from POST /x401/token with your payer record): the free tier then follows your wallet, 300 a day, through any gateway

Output Schema

NameRequiredDescriptionDefault
countNoNumber of endpoints returned
errorNoPresent only when the call failed or needs another step: an error code such as pass_required, next to the fields that explain it
itemsNoRanked endpoints, each with payability and delivery status
filtersNoThe filters applied
attestationNoEIP-191 signature over the answer; verify it with settled_verify or any EVM library
attested_atNoWhen Settled signed this answer (ISO 8601)
generated_atNoWhen this list was built

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / payer_token
      Added value: +{
+  "description": "A Settled payer token (x4t_…, from POST /x401/token with your payer record): the free tier then follows your wallet, 300 a day, through any gateway",
+  "type": "string"
+}
  2. Changed3 schema fields changed
    • addedInput schema / properties / max_price / minimum
      Added value: +0
    • changedInput schema / properties / status / description
      Previous value: -"Endpoint status: live (default), degraded, dead, free, auth_gated, not_found, quote_invalid, unknown or any"New value: +"Only endpoints with this status; live (default) or any for every status"
    • addedInput schema / properties / status / enum
      Added value: +[
+  "live",
+  "degraded",
+  "dead",
+  "free",
+  "auth_gated",
+  "not_found",
+  "quote_invalid",
+  "unknown",
+  "any"
+]
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), but the description adds genuinely non-structured behavior: a free quota of 50 calls/day, a pass lifting it to 1,000, and the fact that results carry payability and delivery verification. It doesn't discuss result volume/pagination beyond the schema's limit, which keeps it just short of a 5.

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 compact sentences that front-load the quota and the ranked-results framing, then the routing guidance. Densely packed but every clause carries information; no filler.

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 8 optional params, full schema coverage, annotations, and an output schema in place, the description supplies exactly the missing layer: quota behavior, what the ranking means, when to use it, and the required follow-up check before paying. Nothing an agent needs to select or call it is absent.

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?

Schema description coverage is 100%, so every parameter is already documented, including the sort enum and the CAIP-2 network format. The description only restates keyword/network/price/sort semantics and adds no format or edge-case detail beyond the schema, so the baseline 3 applies.

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 and resource ('find/rank live endpoints') plus the filters and sort dimension, and frames the result set (payability and delivery verification). It is clearly distinct from the sibling set, which is mostly per-URL checkers and seller/reputation tools.

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?

Explicit 'Use when' condition, an explicit 'Not for: verifying one known URL (settled_check)' exclusion naming the alternative, and an 'After' step routing to settled_check or settled_preflight before paying. This is the full when/when-not/next-action triad.

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

All Settled toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources