x402 Toolbox

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

With no annotations, the description carries the full behavioral burden, and it does disclose one meaningful trait: the MCP path is free while the identical data is pay-per-call elsewhere. It does not mention rate limits, caching/freshness of the data, which chain(s) are covered, or error behavior for invalid addresses.

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 with what the tool returns, which is the right priority. Two sentences, no padding, though the second sentence leans promotional (pay-per-call URL) rather than operational.

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, so the description usefully enumerates the returned fields, which is the key completeness win for a thin lookup tool. Remaining gap is the unspecified blockchain/network scope, which an agent may need before calling.

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?

Only one parameter, and the schema documents it at 100% coverage with a clear description. The prose adds the framing that the address is a wallet (contract or EOA looked up), which is modest added meaning; the notable gap is that no supported chain/format is specified. One-parameter tool with full schema coverage sits at the high end of the 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?

States a concrete verb+resource (enrich a wallet address) and enumerates the exact payload an agent gets back: contract vs EOA classification, native balance, transaction count. No sibling in the list (gas, price, attestation, transfers, verify_tx) overlaps with address enrichment, so it is trivially disambiguated.

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 only implied: an agent can infer it should call this when it needs address-level context. There is no explicit when-to-use/when-not-to-use guidance and no routing to siblings such as get_reputation or verify_tx. The pay-per-call note is a cost/availability remark, not tool-selection guidance.

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 must carry the behavioral burden, and it does disclose two useful traits: the entries are persisted history and they are 'doubly-signed' (an authenticity property an agent can rely on). It does not say whether the log is append-only, its retention window, or what an entry contains, and there is no output schema to fill that gap.

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?

Two sentences, front-loaded with the tool's identity before the access/pricing note, with no filler. Every clause carries information an agent can act on.

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 one-optional-parameter read tool with no annotations and no output schema, the description covers identity and access but not the shape or size of what comes back, so an agent cannot tell how to interpret results. It is adequate but leaves a real gap.

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% (the single 'limit' parameter documents range 1-100 and default 20), so the baseline is 3. The description adds nothing about pagination or ordering semantics beyond what the schema already states.

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 the resource precisely - a persisted, doubly-signed log of past oracle attestations from this server - which is specific enough to separate it from every sibling (verify_tx, get_reputation, get_gas_*). The retrieval verb is only implied by the name rather than stated ('get/list'), so it falls just short of the top mark.

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?

There is no statement of when to reach for this tool versus the many sibling read tools, and no prerequisites or exclusions. The only conditional language concerns free-via-MCP versus pay-per-call access, which is a pricing note rather than usage guidance.

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. It usefully discloses the cost/freshness tradeoff and where the paid variant lives, which is real behavioral context. It omits key traits for a freshness-tiered tool: how stale 'cached' data may be, rate limits on the free path, and whether results differ in shape between tiers.

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?

Two compact sentences, front-loaded with the data served and the tiering model. The trailing sentence about the paid endpoint is promotional but does convey a genuine usage channel, so it earns partial keep; a small amount of framing could be trimmed.

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 single-parameter, no-output-schema read tool with full schema coverage, the description covers what is returned, the two modes, and the cost model. The remaining gap is the absence of any indication of freshness windows or response shape, which would matter for the 'cached' mode.

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 enum already documents the two values, so a 3 baseline applies. The description goes slightly beyond the schema by attaching meaning to each tier ('cheap' vs 'guaranteed current'), which helps the agent choose a value rather than just enumerate it.

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?

It names the resource (gas + ETH/USD data) and the defining dimension (freshness tier), which is more specific than a generic 'get data'. It does not, however, contrast itself against the many siblings that also serve gas or ETH price data (get_gas_metrics, get_reliable_eth_price, get_normalized_gas), so an agent still has to infer which source 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?

The tier hints ('cached (cheap)' vs 'live (guaranteed current)') imply when each option is appropriate, and the pay-per-call note signals a production context. But there is no explicit routing guidance versus sibling tools, and no statement of when this tool should not be used or what limits apply to the free MCP path.

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?

