Stablecoin rails, corridors and payment provider data

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

No annotations exist, so the description carries the full burden and does well: free, deterministic, no external calls, 60 calls/min per client, and an explicit negative scope ('says nothing about who controls an address'). It omits error behavior for malformed chains, which keeps it 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.

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

Front-loaded as a question that states the core purpose immediately, then cost/scope/rate-limit details. The mid-sentence parenthetical listing outputs is slightly dense but every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations and no output schema, the description must supply everything, and it does cover inputs, per-chain behavior, outputs, cost, rate limit, and scope limits. It stops short of describing return shape or failure modes, which is the only remaining gap for a stateless check.

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

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

Schema coverage is 100%, so the baseline is 3, and the description adds real semantics beyond it: the chain parameter selects the validation regime (EIP-55 vs base58/32 bytes), and it enumerates the outputs tied to the address input (valid, checksummed form, checksum correctness, casing).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb+resource framing ('is this address well formed for this chain, and what is its EIP-55 checksummed form?') and names the two supported families (EVM EIP-55, Solana base58). It is trivially distinguishable from every sibling tool, none of which touch address validation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives clear context (free, deterministic, no external calls) and an explicit scope boundary: 'Format only; says nothing about who controls an address.' That tells the agent when NOT to rely on it. No alternative tool is named, but no sibling overlaps functionally, so there is nothing to route against.

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

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

With no annotations, the description carries the full burden and does it well: it discloses that the call is paid ($0.03 USDC), that the server holds no wallet and never pays, that it returns HTTP 402 payment requirements (x402 on Base, MPP on Tempo), and that the caller must pay with their own client and retry the URL. It also characterizes the payload (published corridors with rails/speed/fee notes/cited, plus inferred on/off-ramp routes labelled as inferred). Rate limits and failure modes are not covered, keeping it from 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.

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

Purpose is front-loaded as a question, followed by price, return content, and the payment/retry workflow. It is dense but each block earns its place; the main inefficiency is mild repetition of the 'one currency or stablecoin to another' phrasing between the question and the following sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates by describing what is returned (corridors with rails, speed, fee notes, citations; inferred ramps labelled as inferred) and by spelling out the 402 payment workflow end-to-end. It stops short of documenting error handling or parameter format edge cases, but covers what an agent needs to invoke it.

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

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

Schema description coverage is 100% and each of the three params (from, to, country) is documented with examples in the schema. The description echoes the from/to concept but adds no new parameter semantics such as accepted formats or aliases, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening question plus the follow-on phrase 'Money-movement routes from one currency or stablecoin to another' names a specific resource (corridors/routes) and the axis being queried (from → to, in a country, over rails). It is clearly a corridor/route lookup, but it never distinguishes itself from the closest sibling, stablecoin_rails, so an agent must infer which to pick.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is implied by the framing ('Who can move money...'), and the paid/non-paying-server flow tells the agent what to expect. However, with siblings like stablecoin_rails and search_providers present, there is no explicit when-to-use-this-vs-alternative guidance, so routing between tools is left to inference.

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

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

With no annotations, the description carries the full burden and does so exceptionally: it discloses the $0.001 USDC cost, that unresolved fields are the literal string "unknown", that unknown chains/malformed input return 404/400 without charge, and that the server holds no wallet and only returns 402 payment requirements (x402 on Base, MPP on Tempo) plus a retry URL.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The purpose is front-loaded, but the opening question and the following sentence list substantially the same fields twice (CAIP-2 id, gas token, explorer, x402/MPP, stablecoins), which is redundant. Several clauses about payment mechanics could be tightened without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description compensates fully by enumerating returned fields, documenting placeholder semantics, error codes, and the complete payment handshake including the retry URL. An agent has everything needed to invoke and interpret the call.

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

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

Schema coverage is 100% and the single parameter is documented with concrete examples (base, solana, eip155:8453), so the baseline is 3. The description adds only tangential parameter-related context via the unknown-chain 404 behavior, not additional syntax or format detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (chain facts) and enumerates exactly what it returns: CAIP-2 chain id, gas token, finality class, block explorer, x402/MPP settlement status, and stablecoins. This is distinguishable from siblings like get_token or get_provider because it is explicitly chain-level rather than token- or provider-level.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It clarifies that this is a paid endpoint and describes error handling for unknown/malformed input, which is useful. However, it never states when to reach for this tool versus alternatives such as get_token or stablecoin_rails, leaving sibling selection to inference.

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

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

With no annotations, the description carries the behavioural burden and does so well: it discloses the call is free, that the content is an example taken verbatim from a real record, that it is labelled as such, and that it carries a last-verified date. This is exactly the kind of provenance information an agent needs to avoid treating sample data as live. It stops short of explaining freshness guarantees or pagination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Every sentence carries information, but the second sentence opens with a dangling "Free:" fragment that reads awkwardly, and the opening question format delays the actual resource description. It is reasonably front-loaded but not cleanly structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, no annotations, and no parameters, the description must stand alone — and it describes the return payload (prices, paths, one full sample response with provenance labelling) well enough for correct invocation. Minor gaps around response freshness beyond the single verified date remain.

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

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

The tool takes zero parameters, so there is no parameter semantics to add; the baseline for a no-param tool is 4. The description correctly implies the call is parameterless by addressing it as a fixed catalogue lookup.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete resource — the catalogue of paid endpoints with their prices and paths — plus one full example response for GET /v1/provider. That is specific enough to distinguish it from siblings like get_provider, which returns live provider data. It is framed as a question rather than a verb+resource statement, which costs it a point.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

"Use it to see the shape and depth of paid data before paying" gives a clear when-to-use trigger: previewing paid data before committing to spend. It does not explicitly name an alternative tool, so the contrast with get_provider must be inferred.

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

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

