Settled

Check an x402 endpoint

settled_check

Read-onlyIdempotent

Free: 25 calls/day per address, 300 with a payer record (free, keyed to your wallet), no daily cap with a pass. Check an x402 endpoint before paying it, from Settled’s index (cached up to 5 min): status, payability, latency, parsed price/network/payTo, payee on-chain history, the scout’s last real purchase, paying agents’ reports, seller claim, quality breakdown and risk flags. Use when: deciding whether to call an endpoint, and for routine re-checks. Not for: a fresh probe right now (settled_preflight) or searching (settled_find_endpoints). If status is unknown, call settled_submit; after paying, call settled_report.

Input Schema

Name	Required	Description
`url`	Yes	Full URL of the x402 endpoint, e.g. https://api.example.com/search
`pass`	No	Settled day pass token: lifts the free daily cap; or send it as the x-settled-pass header
`force`	No	true to probe now instead of using the 5-minute cache; needs a pass
`payer_token`	No	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

Output Schema

Name	Required	Description
`url`	No	The endpoint
`asset`	No	Asset of the cheapest option
`error`	No	Present only when the call failed or needs another step: an error code such as pass_required, next to the fields that explain it
`flags`	No	Risk flags
`payee`	No	Whether the payTo has on-chain history
`cached`	No	Whether this came from Settled's 5-minute cache
`pay_to`	No	The payTo Settled's probe sees; compare it with the quote you are about to pay
`scheme`	No	Payment scheme, e.g. exact
`status`	No	Endpoint status, e.g. live, degraded, dead, free, auth_gated, not_found or quote_invalid
`network`	No	Network of the cheapest option (CAIP-2)
`onchain`	No	Settlements and unique payers over the last 30 days
`quality`	No	Quality score breakdown
`reports`	No	Paying agents' reports
`evidence`	No	The grade of the evidence and the receipt line first: grade purchased (Settled paid this endpoint and compared what came back with the listing; receipt has the amount, day, bytes, listing verdict and Base transaction) or observed (live probes, payTo history and agent reports only; the scout buys and the ledger reads on Base, so an endpoint on another network is observed only)
`price_usd`	No	Price per call in USD (cheapest option)
`checked_at`	No	When this answer was built
`first_seen`	No	When Settled first saw it
`last_ok_at`	No	When it last answered with a valid quote
`latency_ms`	No	Latency of the latest probe
`payability`	No	Payability verdict and the verb that pays
`attestation`	No	EIP-191 signature over the answer; verify it with settled_verify or any EVM library
`attested_at`	No	When Settled signed this answer (ISO 8601)
`description`	No	The listing's description
`network_name`	No	Readable network name
`seller_claim`	No	The seller's claim and profile, if claimed
`service_name`	No	The listing's service name
`x402_version`	No	x402 version of the quote
`last_probe_at`	No	When Settled last probed it
`delivery_receipt`	No	The scout's last purchase, with its settlement transaction and checks (when the scout has bought it)
`http_status_last`	No	HTTP status of the latest probe
`last_delivery_at`	No	When the scout last bought it
`delivery_verified`	No	Whether a real payment by Settled's scout came back with content

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026

addedOutput schema / properties / evidence

Added value: +{
+  "description": "The grade of the evidence and the receipt line first: grade purchased (Settled paid this endpoint and compared what came back with the listing; receipt has the amount, day, bytes, listing verdict and Base transaction) or observed (live probes, payTo history and agent reports only; the scout buys and the ledger reads on Base, so an endpoint on another network is observed only)"
+}

Changed1 schema field changedOct 23, 2026

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"
+}

First observedOct 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations by disclosing quota mechanics (25/day per address, 300 with a payer record, uncapped with a pass) and cache staleness (up to 5 min), which materially affect result freshness and failure modes. It also surfaces downstream workflow obligations (submit if unknown, report after paying).

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?

Dense but every sentence carries information; the use/not-for/next-step structure is easy to parse. Mild weakness: the pricing/quota sentence is front-loaded ahead of the core purpose, so the most decision-relevant statement is not first.

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 an output schema present, the description need only cover selection, cost, and caching — all of which it does, plus cross-tool handoffs. Nothing an agent needs to call this 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 adds value by tying the free-tier behavior to the payer record/pass and by framing `force` as a probe that bypasses the 5-minute cache and requires a pass. It does not add syntax or format detail beyond the schema, hence not a 5.

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+resource ('Check an x402 endpoint'), names the data source ('Settled's index, cached up to 5 min'), and enumerates the returned signals (status, payability, latency, price/network/payTo, payee history, reports, risk flags). It also explicitly separates itself from settled_preflight (fresh probe) and settled_find_endpoints (search), so an agent can pick it 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 Guidelines5/5

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

Gives explicit 'Use when' (deciding whether to call an endpoint; routine re-checks) and 'Not for' clauses naming the two alternatives. It further routes follow-ups: settled_submit when status is unknown, settled_report after paying — a full decision tree rather than an implied one.

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

All Settled tools Inspect

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

Need Help?