No annotations are provided, so the description carries the full burden. It adds useful availability context (free via MCP, paid API alternative) and implies real-time data, but it does not disclose safety profile, rate limits, authentication needs, freshness guarantees, or caching behavior.

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 description is two tightly written sentences. The core function and return fields are front-loaded, and the pricing/availability note is secondary and brief.

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 zero-parameter read tool with no output schema, the description gives a solid summary of return values: side-by-side gas prices, delta, ratio, and estimated USD transfer cost on both chains. It omits details like units, timestamp, and exact response format, but remains adequate for most agent selection needs.

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 are zero parameters, so the baseline score is 4. The description does not need to explain input semantics, and it appropriately focuses on what data is returned instead.

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 resource and scope: real gas price on Ethereum vs Base side by side, plus delta, ratio, and USD transfer cost. It is clearly distinguishable from generic gas metrics and historical gas tools by its cross-chain comparator focus, though it does not explicitly name sibling alternatives.

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 some usage context by noting the data is free via MCP and also available pay-per-call for production/agentic use. However, it does not say when to choose this tool over siblings like get_gas_metrics or get_normalized_gas, nor does it state any exclusions.

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 disclose useful non-schema traits: row-count pricing, a minimum charge, a stated max range, free MCP access, and a paid production endpoint. It still omits rate limits, authentication needs, and explicit read-only/side-effect information.

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 description is two sentences and front-loads the core capability before moving to pricing and availability. It is dense but not repetitive, and the paid endpoint is relevant context rather than padding.

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 simple three-parameter export tool with a fully documented schema and no output schema, the description covers the basic purpose, format, and pricing. It remains incomplete on sibling differentiation, explicit date-range constraints, and operational details such as rate limits or auth.

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 schema already documents from, to, and format. The description reinforces the date-range and JSON/CSV aspects but adds no syntax, timezone, inclusivity, or range-bound details beyond the schema.

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 clearly states the resource and scope: raw Ethereum gas price samples over a date range, with JSON or CSV output. It distinguishes the tool from aggregate/metric siblings by emphasizing raw samples and export, though it does not explicitly name a sibling for contrast.

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 notes that the data is free via MCP and that the same data is available pay-per-call for production/agentic use, which gives some usage context. However, it does not explain when to choose this tool over sibling gas tools such as get_gas_metrics or get_gas_comparator.

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?

No annotations are provided, so the description carries the full disclosure burden. It usefully reveals the pricing model (free via MCP, pay-per-call alternative for production), but says nothing about rate limits, window bounds, data source, or freshness — significant gaps for a tool whose reliability profile matters.

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?

Two sentences, front-loaded with the substantive capability before the commercial note. The promotional URL is arguably incidental to tool selection, but the text is otherwise tight with no wasted words.

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, the description usefully enumerates the returned statistics, covering the return-value question. The parameters are fully documented in the schema, so the remaining omission — data source and freshness guarantees — is a modest gap rather than a blocking one.

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 single parameter windowMinutes is fully documented in the schema (100% coverage), so the schema does the heavy lifting. The description's phrase 'over a window' corroborates the parameter meaning but adds no syntax, bounds, or default information beyond what the schema already supplies.

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 (Ethereum gas price) and enumerates exactly what is computed (rolling average/min/max/volatility/trend), which lets an agent distinguish it from siblings like get_gas_history_export or get_normalized_gas. It does not, however, explicitly state how it differs from those tools, so it stops short of a 5.

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?

There is no when-to-use or when-not-to-use guidance relative to the sibling gas tools. The mention of a pay-per-call production endpoint is about the delivery channel, not about choosing this tool over get_gas_comparator or get_normalized_gas, so it does not function as usage routing.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses that access is free via MCP and that the same data is sold pay-per-call elsewhere, which is real behavioral context; however, 'recent' is undefined (no freshness window), and nothing is said about result ordering, size limits, 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?

Two short sentences, purpose front-loaded, no filler. The second sentence is a promotional/alternative-channel note rather than functional information, which slightly dilutes focus but does not bloat the definition.

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 one optional parameter, no annotations, and no output schema, the description is adequate but leaves key operational gaps: it never defines the freshness window implied by 'recent', nor says anything about result volume. The pricing sentence is extra context rather than a gap-filler.

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 the single parameter (minUsd) already documents its meaning and default of 10000. The description only restates 'above a value threshold' and adds no format, unit, or boundary detail beyond the schema, 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?

Names a specific resource (recent USDC transfers on Base) with a scope condition (above a value threshold), so an agent knows exactly what data it returns. Siblings are all unrelated data feeds (gas, attestation, price), so no explicit differentiation is needed, but the description also never states the underlying verb (list/filter/stream).

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?