With no annotations, the description carries the full behavioral burden and does so richly: it discloses the cost ($0.01 USDC), the payment protocols (x402 on Base, MPP on Tempo), that the server holds no wallet and never pays, and that it returns 402 payment requirements plus a retry URL. This is exactly the kind of auth/payment context an agent needs and could not infer from the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Purpose is front-loaded in the opening sentence and the field list, with the payment mechanics following. There is mild redundancy — the rhetorical opener partially restates the enumerated content that follows, and the URL is repeated — but every sentence still conveys actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema and no annotations, the description effectively documents the return shape (every fact carries source URL, retrieval date, quote and confidence) and the complete payment handshake. An agent has everything needed to attempt the call and handle the 402 response.

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

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

There is only one parameter and schema description coverage is 100%, with the schema already explaining 'Provider id from search_providers, e.g. circle'. The description adds no syntax or format detail for the id beyond confirming the single-provider scope, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource — retrieve the full cited record for a single provider — and enumerates the content covered (rails, corridors, licences, fees, coverage, payment support). It distinguishes itself from search_providers only implicitly via the schema hint ('Provider id from search_providers'), so the sibling contrast is not spelled out in the prose itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It gives a clear procedural path: this is a paid endpoint, the server returns HTTP 402 requirements, and the caller must pay with their own x402/MPP client and retry the URL. It doesn't explicitly say when to prefer this over search_providers (e.g., single-record lookup vs discovery), so the when-to-use guidance is contextual rather than explicit.

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

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

With no annotations, the description carries the full behavioral burden and does so unusually well: it discloses the exact cost ($0.001 USDC), that failures (400/404) are never charged, that unestablished fields are returned as the literal string "unknown", and that the server holds no wallet and only returns 402 payment requirements for the agent to settle externally. An agent knows the cost, the failure cost profile, and the full retry flow before calling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

It is front-loaded with the core question and the return fields, which is good, but the middle and end are dense run-on sentences and the payment mechanics are restated (no wallet, never pays, pay-and-retry) with overlap. Shorter phrasing would carry the same information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must describe returns, and it does: the field list, per-field source citations and licenses, and the "unknown" sentinel for unestablished fields. Combined with error semantics and the payment flow, an agent has everything needed to invoke the tool and complete the paid call.

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

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

Schema description coverage is 100%, so the schema already documents chain (slug/name/CAIP-2, with example), symbol, and address, including the symbol-or-address fallback. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening question states a specific resource and the exact fields returned (symbol, name, decimals, contract address, issuer) for a stablecoin on a given chain, which is far more than a tautology. It also scopes the dataset (USDC, EURC, USDT, PYUSD, DAI on /v1/chain-covered chains), but it never names a sibling tool to contrast against, so differentiation from get_provider or stablecoin_rails is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It gives usable context: paid lookup, tokens must exist in the dataset, malformed input and misses return 400/404, and payment is completed by retrying the returned URL. However, it never states when an agent should choose this over the sibling tools (e.g. get_chain or stablecoin_rails), so the routing guidance is only implied.

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

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

With no annotations, the description carries the full burden and does well: it declares cost ("Free"), the rate limit ("50 calls/day per client"), and the return shape ("compact cards (no citations)"). It does not state pagination/result-count limits or that empty filters return a broad listing, so it is strong but not exhaustive for a zero-annotation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Front-loaded question followed by tightly packed clauses covering scope, cost, return format, alternative tool, and rate limit in four sentences. Dense but every clause carries information; only the slight redundancy between the question and the second sentence costs a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter, fully-documented, filter-only search tool with no output schema and no annotations, the description supplies cost, rate limit, result format, and the escalation path to get_provider. What is missing is minor: no note on result count/pagination or behavior when all optional filters are omitted.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters with format examples. The description mostly restates those facets, adding only the mild nuance that country means on/off-ramp coverage; baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a concrete question that names the resource (payment/stablecoin providers) and the exact facets searched (asset, chain, country, service/category). It also explicitly distinguishes itself from the sibling get_provider, so an agent can separate the two 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.

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

"use get_provider for the full cited record" names the alternative and the condition that selects it, and the leading question frames the intended query context. No explicit when-not guidance (e.g., do not use for name-only or non-provider lookups) is given, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden and largely meets it: it discloses the price ($0.01 USDC), that the server holds no wallet and never pays, that it returns HTTP 402 requirements, the payment protocols (x402 on Base, MPP on Tempo), and the exact URL to retry. It stops short of covering rate limits, auth, or result caps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Front-loads the purpose as a question and then the paid/scope line before the payment mechanics, so the important content comes first. The payment paragraph is dense but earns its place given the unusual 402 flow; only minor overlap between 'Paid ($0.01 USDC)' and the later payment sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and no annotations, yet the description explains what a result contains (cited stablecoin block with assets, chains, ramp countries, fiat rails, custody model) and how payment works. Missing only secondary details like pagination or result limits, which are minor for a single-lookup tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it frames the four inputs as the asset/chain/country/service axes and clarifies that country matches indicate 'listed' vs. only covered by a 'global' claim, which is not in the schema. That extra semantic detail lifts it above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a concrete question that names the verb (on-ramp, off-ramp, issue, settle) and the resource (this stablecoin's rails), then restates scope as 'rails by asset, chain, country and service.' The scope is unambiguous, though it does not explicitly name or contrast itself with siblings like search_providers or get_provider.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage context is implied by the four filtering dimensions and the note about how country matches are classified, and there are detailed operational instructions for paying and retrying the URL. However, there is no statement of when to choose this over search_providers or find_corridor, and no when-not-to-use guidance.

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