Settled

Settled index status

settled_status

Read-onlyIdempotent

Free. Size and freshness of the x402 endpoint index and the on-chain ledger. Use when: you need to know how current Settled’s data is, or what the paid routes cost, before relying on any other tool. Not for: looking up a specific endpoint (use settled_check). No input.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`mcp`	No	This MCP server's URL
`docs`	No	Where the docs are
`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
`scout`	No	Totals for the scout's paid test purchases
`network`	No	Network Settled's own paid routes settle on (CAIP-2)
`service`	No	Always Settled
`sources`	No	Discovery sources and how far each import has got
`version`	No	Settled's software version
`by_status`	No	Endpoint counts by status (live, dead, ...)
`prices_usd`	No	Prices of Settled's paid routes, in USD
`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)
`total_probes`	No	Probes run so far
`last_probe_at`	No	When the latest probe ran
`settlement_7d`	No	x402 payments (matching a quoted price; crawlers and monitors left out) to tracked sellers over the 7 whole UTC days to yesterday (days gives the first and last)
`onchain_ledger`	No	Coverage of Settled's on-chain settlement ledger
`endpoints_probed`	No	How many have been probed
`endpoints_tracked`	No	Number of x402 endpoints Settled tracks
`live_share_of_probed`	No	Percentage of probed endpoints that are live

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 15, 2026

changedOutput schema / properties / settlement_7d / description

Previous value: -"x402 payments (matching a quoted price; crawlers and monitors left out) to tracked sellers in the last 7 days"New value: +"x402 payments (matching a quoted price; crawlers and monitors left out) to tracked sellers over the 7 whole UTC days to yesterday (days gives the first and last)"

Changed1 schema field changedOct 14, 2026

changedOutput schema / properties / settlement_7d / description

Previous value: -"USDC settled to tracked sellers in the last 7 days"New value: +"x402 payments (matching a quoted price; crawlers and monitors left out) to tracked sellers in the last 7 days"

First observedOct 2, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description still adds genuinely new context: 'Free' (no paid invocation), 'No input', and the fact that the response covers both index freshness and paid-route pricing. It does not discuss rate limits or update cadence, but for a status read that is a minor gap.

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?

Front-loaded with the cost fact ('Free.'), then purpose, then when-to-use, then exclusion. Every clause earns its place; 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?

An output schema exists, so return values need not be described. Combined with full annotation coverage and zero parameters, the description supplies everything needed to decide when to call it and what to expect.

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?

Zero parameters, so the baseline is 4. The description confirms 'No input', which is consistent with the empty schema and prevents an agent from inventing arguments.

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 resource ('the x402 endpoint index and the on-chain ledger') and exactly what aspect it reports ('size and freshness'). It also names the sibling it is not for (settled_check), so an agent can route between them without opening either 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?

Explicit 'Use when' clause names the decision it supports (judging data currency, route cost before relying on other tools) and an explicit 'Not for' clause redirects to settled_check. Both selection conditions are unambiguous.

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?