There is no when-to-use or when-not-to-use guidance relative to alternatives. The second sentence describes an access/pricing channel (free via MCP vs pay-per-call URL), which is about cost, not about when this tool is the right choice.

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?

No annotations are provided, so the description carries the full disclosure burden; it does add real behavioral context by stating the MCP path is free, that a referral cut is paid via ?ref=<address>, and that the same data is sold pay-per-call elsewhere. However it says nothing about return format, rate limits, or freshness/latency of the snapshot, leaving meaningful gaps for a tool with zero annotation coverage.

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?

Three tight sentences, front-loaded with the payload contents before the referral and pricing details. The pricing/URL sentence is somewhat promotional but conveys genuinely useful cost information, so it mostly earns its place.

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, the description compensates by naming the three returned values, and it covers the cost model. For a zero-parameter read tool this is nearly complete, though freshness, format, and whether the referral option applies over MCP remain unstated.

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?

Zero declared parameters, so the schema baseline is 4. The description goes beyond the empty input schema by documenting an optional ?ref=<address> option and its effect (referral cut), though it is unclear whether that query parameter applies to the MCP invocation or only the HTTP endpoint, which introduces slight ambiguity.

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 specific verb (get) and an aggregated resource, then enumerates exactly what is bundled: gas price, ETH/USD price, and the latest Base block. The phrase 'in one call' distinguishes it from single-purpose siblings like get_gas_metrics or get_reliable_eth_price without requiring the agent to open their schemas.

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?

Implies the selection condition well - use this when you need all three data points at once - and names an alternative channel (pay-per-call at the HTTP endpoint) with its intended context (production/agentic use). It does not explicitly say when NOT to use it or route the agent to the narrower sibling tools for single-metric needs.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses availability/cost (free via MCP, pay-per-call alternative) but says nothing about freshness, polling cadence, read-only nature, rate limits, or what the consistent schema contains.

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?

Two sentences, front-loaded with the data scope and schema normalization. The second sentence is partly commercial promotion, which is slightly off-purpose but brief.

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 no-argument read tool with no output schema, the description conveys the data domain (gas price and block data for two chains) but omits freshness/cadence and any sense of return shape, e.g. price units or per-block vs current-only. Adequate but with visible gaps.

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 the baseline is 4. There are no arguments whose semantics could be expanded, and the description does not need to compensate.

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 specific resource (Ethereum and Base gas price and block data) and a distinguishing property: normalized into one consistent schema per chain. That differentiates it from sibling gas tools like get_gas_metrics or get_gas_comparator, though it never names or contrasts them explicitly.

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?

There is no when-to-use guidance, no conditions, and no routing to alternatives such as get_gas_comparator, get_gas_metrics, or get_gas_history_export. The second sentence is promotional (free via MCP, paid endpoint) rather than usage direction.

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 explicitly discloses retry-with-backoff and last-known-good cache fallback, so an agent understands the tool degrades gracefully rather than failing. It omits rate limits, auth requirements, and staleness bounds on the cached value, 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?

Two tight sentences, purpose front-loaded, no filler. The second sentence is partly promotional (paid endpoint) but still conveys a real deployment trade-off.

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 exist, yet the description states what is returned (ETH/USD price), how failures are handled, and the cost model. It lacks only the precise return shape (e.g., quote currency, decimals, timestamp), which a caller would want given there is no output schema.

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 optional parameter and schema description coverage is 100%, so the schema already fully documents simulateFailureRate. The description adds no additional parameter meaning, which is the expected baseline when the schema does the work.

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+resource ('ETH/USD price') and even discloses the retrieval mechanism (retry-with-backoff plus last-known-good cache fallback), which is more than a bare restatement. It does not differentiate against siblings like get_freshness_priced_data or get_market_snapshot, which could plausibly return overlapping price data.

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 implies usage by noting the MCP route is free and a pay-per-call URL exists 'for production/agentic use', which is a soft cue about context. However, it never says when to prefer this tool over the sibling price/market tools, nor any prerequisites or exclusions.

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 it does disclose the two data sources and the free-vs-paid access model. However, it does not state read-only nature, permissions, rate limits, or output format, leaving significant behavioral context unstated.

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 description is two sentences, front-loading the core purpose before adding the pricing/access note. It is efficient, though the second sentence is more about distribution than invocation.

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 simple one-parameter read tool, the description gives a reasonable idea of what the score represents and where it comes from. But with no output schema and no annotations, it should explain the return value or format more fully, and it omits sibling differentiation.

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, address, and the schema already provides a 100% coverage description ('Address to score.'). The description adds no additional semantic detail about the parameter, 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 clearly states the resource: a trust score derived from on-chain activity and an internal ledger of settled payments. It does not name or distinguish itself from any sibling tool, so it stops short of a 5.

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 mentions that the tool is free via MCP while the same data is pay-per-call elsewhere, which is an access note rather than usage guidance. It gives no indication of when to use get_reputation instead of siblings such as enrich_address or get_attestation_log.

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 must carry the behavioral burden. It discloses that output is converted from rendered HTML into clean, tag-free JSON and that the MCP channel is free, but it omits auth, rate limits, error handling, and whether the operation is purely read-only. These gaps are moderate for a simple lookup 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?

The description is two compact sentences with the core purpose front-loaded. The cost-channel note is relevant and does not bloat the text. Every sentence contributes useful context.

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 simple one-parameter read tool with no output schema, the description explains the return format (clean, tag-free JSON) and the scope (lead section). It does not describe the JSON fields or error behavior, but it is nearly complete for correct invocation.

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% for the single 'title' parameter, so the schema already documents its meaning. The description adds no syntax, format, or interpretation details beyond what the schema provides, making the baseline 3 appropriate.

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 resource (Wikipedia article lead section) and the output transformation (rendered HTML into clean, tag-free JSON). It does not name a verb like 'fetch' or 'get', but the name and title make the action obvious. Sibling tools are unrelated, so no differentiation is needed.

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?

The description gives cost-channel context: free via MCP and pay-per-call via a URL for production/agentic use. It does not state when to use this tool versus alternatives or any prerequisites. Usage is implied by the resource type, but explicit when/when-not guidance is absent.

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?

No annotations are provided, so the description carries the burden. It adds real value by disclosing the signed EIP-191 attestation return type and the single-chain (Base) scope, plus the free-vs-paid channel. It omits auth requirements, rate limits, failure/error behavior, and what happens for unconfirmed hashes.

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?

Two sentences, front-loaded with the capability before the pricing/channel aside. The second sentence borders on marketing but does convey the free-vs-paid access model, which is actionable.

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 one-parameter tool with no output schema, the description is fairly complete: it names the chain, the check performed, and the return payload. It still leaves the relationship to verify_tx_multi_source and failure semantics unstated.

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?

With 100% schema coverage on the single txHash parameter, the schema already documents the '32-byte transaction hash' format. The description adds no format, encoding, or validation nuance beyond it, so baseline 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?

States a specific verb ('Checks'), resource ('Base transaction hash'), scope ('confirmed on-chain'), and return value ('signed EIP-191 attestation'). It does not, however, distinguish itself from the sibling verify_tx_multi_source, which an agent could easily confuse it with.

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?

The 'Free via MCP' versus pay-per-call note gives channel/pricing context, but it never says when to choose this tool over verify_tx_multi_source or when the single-source check is sufficient. Usage is implied rather than guided.

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 it does disclose meaningful behavior: parallel checks against 3 independent providers and the consensus rule ('only signs an attestation if all agree'), plus the cost model. It omits what happens on disagreement (error vs partial result) and any rate limits, keeping 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?

Core function and consensus rule are front-loaded in a tight first clause. The second sentence is somewhat promotional (plugging a paid URL) but still conveys a legitimate routing fact, so it mostly earns its place.

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 simple one-param oracle with no output schema, the description covers purpose, consensus behavior, and cost. It stops short of describing the returned attestation's shape or the disagreement outcome, which an agent would need for robust use, but the gap is modest.

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 fully documented there, so the baseline is 3. The description adds only the chain scoping ('Base tx hash'), which is a marginal gain over the schema's generic '32-byte transaction hash'.

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 specific verb+resource ('Checks a Base tx hash') and the distinguishing mechanism ('3 independent RPC providers in parallel'), which cleanly separates it from the sibling verify_tx. An agent can tell what this does without opening the 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?

It implies a free-vs-paid usage split ('Free via MCP; ... also available pay-per-call ... for production/agentic use'), giving some routing context. However, it never states when to choose this over the sibling verify_tx or any other alternative, so usage is only implied.

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