x402-tools

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 well: it discloses billing ($0.02/call over x402/USDC, charged only if the image is delivered), auth (no API key, no account), latency (~2 seconds), and output lifetime (24-hour URL). These are exactly the operational facts an agent needs before invoking.

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 dense sentences, fully front-loaded with the core capability and model, followed by output handling, then cost/auth. No filler.

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 exists, yet the description covers the return shape (hosted URL valid 24h, optional base64), timing, and pricing, so an agent knows what it gets and what it costs. Nothing material is missing.

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 steps, inline, and prompt. The description reiterates the step range/default and the inline behavior but adds no syntax or format detail beyond the schema, making 3 the correct 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 specific verb (Generates), resource (1024x1024 JPEG from a text prompt), and names the exact model FLUX.1 [schnell]. An agent can distinguish this from ai_speech, ai_transcribe, and ai_translate immediately.

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?

Explains the practical workflow ('hand straight to the next tool') and how to get base64 via inline=true, but never explicitly contrasts itself with sibling AI tools such as ai_speech. Context is clear, exclusions are 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?

With no annotations, the description carries the full burden and does so richly: 1-2s latency, output format per language (MP3/WAV), 24-hour URL validity, size/base64 return, character limit, and the billing model. Crucially it discloses that payment is required via x402 USDC at $0.01/call with no API key, and that billing only occurs on delivery – exactly the behavioral facts an agent needs before invoking.

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 core purpose and packs a lot of useful detail into a tight paragraph. It is dense but nearly every clause (languages, engines, formats, cost) earns its place; a small deduction for the run-on pricing 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?

Despite no output schema and no annotations, the description specifies the return payload (hosted URL, validity window, size, optional base64), cost, and payment prerequisite – everything needed to call and interpret the result correctly.

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 lang, text, and inline are already documented in the schema; the description only restates text length and the inline/base64 behavior. Baseline 3 is appropriate since 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?

States a specific verb+resource (text-to-speech) plus the exact languages and the underlying engines (Aura-2 for en/es, MeloTTS for the rest). It is immediately distinguishable from the reverse-direction sibling ai_transcribe.

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 capability and the 2000-character/language constraints, but the description never compares against alternatives or states when-not to use it (e.g., vs ai_transcribe or ai_translate). The inline=true note is parameter guidance, 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 carries the full disclosure burden and does so well: it states the 10 MB limit, that you are charged only if the transcript is delivered, that no API key/account is needed, and the $0.02 x402 (USDC) payment model. Only minor gaps remain (no explicit rate limits or error 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?

Front-loads the core action and input modes, then layers return shape, language coverage, and pricing. Dense but every clause adds value; only the pricing sentence could arguably 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 4-param tool with no output schema and no annotations, the description covers inputs, formats, size limit, return payload (text, language+probability, duration, segments), optional word timestamps, language breadth, and cost. An agent has everything needed to call it correctly.

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 meaning beyond the schema: base64 audio is POST-only, words=true yields word-level timestamps, and language is an optional ISO code to skip detection. This meaningfully augments the field docs.

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 (transcribes) and resource (audio file) and pins the exact engine (Whisper large v3 turbo). This clearly distinguishes it from siblings like ai_speech and ai_translate without needing to open any 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?

Explains the two invocation modes (https URL or base64 via POST) and the words=true option, giving practical context for calling it. It stops short of naming when to choose this over ai_speech or ai_translate, so it is clear context without explicit alternatives.

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 richly: it discloses the 2000-character cap, sentence-level splitting that preserves order and line breaks, that billing occurs only if the translation is delivered, the $0.005 price, the x402/USDC payment path, and that no API key or account is needed. These are exactly the traits an agent needs to invoke a paid metered tool safely.

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 purpose and the two core arguments before secondary facts, and each later sentence (chunking, limits, pricing, auth) carries real information. It is on the long side, but virtually every sentence earns its place for a paid external API call.

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?

Covers constraints, cost, and auth for a 3-parameter tool with no output schema and no annotations, which is the right coverage level. It does not describe the response shape at all (no output schema to lean on), leaving a small gap about what a delivered translation looks like.

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 baseline is 3, and the description largely restates the schema (target as ISO code or English name; source detected when omitted) rather than adding new syntax or format detail. The 'es, fr, de, zh, ja' examples appear in both places, so marginal added value only.

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 and resource ('Translates text') plus the engine (Meta M2M100 1.2B) and scope (~100 languages), which cleanly distinguishes it from siblings like ai_transcribe and ai_speech. 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?

Gives a concrete workflow cue ('Pairs with speech-to-text: translate a transcript, then read it aloud') and explains source auto-detection, so the agent knows the typical context. It stops short of explicit when-not guidance or naming alternatives (e.g. llm_completion could also translate), so it is clear context without 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 burden. It discloses that the call is free, what the catalog includes, and the 402-retry context. It does not describe the response structure, but the content promise is clear and behaviorally useful.

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 most important fact ('FREE, no payment needed'), then the full scope, then a direct call-to-action for HTTP 402. Every sentence 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 zero-parameter, no-output-schema catalog tool, the description tells the agent what it returns, why it is valuable, and when to call it. Nothing required to invoke it correctly is missing.

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 has zero parameters, so the schema is empty and the description correctly adds no parameter detail. The baseline of 4 applies, and the description adds relevant invocation context without needing parameter explanations.

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 purpose: listing all 66 tools with examples, costs, and payment details. It clearly distinguishes itself from sibling tools by being the meta-tool that documents them.

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 an explicit trigger: 'Call this first if a tool answered HTTP 402.' It also implies use for discovering examples and pricing, though it does not elaborate on when to use other tools—mostly unnecessary for a catalog.

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 burden and does meaningful work: it discloses the cost ($0.005 per call), the payment mechanism (x402/USDC), and the qualitative nature of the output ('short, concrete and usable - not a fortune cookie'). It doesn't mention rate limits or error behavior, but the pricing/auth disclosure is valuable non-schema context.

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 the core purpose, then constraints, then cost, in three tight sentences with no waste. Every clause earns its place and the reader gets the essential facts first.

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 content tool with no output schema and no annotations, the description covers what is returned, the language scope, the filtering/repeat-avoidance mechanics and the billing model. Only marginal gaps remain around exact response shape, which is low-stakes here.

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 seed, topic, exclude and language in detail. The description restates the parameter roles (topic filter, id to avoid repeats, seed for reproducibility) without adding syntax or format meaning beyond the schema. 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?

The description states a specific verb+resource: returns one piece of practical advice about work, life or money. It distinguishes itself implicitly from content siblings (content_fact, content_joke, content_riddle) via the 'advice' domain, but never names an alternative to route between them. Clear and specific, just short of explicit sibling differentiation.

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: fetch a random-ish piece of advice, optionally filtered by topic, excluding seen ids. No explicit when-to-use/when-not or comparison to the other content_* tools is given. Adequate but leaves the agent to infer 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?

With no annotations provided, the description carries the full burden and does well: it discloses deterministic behavior via seed, that an id is returned for de-duplication, and the payment model ($0.005 per call over x402/USDC). It stops short of describing error behavior or exactly what fields come back beyond the id.

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 what the tool returns and followed by the practical facts (id, seed, price). The phrase 'Takes parameters' is minor filler, but nothing else is wasted.

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 stateless generation tool with no output schema or annotations, the description covers the important unknowns: return shape (an id), determinism, multi-language behavior, and cost/payment. Minor gaps remain around output structure and failure modes, but an agent can call it correctly.

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 every parameter (seed, topic, exclude, language) is already documented in the schema. The description only loosely gestures at parameters ('takes parameters') and repeats the seed/exclude semantics already present, adding no new 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?

States a specific resource (one curious but true fact) with a clear scope (English or Spanish, filtered by four named topics). An agent can distinguish it from content_joke, content_riddle, and content_word_of_the_day without opening any 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?

The description hints at usage via the exclude/id mechanism ('avoid repeats across a session') and seed reproducibility, which guide how to call it. However, it never states when to choose this over the many sibling generators (joke, riddle, roast, advice) or any exclusions, leaving 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 full burden and does well: it discloses the split/joined return shape, the id-returned-for-deduplication behavior, seed reproducibility, and the $0.005 x402/USDC payment requirement, which is genuine agent-relevant context. It stops short of error/rate-limit behavior, so not 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 and output shape are front-loaded and each sentence carries new information (format, split behavior, id/seed, pricing). Slightly dense and the 'Takes parameters' clause is filler, but there is no meaningful 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?

With no output schema and no annotations, the description compensates by explaining the return structure (setup/payoff split plus joined), the id for dedup, and the payment model. Nothing critical for a correct call is missing, though richer failure/output detail would complete 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 coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: it links the returned id to the `exclude` parameter's purpose (avoiding repeats) and confirms seed reproducibility and the split output, tying parameters to intent rather than just restating types.

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 precise verb+resource+format (one two-sentence horror story) and enumerates the four themes and two languages, so its genre is unmistakably distinct from sibling content_joke, content_riddle, and content_roast. An agent knows exactly what artifact this returns.

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 real usage context — output is split so a narrating agent can deliver line-by-line, and a seed yields reproducibility — but it never says when to choose this over sibling generators or when not to use it. Clear context, no explicit 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 well: it discloses a paid endpoint ($0.005 per call over x402/USDC), that responses include an id, and that seeds yield reproducible results. It omits rate limits or failure behavior, 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?

Three tight sentences: purpose first, differentiating behavior second, cost last. No filler, and the most decision-relevant facts (what it returns, what it costs) are front-loaded.

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-required-param, no-output-schema content tool, the description covers purpose, filters, return shape (id), reproducibility, and payment. Only the output format details (joke text field structure) are left implicit, which is a minor 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 coverage is already 100%, so the baseline is 3, but the description adds real meaning by linking the returned id to the exclude parameter ('returns an id so you can exclude what you have already seen') and by explaining seed reproducibility as 'same seed always returns the same joke.' That relational context is not in 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?

States a specific resource and scope: 'one random joke,' constrained by language (en/es) and category (programming, crypto, general). Combined with sibling names like content_fact and content_riddle, an agent can identify this as the joke generator 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?

Usage is implied through parameter-related context ('exclude what you have already seen,' 'reproducible answer') and a comparison to 'usual one-liner endpoints,' but there is no explicit when-to-use statement nor any routing guidance vs content_riddle/content_fact. Adequate but clearly gapped.

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 provided, the description carries the full burden and does disclose notable behavior beyond the schema: the answer hash is returned in lowercase, the hash-based verification mechanic, and the $0.005 per-call cost paid over x402 in USDC. It stops short of describing rate limits, failure modes, or exactly how the hash enables verification in practice.

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 sentences, front-loaded with what is returned and then why the hash matters. The middle sentence leans slightly promotional ('which no other riddle endpoint lets you do'), but every sentence still carries real 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?

No output schema exists, so the description must cover return values, and it does: riddle, answer, and lowercase SHA-256 hash. Pricing and payment rail are also disclosed. It is largely complete for a zero-required-parameter content tool, with only minor gaps such as failure behavior when exclude filters exhaust the pool.

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 seed, exclude, language, and difficulty including enum-like defaults. The description only echoes the language and difficulty axes at a high level, adding no syntax or format detail beyond the structured fields, which fits the baseline 3.

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 and resource (one riddle by difficulty, in English or Spanish) and explicitly differentiates itself from other riddle endpoints by returning a checkable SHA-256 hash. An agent can tell this apart from content_joke, content_fact, and content_advice 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?

The description gives a clear usage context: the hash lets an agent verify a guess without reading the solution first. It implies when the tool is valuable (answer-checking workflows) but does not state exclusions or alternatives, though no sibling riddle tool exists to route to.

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 load and does well: it discloses cost ($0.005 per call), the payment mechanism and auth implication (x402/USDC), determinism ('seedable') and repeat avoidance. It does not state rate limits or describe the response shape, but the safety profile is effectively non-destructive and conveyed via tone.

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 front-loaded sentences: what it returns, why it beats siblings, then the operational facts (bilingual, seedable, price). Each sentence earns its place, though 'Bilingual, seedable and repeat-free' is a slightly compressed feature dump.

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?

Five optional parameters, no output schema and no annotations, so the description must cover behavior and economics – it does cover payment, target, severity and language behavior. The only gap is the absence of any hint about the returned payload's shape, which is the sole unexplained dimension for a novelty endpoint.

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 target, seed, exclude and language are already documented structurally; the description restates the target list and severity rather than adding format or behavior beyond it. Baseline 3 applies 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?

States a specific verb+resource ('one lighthearted developer roast') and immediately names the parameterizable target list, so the agent knows exactly what it gets. It also distinguishes itself from the other roast-style siblings by contrasting with 'every other roast endpoint [that] returns something generic'.

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 a concrete use scenario ('a code-review agent roast the actual stack in front of it') that clarifies when this beats a generic joke/horror_story sibling. It stops short of explicit when-not conditions or naming specific alternatives by tool name, but the context is unambiguous.

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 discloses the deterministic UTC-date selection, reproducibility of past days, and a concrete cost/payment model ($0.005 per call over x402/USDC). This is real behavioral context an agent needs to call it. Only rate limits and failure behavior are 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?

Four sentences, front-loaded with what you get and the key differentiator (determinism), with pricing last. Each sentence earns its place, though the 'usual endpoints' jab is marginally marketing-flavored 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 exists, yet the description names the return fields (definition, part of speech, example sentence), and covers determinism, language options, and cost. For a zero-required-param lookup tool this is essentially complete, missing only edge behavior (e.g., invalid dates, response format).

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 both 'date' (YYYY-MM-DD, UTC, defaults to today) and 'language' (en|es, defaults to en) are already fully documented. The description reinforces reproducibility and the language options but adds no syntax or format detail beyond the schema. 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+resource ('the word of the day') plus the exact return payload (definition, part of speech, example sentence), and differentiates itself from generic random-word endpoints. An agent can distinguish it from siblings like content_joke or content_fact 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?

Explains the determinism/reproducibility use case ('you can reproduce any past day by passing it') and contrasts against endpoints that return a random word, which is clear context for when this is the right tool. It stops short of naming a sibling alternative, but no sibling here serves the same purpose, so guidance is effectively complete.

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: exact-match-only behavior, list-entry response rather than risk score, snapshot publication date on every answer, no API key/account, and a concrete pricing/payment mechanism. These are precisely the traits an agent needs 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?

Six compact sentences, each carrying a distinct fact — coverage, response shape, matching mode, provenance, auth, cost. No repetition and no filler.

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 tool with no annotations, the description covers what it does, how it matches, what it returns, data freshness, auth requirements, and payment. Nothing an agent needs to call it correctly is missing.

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 schema does the heavy lifting. The description adds currency breadth ('16 currencies including Ethereum, Bitcoin, Tron, USDT'), which is useful context but doesn't extend parameter semantics 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?

States a specific verb and resource ('Checks one crypto address against the OFAC SDN list'), names the source (US Treasury), and scopes the answer format ('a hit returns the actual list entry, not a risk score'). No sibling tool overlaps with sanctions screening, and the description makes its distinct purpose unmistakable.

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?

Clearly frames the screening context and what a hit means, and states 'Exact matching only, never fuzzy,' which tells the agent when results will and won't appear. It doesn't explicitly name a contrasting sibling, but no sibling could be confused with OFAC screening, so an exclusion is unnecessary.

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 delivers unusual value: the underlying method (eth_getBalance), the absence of rate limits and API keys, the flat pricing, and the x402/USDC payment requirement. It does not cover failure modes (invalid address, unsupported chain) or whether the returned value is wei/hex, so it falls 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?

Three short, front-loaded sentences with no filler; capability first, then operational constraints, then the underlying RPC method and cost. 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?

For a two-parameter read tool with a fully documented schema, the description covers capability, chains, and the payment/access model. The only meaningful omission is the shape of the returned balance (wei vs. decimal string), which matters since 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?

Schema description coverage is 100% and both parameters are documented in the schema, so the baseline is 3. The description's chain list duplicates the enum-style values already given in the chain property and adds no format or syntax detail beyond 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?

States a specific verb+resource (native coin balance for any address) and enumerates the supported chains, making it clearly distinct from the sibling evm_erc20_balance and evm_token_info. An agent can route to it 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?

The description establishes context (multi-chain native balance, no API key, flat price) but never says when to prefer this over evm_erc20_balance, evm_portfolio, or evm_chains, nor what conditions exclude it. Usage is implied by the resource name rather than stated.

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 disclose non-obvious traits: the cost model ('$0.005 per call') and the payment rail ('x402 (USDC)'), plus the underlying RPC method. It omits what happens if 'chain' is omitted (default chain?) and any error behavior for unsupported chains, so it is strong but not complete.

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 short sentences, each earning its place: return values first, then the decision it supports, then implementation and pricing. Front-loaded and free of filler.

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 must carry everything, and it does explain the returned fields and cost. The remaining gap is behavior when 'chain' is absent and error handling for invalid chains, which an agent would still need to discover.

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 sole parameter's allowed values (base | ethereum | polygon | arbitrum | optimism) are already in the schema. The description adds only the phrase 'any supported chain', which hints at the domain but not at default behavior when the optional parameter is omitted. 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 resource and the exact values returned ('latest block height and timestamp', 'how old the chain head is in seconds'), and grounds it with the underlying RPC method (eth_getBlockByNumber). An agent can distinguish this from siblings like evm_chains (lists chains), evm_tx, or evm_fees without opening any 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?

Gives a clear usage context: 'Tells an agent whether a node is in sync,' which is exactly the decision this tool supports. However, it names no alternatives (e.g., evm_chains for enumerating supported chains) and states no when-not-to-use condition, so it stops short of explicit routing 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?

No annotations, so the description must carry the burden, and it does disclose key behavioral traits: read-only only, five chains, no API key, no rate limit, and a concrete price ($0.005 via x402/USDC). It does not mention auth mechanics for x402 payment or what happens on revert, 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?

Three tight sentences, front-loaded with what it does, then the differentiator, then the cost. Zero filler; 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?

Complete enough for an agent to invoke: purpose, scope, chain options (in schema), and payment model are covered. With no output schema, the description still doesn't describe the return format beyond 'raw result,' and x402 payment flow isn't explained – minor gaps against a 5-param, no-annotation 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 schema already documents every parameter (to, data, from, block, chain). The description adds only the 'your own calldata' framing, which is useful but doesn't extend beyond the schema's own definitions. Baseline 3 is 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?

States a specific verb (runs a read-only eth_call), the exact resource (raw contract call with your own calldata), and the return (raw result). The line 'The escape hatch for anything the typed endpoints do not cover' sharply distinguishes it from the many typed evm_* siblings like evm_erc20_balance and evm_storage.

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?

Clear context: use this when the typed endpoints don't cover a call, i.e., when you have raw calldata. It implies the alternative (typed siblings) but doesn't name any specific one or spell out exclusions such as calling write methods.

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 reveals the underlying eth_getBlockByNumber call, the semantic meaning of the output (head staleness), and the cost/payment model ($0.005 per call over x402/USDC). It omits rate limits and error behavior, but the cost and method disclosure is unusually valuable.

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, then use case, then method and price. Four short clauses, each earning its place with zero filler.

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 exists, so the description properly explains return values (chain id, block height, staleness). For a zero-required-parameter health check, nothing an agent needs to invoke it correctly is missing.

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 optional parameter and schema coverage is 100%, so the schema already documents the chain filter and its valid values. The phrase 'every supported chain in one call' weakly mirrors the omit-to-get-all behavior but adds no syntax or meaning beyond the schema, 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 resource and scope ('Live health of every supported chain in one call') and enumerates the returned fields (chain id, block height, staleness). It is clearly distinguishable from single-chain siblings like evm_block or evm_fees because it aggregates health across all chains.

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?

Provides a clear use case: 'Use it to pick a chain that is actually responding.' That is actionable context, but it names no alternative tool and states no when-not-to-use conditions, so it falls short of explicit routing 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 data source (Ethereum mainnet, read directly) and the paid-over-x402 cost model at $0.005/call, which matters for invocation. It omits failure behavior: what happens when a name is unregistered or an address has no reverse record, and whether results can be stale.

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 core action is front-loaded in the first sentence, with cost/source detail trailing. The middle sentence ('Names are what humans paste...') is rhetorical but does clarify the practical purpose; only mild trimming is possible.

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 exists, yet the description never states what is returned (an address string, a primary name, or nothing when unresolvable). For a tool with two optional parameters and zero required ones, it also leaves the 'supply exactly one' contract unstated, though the source and pricing context are covered.

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. The description adds only the reverse-resolution meaning of the address parameter ('an address back to its primary ENS name'), which is modest value on top of the schema's own 'Use instead of name' note.

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 verb (resolves) and resource (ENS name) and covers both directions of resolution (name→address and address→primary name). No sibling in the evm_* family does ENS resolution, so an agent can distinguish it immediately.

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 implies the use case (converting between human-readable names and chain-usable addresses) and notes it reads Ethereum mainnet directly. However it never states when to prefer one direction, nor routes the agent away from an alternative, and gives no guidance that exactly one of name/address should be supplied.

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 discloses the underlying mechanism (eth_call to the allowance method), the pricing model ($0.005 per call paid over x402 in USDC), and the two-part return (remaining amount plus an unlimited flag). It omits rate limits and any failure/error behavior, 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?

Three sentences, front-loaded with the core question the tool answers, then usage context, then mechanism and cost. Every sentence carries information, though the 'finds forgotten infinite approvals' phrasing is slightly promotional rather than strictly functional.

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 exists, and the description compensates by explaining what is returned (remaining allowance and unlimited-approval status). Combined with the transport and payment details, an agent has enough to call it correctly; error handling and rate limits 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?

Schema description coverage is 100%, so owner, spender, token and chain are already documented in the schema. The description reinforces the owner/spender relationship conceptually but adds no syntax, format, or default guidance beyond what the schema provides — the baseline 3.

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: reads the ERC20 allowance a spender has over an owner's tokens, and additionally reports whether the approval is unlimited. This clearly distinguishes it from sibling readers like evm_erc20_balance and evm_token_info.

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 concrete usage context — 'the check to run before an approve' and 'the one that finds forgotten infinite approvals' — which tells the agent when this tool is the right one. It does not explicitly name an alternative tool to use instead, but the intended scenarios are clear.

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 reasonable work: it discloses the read-only mechanism (eth_call / balanceOf), the return shape (raw amount plus decimals), and a concrete cost model ($0.005 per call via x402/USDC). It doesn't state chain defaults or failure behavior for invalid contracts, but the cost and mechanism disclosure is genuinely useful context beyond 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?

Front-loaded with the core purpose, and every sentence adds something. Minor redundancy in repeating the eth_call/balanceOf mechanism twice, but the pricing and return-format notes are justified.

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 3-parameter read tool with full schema coverage but no output schema, the description usefully describes the return value (raw amount + decimals) and the cost, which is what an agent would otherwise lack. Leaving the chain parameter's default unstated is the main remaining 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%, so the schema already documents chain, token, and address. The description only adds token examples (USDC, USDT, DAI) without explaining the chain parameter's default or valid range, so it sits at the baseline for high-coverage schemas.

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 and resource — fetch the ERC20 balance for a wallet — and pins the mechanism (balanceOf via eth_call). The 'ERC20' qualifier implicitly separates it from evm_balance (native) and evm_erc20_allowance, but no sibling is named explicitly, so the differentiation is inferred rather than stated.

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/when-not guidance and no named alternative. The list of sample tokens (USDC, USDT, DAI) implies the tool is for token lookups, but an agent gets no help deciding between this, evm_balance, evm_erc20_allowance, or evm_token_info.

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 burden and does well: it discloses the cost ($0.005 per call), the payment/auth rail (x402 USDC), and the underlying method (eth_estimateGas), and implicitly confirms nothing is signed. It does not disclose return shape or revert-error behavior, which keeps 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?

Three compact sentences with the core capability front-loaded, then the cost/payment mechanism. Every sentence earns its place with no filler.

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 read-only estimation tool with no annotations and no output schema, the description covers purpose, cost, and rails, and implies the return (gas estimate plus price). It could say more about what a revert response looks like, but it is otherwise sufficient.

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 all five parameters (to, data, from, chain, value) are already documented in the schema. The description adds no format or semantic detail beyond what the schema provides, making the baseline 3 correct.

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 ('Estimates the gas a transaction would need') and adds scope ('before you sign anything', 'find out that a call would revert') that separates it from evm_gas and evm_call without naming them. The purpose is unambiguous, though explicit sibling naming would push this to 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?

'before you sign anything' and 'cheapest way to find out that a call would revert' give clear when-to-use context. No alternatives (e.g. evm_call or evm_fees) are named, and there are no when-not cases, 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 does add real operational context: exact cost ($0.005 per call), the payment rail (x402/USDC), the data source and window (eth_feeHistory, last 20 blocks), and the percentiles returned. It does not cover failure modes (e.g. unsupported chain, payment failure), 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?

Three tight sentences, front-loaded with what is returned and followed by why it matters and the operational facts. The '$0.005 per call, paid over x402' line is dense but earns its place as cost transparency; nothing is filler.

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 so concretely (two fee fields, three speed percentiles). Cost, source, and payment method are covered; the only meaningful gap is sibling differentiation against evm_gas/evm_estimate_gas.

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 chain parameter has its allowed values documented inline in the schema, so the schema carries the semantics. The description says nothing about chain, but with full schema coverage that is an acceptable 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?

It states a specific resource and outputs (maxFeePerGas and maxPriorityFeePerGas from the last 20 blocks, at slow/normal/fast percentiles) and names the upstream RPC method (eth_feeHistory). It is clear what the tool returns, but it never distinguishes itself from siblings evm_gas or evm_estimate_gas, leaving ambiguity about which fee tool 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?

'Beats guessing a gas price and getting stuck in the mempool' gives an implied motivation for using it, and the stated price signals a paid premium path. But there is no explicit when-to-use/when-not and no reference to evm_gas or evm_estimate_gas, which are the obvious alternatives an agent must weigh.

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 does disclose the upstream call (eth_gasPrice) and a pay-per-call model at $0.005 via x402/USDC, which is genuinely useful cost context. It does not state caching freshness, rate limits, default chain behavior when the optional chain is omitted, or fallback behavior for unsupported chains.

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 what is returned before the audience note and pricing. No filler; each sentence adds something (outputs, audience, cost).

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 read tool with high schema coverage and no output schema, the description covers outputs, units, the upstream RPC method, and pricing. It omits default-chain behavior and freshness, which keeps it short of complete.

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 chain parameter already enumerates valid values in the schema, so the description need not repeat them. The description adds nothing about what happens when chain is omitted, though that is a meaningful gap for an optional parameter.

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 (current gas price and base fee) and scope (any supported chain), with units (wei and gwei) and an extra output (plain transfer cost estimate). It does not name or distinguish itself from the close siblings evm_estimate_gas, evm_fees, or evm_block, which an agent would need help choosing between.

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?

'For agents planning a transaction' implies a use case but gives no when-not conditions and never routes toward evm_estimate_gas or evm_fees, which are the obvious alternatives for a similar question. Usage context is implied rather than specified.

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 a good job: it discloses the underlying method (eth_getCode), the nature of the result (contract vs wallet plus bytecode size), and cost/payment model ($0.005 per call over x402/USDC). It omits read-only framing, latency, and failure behavior, so not a 5, but far above baseline.

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 sentences, tightly front-loaded: what it returns first, then the use case, then the mechanism and price. Every sentence adds information with no waste.

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 ('contract or wallet' and bytecode size). Pricing and payment rails are also given, leaving nothing an agent needs before invoking 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%, so the schema already documents both the address and chain parameters. The description adds the eth_getCode reference but no syntax, format, or chain-default guidance, so the baseline 3 is 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?

States a precise verb+resource: determines whether an address is a contract or a plain wallet and how large its bytecode is. This is clearly distinguishable from siblings like evm_balance, evm_call, or evm_token_safety without opening any 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?

Gives a concrete when-to-use: 'a cheap safety check before sending funds,' which frames the intent well. It does not explicitly name an alternative tool or state exclusions, so it falls short of a full 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?

No annotations are provided, so the description carries the burden. It discloses useful behavioral details: it uses eth_call (ownerOf), costs $0.005 per call, and payment is over x402 (USDC). It does not state error behavior for non-existent tokens or non-ERC721 contracts, and does not mention rate limits.

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 front-loaded with what the tool returns, then follows with the key usage benefit and implementation/payment details. Every sentence is relevant and there is no filler.

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 3-parameter read-only call with no output schema, it covers the return values (owner, tokenURI, collection name), the call mechanism, pricing, and the operational benefit. It lacks explicit error-handling or failure-mode notes, but is otherwise complete for an agent to invoke it correctly.

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 documents contract, tokenId, and chain. The description adds no extra parameter meaning beyond what is in the schema, which sets the baseline at 3.

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 precise verb and resource: it returns the owner of a given ERC721 token id plus tokenURI and collection name in one call. It distinguishes itself from siblings like evm_token_info and evm_token_safety by explicitly returning NFT ownership data via ownerOf.

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 clear context (answering whether an NFT is still owned by someone) and notes it requires no indexer or API key, which helps an agent choose it over indexed alternatives. However, it does not name a specific sibling alternative or state when not to use it.

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 a good job: it discloses the upstream method (eth_getTransactionCount), the cost ($0.005 per call), and the payment rail (x402/USDC). It omits edge-case behavior such as what nonce is returned for an address with no history and any rate limits.

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?

Four short sentences, each earning its place: core function, use-case, backend source, and pricing. The primary purpose is front-loaded with no filler.

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 two-parameter read operation with no output schema, the description supplies the return values, the use case, the data source, and cost/payment details an agent needs before calling. Nothing material is missing.

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 both parameters are already documented, and the enum-like chain list lives in the schema. The description adds no syntax, format, or default details for chain or address, so the 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?

The description names a specific verb+resource ('Next transaction nonce for any address') and adds a second return value (contract detection). It is clear, but the contract-detection clause overlaps with the sibling evm_is_contract, so an agent gets no explicit guidance on which to prefer, which slightly weakens differentiation.

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?

'What an agent needs before signing a transaction' gives a concrete usage context that routes the agent to the right moment in a workflow. It stops short of naming alternatives (e.g., evm_is_contract for the boolean alone) or stating when-not to use it, so it is clear context without 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 burden and does disclose key traits: the $0.005 cost paid over x402 with USDC, and the internal mechanics (eth_getBalance + eth_call). It omits error/edge behavior for invalid token addresses and any rate limits, but the payment requirement is meaningful behavioral context rarely found elsewhere.

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 tightly packed sentences: what it returns, why it beats per-token calls, its internal method, and its cost. Front-loaded with the capability, no filler, every clause 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 does describe the return shape at a useful level (balances with symbol and decimals already applied). It does not clarify whether the native balance is returned separately from the token array or the exact response structure, leaving a small gap for a tool with this many tokens returned.

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 address, chain options, and the up-to-20 token array. The description reinforces 'on one chain' and 'every token you list' but adds no format or constraint detail beyond the schema. Baseline 3 is 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?

States a specific verb+resource: native balance plus balances of listed tokens on one chain in a single call. The phrase 'One request instead of one per token' implicitly distinguishes it from the per-token siblings like evm_balance and evm_erc20_balance. An agent can identify what this tool uniquely does without opening any 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?

Clearly frames the usage context: batching many token lookups into one paid call rather than one per token, which implies when it is preferred. It does not name alternative tools or state explicit when-not conditions (e.g., use evm_balance for native-only), so it falls short of 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 present, the description carries the full behavioral burden, and it does add real context: the upstream method (eth_getTransactionReceipt) and the pricing model ($0.005 per call, paid over x402 in USDC). It omits handling of pending/unknown hashes (what happens if the tx isn't mined yet), which is the main remaining behavioral 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?

The content is front-loaded: the return payload comes first, then the identification of the underlying endpoint. It is short overall, though the fragment "The call that answers did my transaction work" is grammatically loose and slightly filler-ish rather than essential 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 correctly spends its words describing what comes back (status, gas used, fee, log count). Combined with the 100%-covered input schema and the disclosed cost/RPC backend, an agent has enough to call it correctly. Only pending-transaction behavior and the supported-chain set are 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?

Both parameters (hash, chain) are already fully described in the schema at 100% coverage, so the schema does the heavy lifting. The description adds no syntax, format, or default guidance for hash or chain beyond what the schema provides; 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?

The description names the resource (transaction receipt) and enumerates what it returns: success/revert status, gas used, fee paid, log count. That is far more specific than a tautology and lets an agent distinguish it from evm_tx. It stops short of 5 because it never explicitly contrasts itself with the closest sibling, evm_tx.

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 call that answers did my transaction work" implies usage but is informal and doesn't state prerequisites or exclusions. It does not tell the agent when to prefer evm_tx (raw transaction data) over this receipt endpoint, which is the obvious ambiguity given the sibling list. Usage is implied, not 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?

No annotations are provided, so the description carries the full burden, and it discloses valuable operational context beyond the schema: the underlying eth_getStorageAt mechanism and the pricing/payment model ($0.005 per call over x402 in USDC). It still omits edge-case behavior such as what is returned for an empty/unset slot.

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 the core action and use case, then mechanism, then cost; nothing is redundant. The middle sentence is a sentence fragment ('How you inspect...') that reads slightly awkwardly, but the information density is high.

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 must convey the return shape, and it does so by stating the slot is decoded as hex, integer, and address. For a single-slot read across multiple chains, this is close to complete, though error/empty-slot behavior remains 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?

Schema description coverage is 100%, so the slot, chain, and address parameters are already fully documented in the schema, including the decimal-or-0x-slot-key nuance. The description adds decoding-format detail (hex/integer/address) but nothing about parameter syntax beyond the schema, making the baseline of 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?

States a specific verb and resource: reads a raw storage slot of any contract, with the decoding formats named. It is clearly distinguishable from evm_call, evm_balance, and evm_erc20_balance, which read higher-level state rather than raw slots.

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 a concrete when-to-use case (proxy implementation slots, owners, paused flags with no public getter), which explains why an agent would reach for raw storage instead of a typed read. It does not, however, name a specific alternative sibling or an explicit when-not-to-use condition.

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 delivers: 'Via eth_call' discloses a read-only mechanism (no state mutation), and the explicit '$0.005 per call, paid over x402 (USDC)' warns of cost and payment requirements. It stops short of an explicit read-only statement or error/revert 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?

Three short, front-loaded sentences: the return payload leads, the use case follows, and operational details (mechanism, price) are compressed into the tail. No filler.

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 by enumerating returned fields and disclosing mechanism plus cost. It is nearly complete, lacking only error behavior and multi-chain nuance for the optional 'chain' parameter.

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 both parameters (chain, token) are fully documented in the schema. The description adds no format or syntax detail for either parameter, so the 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?

The description states a specific verb+resource ('Name, symbol, decimals and total supply of any ERC20 contract') and names the exact returned fields, distinguishing it from siblings like evm_erc20_balance (balances) and evm_token_safety (safety checks). An agent can tell what it returns 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 gives a concrete usage context ('Useful to label a token address before showing it to a user'), which tells the agent when this is the right call. It does not name alternatives or state when-not to use it, but the scenario is clear enough.

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 the data source (deepest Uniswap V3 pool via eth_call), the chains covered, the fields returned for auditability, and a concrete cost/payment mechanism ($0.005 per call over x402 in USDC). Missing only failure behavior when no pool exists and rate/latency characteristics.

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 the core purpose and source, followed by return fields, trust/cost notes. Dense but each sentence contributes (source, chains, auditable outputs, cost). Only slightly packed with the x402/payment detail in the same breath as the technical source.

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 3-param read with no output schema, the description itself enumerates returned fields (pool address, fee tier, liquidity, sqrtPriceX96, tick, block) and the pricing model, which is what an agent needs. It stops short of documenting no-pool failure modes, the one gap given the absence of annotations and 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?

Schema description coverage is 100%, so the schema already documents chain, quote, and token; the baseline is 3. The description adds minor context (quote defaults to USDC, token is an ERC20 contract) but no syntax, format, or edge-case guidance beyond what the schema 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?

States a specific verb (reads spot price) and resource (any ERC20), plus the exact source mechanism (deepest Uniswap V3 pool against USDC) and supported chains. This clearly separates it from sibling reads like evm_token_info, evm_balance, or evm_erc20_balance, which return metadata/balances rather than a priced quote.

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 conveys context (no aggregator, no API key, on-chain source) so an agent can infer this is the price tool, but it never explicitly names alternatives or states when NOT to use it, e.g. for tokens with no V3 pool or on unsupported chains. Usage is implied rather than routed.

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 disclosure burden and does well: it states determinism ('same contract, same answer'), that output is evidence (exact selector and byte offset) rather than a verdict, and the commercial terms ($0.01 per call over x402 USDC). It does not cover failure/error behavior for unsupported chains or invalid addresses, leaving some gaps.

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?

Four tight sentences, front-loaded with the purpose, then capabilities, then the differentiator, then pricing. Every sentence adds information an agent needs; no filler or repetition.

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 two-parameter read-only tool with no output schema, the description explains what comes back (selector evidence plus offset) and the cost model, which is substantial. Minor gaps remain around behavior on malformed input or unsupported chains, but nothing critical is missing.

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 both parameters are already documented, making 3 the baseline. The description restates the supported chains and the ERC20-address nature of the token parameter but adds no syntax, casing, or default-chain detail 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?

States a specific verb and resource ('Pre-trade risk check for any ERC20'), enumerates exactly what it detects (mint, pause, blacklist, proxy, mutable tax powers), and contrasts itself with 'LLM-written verdicts'. However, it never names or differentiates from its closest sibling, evm_token_info, which an agent could plausibly 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?

'Pre-trade' and 'an agent can apply its own policy' imply the usage context, so the when-to-use is inferable. But there are no explicit exclusions, no named alternative tool, and no conditions distinguishing it from evm_token_info or evm_call for contract inspection.

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 disclose two important traits: the underlying RPC method (eth_getTransactionByHash) and the paid-access model ($0.005 per call over x402/USDC), which an agent otherwise could not infer. It omits error behavior for unknown hashes and any rate/latency context, so it is not fully transparent.

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 short, front-loaded sentences with zero filler: what it returns, why to prefer it, how it is executed and billed. Every clause 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 usefully enumerates the returned fields, and it discloses the payment mechanism an agent must know before calling. It omits chain defaulting and failure behavior, but the core calling information is present.

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 both 'hash' and 'chain' are already documented in the schema; the description only reinforces 'by hash' and adds nothing about the chain parameter (default value, supported chain syntax). Baseline 3 applies 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?

Names a specific verb+resource ('Full transaction details by hash') and enumerates the returned fields (from, to, value, gas used, status, block), which crisply separates it from the sibling evm_receipt and evm_call tools that return only partial 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?

The phrase 'One call instead of two' tells the agent this replaces the transaction+receipt pattern, implicitly steering away from evm_receipt for this use case. It stops short of explicitly naming the alternatives or stating when NOT to use it (e.g. when only the receipt is needed).

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 present, the description carries the full burden and does so well: it discloses the once-daily cadence, reproducibility, the 90-day lookback limit, what the response contains (rate, publication date, euro-cross flag), and the cost/payment mechanism ($0.005 per call over x402 USDC). This is exactly the behavioral context an agent needs to pick and budget for the call.

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 core conversion scope, then stacks scope, return shape, positioning and price in three tightly packed sentences with little waste. Slightly dense, and the pricing sentence is arguably a separate concern, but every sentence carries 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?

For a 4-param, no-output-schema tool, the description covers inputs, the historical limit, the return shape, and the payment model, so an agent knows both how to call it and what it will get back. Nothing material to correct invocation is missing.

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 all four parameters (from, to, amount, date) are already documented, including the ISO 4217 format and the YYYY-MM-DD/90-day constraint. The description reinforces the currency family size and default-window behavior but adds no meaning beyond the schema, 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 and resource ('Converts an amount between any two of the ~30 currencies in the ECB's official reference rates') and pins the scope to a fixed daily publication rather than a live quote, which is what separates it from any market-rate tool. An agent can identify the tool's job 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?

Gives a clear when-to-use framing ('the auditable rate accounting and customs ask for') and an explicit when-not ('not a live market quote'), plus the 90-day historical window. It doesn't name an alternative sibling tool for live rates, so it stops short of full routing 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 and does disclose genuinely useful behavior: no account/API key, fixed $1.00 cost independent of token count, USDC payment over x402, automatic model failover, and sub-1s typical latency. It omits error/refund behavior on failure and the response payload shape, 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?

The $1.00 flat price is repeated three times ('$1.00 per call' at the start, mid-sentence, and again at the end), and 'no account/no API key/nothing to sign up for' is stated twice. Pricing marketing crowds out the functional statement.

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, so the description must cover everything; it covers cost, auth, and payment well but never describes what the completion response contains or what happens when inference fails despite failover. Adequate but with a clear gap for a paid, unauthenticated API.

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 explains prompt, sistema, and maxTokens. The description adds only one nuance beyond the schema: that maxTokens does not affect price, which the schema field also states. 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 the verb and resource ('LLM inference', 'POST a prompt, get the completion'), which is enough to distinguish it from the content_* siblings and the evm/util helpers. However, roughly half the text is pricing boilerplate, and it never says how it differs from the LLM-backed content_joke/content_riddle tools.

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?

No indication of when to choose this over the many content_* generation siblings, nor any when-not guidance. The closest thing to context is the metered-gateway comparison, which contrasts products rather than tools available to the agent.

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 provided, the description carries the full burden and does well: it discloses the randomness guarantee ('Cryptographically random, not Math.random') and the cost/payment model ('$0.005 per call, paid over x402 (USDC)'). These are meaningful behavioral facts beyond the schema. It still omits return format and per-call limits, 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?

It is short and front-loads the core action before secondary facts (randomness quality, use cases, pricing). The clause 'an agent has to decide on its own' is slightly vague and could be tightened, but nothing is padded.

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 tool with no output schema, the description covers purpose, randomness quality, cost, and example use cases. It lacks explicit detail on the return shape, but the scope is narrow enough that this is a minor 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%, with the count parameter fully documented (1-100, default 1). The description's 'one or more fair coins' only restates the schema, adding no new syntax or constraint detail, so the 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 and resource: 'Flip one or more fair coins and get heads or tails, with the tally.' An agent immediately understands the operation and result type. It does not explicitly distinguish itself from the nearby random_dice/random_number siblings, 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 names concrete use cases ('tie-breaks and A/B splits'), which implies when to reach for it. However, it offers no exclusions and does not route the agent to alternatives like random_number or random_pick, so guidance is inferred 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 burden and does well: it discloses the RNG mechanism (platform CSPRNG with rejection sampling), guarantees fairness per face, notes the non-deterministic nature of the output, and reveals pricing ($0.005/call via x402 in USDC). It stops short of detailing error behavior or latency, but the behavioral picture is unusually complete.

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 short sentences, front-loaded with the purpose and return value, then mechanism, then cost. The rejection-sampling remark is a slight detour but is short and justifies the fairness claim, so it 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?

A zero-required-parameter, non-deterministic tool with no output schema; the description compensates by describing the return (all rolls plus total), the fairness guarantee, and the payment cost. Little that an agent needs in order to call it correctly is missing.

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% (count 1-100 default 1; faces 2-1000000 default 6), so the schema already documents both parameters and the baseline is 3. The '3d6' notation adds only loose flavor, and it does not map cleanly onto the two separate count/faces fields.

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 and resource ('Roll dice with any number of faces') and explicitly names what is returned ('every roll plus the total'). The dice/faces framing differentiates it in substance from random_number or random_coinflip, though it never names those siblings directly.

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 choose this over the other random_* tools (coinflip, number, pick, shuffle). The only usage-flavored content is the notation example '3d6, 1d20', which is syntax rather than selection guidance, and there are no exclusions or prerequisites.

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 burden and does add real behavioral value: it discloses the sampling algorithm (rejection sampling → uniform ends, unlike modulo) and, importantly, a pricing/access trait ($0.005 per call paid over x402 USDC). It stops short of error or edge-case behavior, but the cost and uniformity disclosures are exactly the kind of non-structured context annotations would otherwise provide.

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 what the tool produces, then the uniformity guarantee and cost. Nothing is filler; the algorithm note is arguably more detail than needed but is not wasteful.

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 scalar-generator with 100% schema coverage and no output schema, the definition covers purpose, uniformity behavior, and cost. Return values are self-evident (numbers), so the only missing element is routing guidance against the sibling random tools.

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% with four well-annotated optional params (min/max/count/unique defaults and constraints all documented in the schema). The description adds no parameter syntax or format beyond that, so the 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+resource: 'Uniform random integers in any range you give, with or without repeats.' An agent can tell this generates arbitrary-range integers (unlike random_dice/random_coinflip, which are fixed domains), but the description never names those siblings, so the differentiation 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?

The phrase 'in any range you give, with or without repeats' implies the use case (arbitrary-range integers, optionally unique draws), but there is no explicit when-to-use guidance, no exclusion of the random_dice/random_pick/random_coinflip siblings, and no mention of when to prefer the unique flag.

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, so the description carries the burden. It discloses key behavior: cryptographic randomness source, presence of entropy bits, and per-call cost via x402. It does not state whether generated secrets are stored/logged or describe the exact return shape, leaving minor gaps.

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 tightly written sentences, front-loaded with purpose. Each sentence adds distinct value: purpose/security, alphabet guidance, and payment cost. No filler.

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?

The description is complete enough for a simple zero-required-param generator: it covers security source, output entropy, alphabet choice, and cost. With no output schema, the return structure is not fully specified, but the entropy mention gives useful partial context.

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 count, length, and alphabet. The description still adds meaningful context for the alphabet parameter, especially the legibility/readability distinction beyond the enum names.

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 (Generate) and resource (strong random secrets/passwords), and adds distinguishing properties: CSPRNG origin, entropy output, and four alphabets. This is enough to separate it from generic random_* siblings without naming them.

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 implies when to use the legible alphabet ('for anything a human has to read back'), but gives no explicit alternatives or when-not-to-use guidance relative to random_number, random_pick, or other siblings. Usage is inferable but not fully prescribed.

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. It usefully discloses the cost and payment rail ('$0.005 per call, paid over x402 (USDC)'), which is real added value, but says nothing about edge cases (e.g., requesting more items than exist without repeat), error behavior, or return format.

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 purpose is front-loaded in the first sentence with zero waste. The middle sentence ('The list is yours, so this is the unbiased chooser an agent needs...') leans marketing and could be trimmed, but the whole stays short.

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 3-param, all-documented tool with no annotations or output schema, the description covers purpose, usage framing, and pricing. It lacks any edge-case guidance but is largely sufficient 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%, so count, items, and repeat are already fully documented with defaults. The description's 'with or without repeats' maps to repeat but adds no syntax or format detail beyond the schema; 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+resource ('Pick one or more items at random from a list you send') and adds modifiers ('with or without repeats'). The scope 'from a list you send' implicitly distinguishes it from fixed-set siblings like random_coinflip, random_dice, and random_number, but no sibling is named outright.

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 a clear condition for use: 'when it has options and no reason to prefer any.' This is good context but stops short of naming alternatives or stating exclusions (e.g., use random_shuffle to reorder rather than select).

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 disclose the important operational traits: the randomness source (platform CSPRNG), the uniformity guarantee, and the billing model ($0.005 per call paid over x402 in USDC). What it omits is the return shape and edge-case behavior (empty list, single item), which matters for a paid call.

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 compact sentences, front-loaded with the core action, then the differentiator, then the cost. Each sentence earns its place: the Fisher-Yates/random-key comparison justifies the implementation choice and the price disclosure is essential for a paid tool.

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 100% schema coverage but no output schema and no annotations, the description covers purpose, guarantee, and cost adequately. It stops short of stating what is returned or how degenerate inputs are handled, which would complete the picture for a non-deterministic paid operation.

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% for the single 'items' parameter, and the schema already documents both the comma-separated form and the JSON-array POST body alternative. The description adds no further meaning 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?

States a specific verb+resource ('shuffle a list into a uniformly random order') and pins down the algorithm (Fisher-Yates over the platform CSPRNG), which clearly separates it from siblings like random_pick, random_number, and random_dice. An agent can tell immediately that this permutes an entire list rather than drawing a value.

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 shuffle semantics, and the description contrasts against a naive 'sort by random key' approach, but that is a correctness argument rather than routing guidance. It never says when to choose this over random_pick (one element) or when shuffling is inappropriate, and no explicit prerequisites are given.

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 provided, the description carries the full behavioral burden and does well: it discloses data sources, return structure (IPv4/IPv6 prefixes with sample), that it is keyless and free at the source, and the pricing model ($0.005 per call via x402 USDC). It does not disclose rate limits, caching, or failure modes like missing RDAP records.

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 a single dense but well-structured sentence that front-loads the data sources and follows with workflow context and pricing. It is appropriately sized for the amount of information conveyed, though slightly information-dense.

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 lookup tool with no output schema and no annotations, the description is quite complete, covering data sources, output shape, pricing, and usage context. It could be improved by mentioning error handling or what happens when an ASN is not found, but the core is solid.

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 the single 'asn' parameter with format examples ('15169 or AS15169'). The description adds no further parameter detail. Baseline 3 applies when the schema fully covers parameters.

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 (lookup) and resource (autonomous system number) and enumerates the exact data sources and fields returned (RDAP registry record via ARIN-to-RIR referral, Team Cymru DNS, RIPEstat prefixes split IPv4/IPv6). It clearly distinguishes itself from sibling red_ip by naming the workflow relationship ('natural second call after /v1/red/ip').

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 provides clear context for when to use it: after red_ip yields an origin ASN. It also notes it is keyless and free at the source. However, it does not explicitly state when NOT to use it or list alternative ASN-related tools, though none appear in the sibling list.

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 a good job: it discloses the read-only nature, that no API key or account is needed, and—unusually valuable—the exact cost model ($0.005/call via x402 USDC). It does not discuss rate limits, pagination, or failure behavior, so it falls 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 with the core capability, then the ISSUED-vs-serving distinction, then cost—each sentence earns its place. Slightly long, and the pricing sentence could be tighter, but nothing is wasted.

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 two-parameter lookup with no output schema, the description enumerates the returned fields and clarifies semantics of the data source, giving an agent everything needed to call it and interpret results correctly.

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 both parameters (domain, subdomains) are already fully documented, including host reduction and the default. The description adds no parameter-level 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.

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

States a specific verb+resource: reads TLS certificates from Certificate Transparency logs, and enumerates exactly what is returned (issuer, validity window, days to expiry, revocation, hostnames). Crucially it distinguishes itself from a 'what is the server serving now' scanner, which separates it from siblings like red_domain_check or web_status.

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 condition for when this is the right tool: finding certificates 'you did not know existed' versus checking live server state. However it never names an alternative sibling for the live-serving case, so routing is inferred 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 provided, the description carries the full burden and does so richly: it discloses that every list is re-validated on each call via its RFC 5782 test entry, that dead/refusing lists return 'unavailable' rather than a false 'clean', that output is raw return codes with published reason text (not a score), that delisting URLs are included, and that each call costs $0.005 via x402/USDC. Failure modes, output semantics, and cost are all surfaced.

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 clause, with the value-add details (raw codes over scores, RFC 5782 re-validation, delisting URLs, pricing) following in tight, waste-free sentences. Every sentence carries information an agent needs, and nothing is padded.

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 or annotations exist, so the description must cover return semantics and safety on its own, and it does: it explains the return shape (per-list raw return code plus reason text), the delisting URL, the unavailable case, and the x402 payment model. For a one-param lookup tool this is complete.

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 a single parameter with 100% schema description coverage, so the schema already fully documents the 'ip' field and its IPv4-only constraint. The description reinforces 'one IPv4 address' but adds no syntax, format, or validation detail beyond what the schema states. 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?

States a precise verb+resource (checks one IPv4 against nine named public DNS blocklists) and names actual lists, so the function is unmistakable. It does not explicitly position itself against close siblings like red_ip or red_domain_check, but the resource and scope are specific enough that an agent can differentiate. Clear and specific, missing only explicit sibling differentiation.

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?

Implied usage is clear: reach for this when you need an IPv4's blocklist status. However, it gives no explicit when-to-use/when-not guidance and never names alternatives in the red_* family (red_ip, red_domain_check) that an agent might otherwise pick. Usage is inferable but not stated.

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 disclose important traits: live (uncached) DNS, no API key/account needed, and a per-call cost of $0.005 paid via x402 (USDC). Cost and payment model are exactly the kind of context an agent needs. It omits rate limits, timeouts, and error behavior, and does not define the "looks parked" heuristic.

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?

Four sentences, front-loaded with the payoff (everything DNS in one call), followed by usage pattern, constraints, and pricing. Every sentence adds distinct information with no filler.

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 correctly substitutes by enumerating the returned fields, and it covers auth, cost, and usage pattern. It lacks any note on response shape, pagination (not applicable here), or failure behavior, which keeps it from a 5.

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 is fully documented in the schema (URL/email reduced to host). The description adds no parameter-level detail, so the 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 resource (DNS data for one domain) and enumerates exactly what is returned: registration status, A/AAAA, nameservers, MX, SPF/DMARC, DNSSEC, parked heuristic. That enumeration implicitly separates it from siblings like red_whois (registration data) and red_dnsbl (blocklists) without the agent opening any 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?

"Built for going through a list of domains one at a time" gives clear context for how and when to invoke it (one domain per call, iterating over a list). It does not name alternative tools or state exclusions, 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 does so: it discloses the score range, the verdict enum, the itemised-evidence response shape, the data sources with counts, and critically the operational profile — no SMTP probe, no API key, $0.005 per call paid over x402 (USDC). Cost and payment-path disclosure is exactly the kind of behavioral context annotations would never provide.

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 leading sentence front-loads the action and output, and every following clause (data-source counts, method, pricing) earns its place. It is dense to the point of reading as one long run-on block, which slightly hurts scannability, but there is essentially no filler.

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 exists, so the description must, and does, explain the return values (0-100 score, verdict enum, itemised evidence per lost point). Combined with the pricing and method disclosure, an agent has everything needed to call this correctly.

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 'email' parameter is documented with an example in the schema itself. The description adds no format or syntax detail beyond what the schema already supplies, 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?

States a specific verb and resource ('Scores one email address 0-100') and enumerates the exact output verdicts (ok, risky, disposable, undeliverable, invalid) plus the evidence model. This clearly separates it from siblings like red_domain_check, red_dnsbl, red_whois and util_phone without the agent needing to open any 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?

The description implies the use case (screening/validating a single address) but never states when to reach for this tool versus an alternative, nor any exclusions or prerequisites for calling it. It distinguishes its *method* ('No SMTP probe') but not its *usage conditions*, leaving this at implied 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 and does well: it discloses the two keyless public sources (so no auth/credentials are implied), the referral-chain mechanism, and the $0.005-per-call x402/USDC payment requirement. It omits failure behavior (invalid IPs, rate limits) and response shape, 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?

Front-loaded with the core lookup, then sources, then explicit non-capabilities, then cost and usage pattern. Every sentence adds a distinct fact (source, exclusion, price, use case) with no 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?

No output schema and no annotations exist, so the description must cover return values and cost, and it does name the returned registry fields and ASN plus the per-call price. It could say more about error cases or output structure, but for a one-parameter lookup it is nearly complete.

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 a single parameter with 100% schema coverage, and the schema description already says 'The IPv4 or IPv6 address to look up.' The description's 'one IPv4 or IPv6 address' adds no format or syntax detail beyond that, 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?

States a precise verb+resource ('looks up one IPv4 or IPv6 address') and enumerates exactly what comes back (registry holder, country, since-date, abuse contact, origin ASN). It is clear what the tool is, but it never names the overlapping siblings red_asn or red_whois, so an agent must infer the boundary 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?

'Built for going through a list of IPs one at a time' gives a concrete usage context, and the explicit exclusions (no city-level geolocation, no VPN/proxy detection) tell the agent when this tool will not answer the question. It stops short of pointing to a specific alternative for those excluded cases, so no sibling is named.

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 substantial work: it discloses the data source (RDAP via IANA bootstrap), the auth model (no API key, no account), the cost ($0.005 per call over x402/USDC), and the key edge case (TLDs with no RDAP server say so rather than reporting unregistered). Rate limits and failure modes are not covered, 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?

Four dense sentences, front-loaded with what the tool is and where the data comes from. Every sentence adds information, though the pricing and bootstrap details could be compressed slightly.

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 compensates by enumerating the returned fields (creation/expiry/last-change dates, age, days to expiry, registrar, EPP status codes, nameservers, DNSSEC, abuse contact) plus the edge-case return behavior. An agent knows what it will get and what it costs 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 schema description coverage is 100%, so the schema already explains that URLs and emails are reduced to their host. The description adds nothing beyond 'one domain', which is the correct baseline 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?

States a specific verb and resource ('Registration data for one domain') and immediately differentiates the mechanism from port-43 whois scraping. It also implicitly separates itself from the sibling red_domain_check by framing itself as registration data rather than availability.

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 ('one domain', registration data) but the description never states when to pick this over red_domain_check or red_dnsbl, nor any exclusions. The agent can infer the context but must do the routing work itself.

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 well: it discloses the source of truth (runtime tz database), the exact return payload (offset, abbreviation, DST flag, UTC instant, hour delta), and the two tricky edge cases (non-existent and ambiguous times). It even discloses cost and payment rail ($0.005/call over x402 USDC), which is genuinely useful for agent decision-making.

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?

Four sentences, all front-loaded and each earning its place: purpose, return shape, edge-case warning, pricing. No repetition of the name or schema.

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 exists, so the description must describe the return payload — which it does explicitly. Combined with full schema coverage of inputs and clear behavioral/cost disclosure, nothing an agent needs to call it correctly is missing.

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 from/to/time with formats and defaults. The description adds no parameter-level syntax or constraints beyond what the schema provides, so the 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+resource (convert a time between two IANA time zones) and immediately scopes it with DST handling. An agent can distinguish this from time_now (current time) and time_zones (zone listing) without opening any 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?

Usage is implied by the description — this is the tool for zone-to-zone conversion, and hand-made conversion is called out as error-prone. However, no sibling is named or routed to (time_now, time_zones), and no explicit when-to-use/when-not guidance is given.

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 so well: it enumerates return contents (ISO with offset, 24h, 12h, weekday, unix, UTC), discloses DST-active status and standard offset, and importantly reveals that the call costs $0.005 via x402 (USDC), an auth/payment constraint an agent must anticipate. It omits error behavior for invalid zones, 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?

Front-loaded with the core purpose, followed by output detail, DST/offset rationale, and pricing. Three sentences, each carrying information, though the long output-format enumeration is slightly list-heavy.

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 exists, so the description must describe return values, which it does comprehensively, and it covers the payment requirement and the single required parameter via the schema. For a one-param tool it is close to complete, missing only error/edge-case handling.

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 'zone' parameter is fully documented in the schema with examples. The description only echoes 'any IANA time zone' without adding format or edge-case guidance beyond what the schema already provides, so the 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?

The description states a specific verb and resource (returns the current time in any IANA time zone) and enumerates the output forms, so an agent knows exactly what it produces. However, it never names or distinguishes itself from the sibling tools time_convert or time_zones, leaving the agent to infer that this is the 'now' tool versus a conversion or enumeration tool.

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 rather than stated: the phrase 'every form an agent needs at once' signals it is the single-call option when multiple representations of the current moment are wanted. There is no explicit when-to-use, no exclusions, and no routing to time_convert/time_zones for related 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?

With no annotations, the description carries the full burden and does disclose real behavioral traits: the return fields (offset, abbreviation, local time, DST state) and the payment model ($0.005/call over x402 USDC). It omits rate limits, error/pagination behavior, and how often offsets refresh, so it falls 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?

Three sentences, zero filler, and front-loaded with the core capability and the returned data before the usage hint and pricing. Every sentence 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?

There is no output schema, so the description must explain returns — and it enumerates them precisely. Combined with the usage framing and cost disclosure, an agent has everything needed to select and invoke this tool correctly.

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. The description restates the offset-filter use case ('find every zone sitting at a given offset right now') and implies the search-into-zone-name flow, but adds no format or syntax detail beyond what the schema already provides.

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 and resource ('Search the full IANA time zone list') and immediately enumerates the returned fields (UTC offset, abbreviation, local time, DST state). This cleanly separates it from siblings like time_now and time_convert, which operate on an already-known zone.

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 two concrete use cases: mapping a city/country to a zone name other endpoints expect, or finding zones at a given offset. It references the sibling endpoints implicitly, but does not state exclusions or when a sibling like time_convert is the better call instead.

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 burden and does well: it discloses the return format (EIP-55 checksum) and the pricing/payment model ($0.005 per call over x402/USDC), which an agent cannot get from the schema. It stops short of stating error behavior for a failing checksum or any rate limits, so it is above baseline but not fully exhaustive.

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: purpose first, the motivating use case second, and the cost detail last. Every sentence earns its place with no filler.

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 validation tool with no output schema, the description explains both the input expectation and the returned checksum form, and even surfaces the cost. Only the failure/error semantics for an invalid checksum 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?

Schema coverage is 100% and there is only one parameter, so the schema already documents 'address' including 'in any case'. The description adds only the EVM-type constraint (implied by the address format), which is marginal beyond the structured field.

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 (validates) and resource (EVM address) and even names the output form (EIP-55 mixed-case checksum). This clearly separates it from siblings like evm_ens, evm_is_contract, or util_keccak256 without needing to open any 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?

Gives a concrete usage context – run it before sending funds to catch typos. There is no explicit when-not or named alternative sibling, but the trigger condition is clear and actionable.

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 usefully discloses the pricing model ($0.005 per call, paid over x402/USDC) and UTF-8 handling, which are traits an agent cannot get from the schema. However, it says nothing about error behavior for invalid base64, output format, or limits.

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 and the pricing sentence earns its place as actionable context. The middle sentence ('Encoding is what carries payloads through headers and JSON, and x402 itself rides on it') is largely justification/marketing that adds little invocation value, so the response is slightly padded.

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 utility with no output schema and no annotations, the description covers both directions, the URL-safe variant, UTF-8 handling, and cost. Gaps remain around error/return behavior, but nothing critical to correct invocation is missing.

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 mode, input, and urlSafe completely. The description's mention of 'both directions' and 'URL-safe alphabet' loosely maps to mode and urlSafe but adds no syntax or default detail beyond the schema, warranting the baseline 3.

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: base64 encode and decode, naming both directions and the URL-safe alphabet plus UTF-8 handling. The purpose is unambiguous and matches the title. It does not explicitly differentiate from sibling utilities like util_hex or util_uuid, 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?

The description gives general context for why base64 matters ('carries payloads through headers and JSON') but provides no explicit when-to-use or when-not-to-use guidance, and does not name an alternative such as util_hex for hex conversions. Usage is only implied from domain context.

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 well: it discloses exact big-integer handling (the key correctness edge case) and the cost/payment model ('$0.005 per call, paid over x402 (USDC)'). It omits error behavior and return shape, but the precision and billing disclosures are genuinely useful context beyond 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?

Three tight sentences: purpose first, then the motivating use case, then cost. Every sentence earns its place and nothing is redundant.

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 two-parameter converter with no output schema, the description covers purpose, use case, precision behavior, and cost. It could state the return format, but for a transparent value-conversion tool the coverage is nearly sufficient.

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 both 'as' (with its hex|decimal|text modes) and 'value' are already documented in the schema. The description adds purpose framing but no additional parameter syntax or format detail, so the 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?

The description names a specific verb ('Converts between') and the exact resource set ('hex, decimal and UTF-8 text'), so an agent knows precisely the transformation offered. It does not explicitly differentiate from adjacent utilities like util_base64 or util_units, but the named format set is self-distinguishing.

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 concrete use case: 'For reading raw RPC output, which comes back as hex and overflows a JavaScript number.' This tells the agent when the tool is applicable, though it names no exclusions or alternative tools for related conversions.

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 offline/deterministic behavior, no network call, no third-party dependency, and the per-call price and payment rail (x402/USDC). It also previews the returned fields. It omits error/malformed-input behavior and any rate limits, 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?

Three sentences, front-loaded with the core operation and its checks, then behavior, then cost. The "no third party that can go down" phrasing is slightly promotional, but nothing is redundant or padded.

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 validator with no output schema and no annotations, the description covers inputs accepted, processing semantics, returned fields, and cost. Missing only failure-mode detail for invalid IBANs, which is a minor 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?

Only one parameter, and the schema already documents at 100% coverage that spaces and lowercase are accepted. The description adds no further syntax or format guidance beyond the schema, so the baseline 3 for high schema coverage 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 (validates) and resource (one IBAN) and enumerates exactly what is checked: country, length, ISO 7064 mod-97, SEPA membership, and account-number split. This distinguishes it from the other util_* validators (util_vat, util_phone) without needing 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?

"Built for cleaning a list of accounts one at a time" gives clear usage context and implies the call granularity an agent should expect. It does not name when-not to use it or point at any alternative tool, 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 behavioral burden and discloses two non-obvious traits: a per-call cost ($0.005) and a payment mechanism (x402/USDC). It also warns against the SHA3-256 mix-up, a meaningful correctness caveat. It stops short of stating the return format or error behavior, but for a deterministic hash the payment and distinction details are the salient additions.

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 core operation, then use cases, then pricing. Each clause earns its place and nothing is redundant.

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-annotation, no-output-schema tool, the description is largely self-sufficient: it states what the function is, when to use it, the SHA3-256 pitfall, and cost. The only minor omission is the output format (hex), which is reasonably inferable for a hash.

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 schema already explains the single 'input' parameter as plain text or a 0x-prefixed hex payload hashed as bytes. The description's phrase 'any string or hex payload' reiterates rather than extends that, so the baseline 3 for high-coverage schemas 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 names a specific verb and resource ('Keccak-256 of any string or hex payload') and crucially distinguishes the operation from the near-identical SHA3-256, which an agent would otherwise confuse it with. It also identifies its domain (Ethereum hashing), letting it be told apart from siblings like util_sha256 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.

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

It names concrete use cases (selectors, event topics, salts, CREATE2 addresses) that tell the agent when this tool applies. It distinguishes itself from SHA3-256 but doesn't explicitly route to adjacent siblings such as util_selector or util_sha256, so usage context is clear but not fully exhaustive.

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 at all, the description carries the full burden and does so well: it declares the tool is offline, requires no network or API key, therefore cannot fail due to third-party downtime, and — critically for an agent — costs $0.005 per call settled over x402 in USDC. Cost and payment mechanism are behavioural facts an agent cannot get anywhere else.

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 the core action, and each subsequent clause (offline, no key, cost, data source) adds decision-relevant information rather than filler. The single long sentence is dense but every element earns its place; only minor tightening is possible.

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 by naming the returned values (tel: URI, national dialling form), the data source, and the pricing model. It omits error behaviour for an invalid number (e.g., whether a failed check is still billed) and any rate-limit detail, which are the remaining gaps for a paid 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 description coverage is 100%, so both parameters are already documented, including the rule that 'country' only applies when the number carries no country code. The description's discussion of shared calling codes (+1) explains why country resolution matters but does not add syntax or format 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?

States a specific verb and resource ('Checks one phone number'), then enumerates the three concrete operations: E.164 normalisation, country resolution, and national-length validation. It also discloses the return payload (tel: URI and national dialling form), which clearly separates it from siblings like util_iban or util_vat.

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 phrase 'one phone number' implies scope and the offline/no-API-key framing hints at when this is preferable to a networked lookup, but there is no explicit when-to-use statement and no sibling is named as an alternative. Usage is inferable rather than stated.

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 burden, and it discloses the cost model ($0.005 per call, paid over x402 in USDC) — non-obvious operational context an agent must know before calling. It does not cover failure behavior for malformed signatures or confirm determinism/idempotency, so it stops short of full disclosure.

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 short sentences: purpose first, then use case, then cost. Every sentence earns its place and nothing is padded.

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?

The description explains both return values (4-byte selector, 32-byte topic0) even though no output schema exists, and the single input parameter is fully specified by the schema. Nothing needed to invoke it correctly is missing.

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 format rules (canonical, no spaces, no argument names) are already documented. The description adds an inline example signature, which reinforces the expected shape but adds no syntax 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?

States a specific verb and resource: converting a Solidity signature to a 4-byte selector and 32-byte topic0. This cleanly distinguishes it from neighbors like util_keccak256 (raw hash) and util_hex, which do not compute selectors.

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 concrete use cases ('build calldata by hand', 'filter logs'), which tells the agent when this tool is the right pick. It stops short of naming an alternative tool or stating exclusions, so it is clear context rather than full routing 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 burden and does disclose meaningful traits: both return encodings (hex and base64) and the cost/payment model ($0.005 per call over x402 USDC). It omits error behavior and input-normalization edge cases, but for a deterministic pure function 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.

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

Three short sentences, front-loaded with what the tool does and its outputs, followed by use context and pricing. No filler or repetition.

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 usefully supplies the return format (hex and base64) and the payment requirement, which an agent needs before calling. Only edge-case behavior (invalid hex, empty input) is unspecified, leaving it slightly short of fully complete.

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 already documents the 'plain text or 0x-prefixed hex' semantics; the description's 'any string or hex payload' merely paraphrases it. 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?

States a specific verb+resource (SHA-256 hashing) and the input/output formats (hex and base64). Explicitly positions itself against the sibling util_keccak256 by noting it is 'the hash everything outside Ethereum uses', so an agent can disambiguate 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.

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

The Ethereum/non-Ethereum framing gives clear context for when to pick this over util_keccak256, and the listed use cases (file digests, API signatures, content addressing) reinforce that. It stops short of an explicit 'use util_keccak256 for Ethereum payloads' instruction, so it is strong but not fully prescriptive.

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 burden and does deliver real behavioral detail: exact integer maths, no floating point, no silent rounding, plus the $0.005 per-call cost and x402/USDC payment requirement. It omits error behavior and output format, which keeps 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?

The core purpose is front-loaded in the first sentence, followed by two sentences on precision and cost. Slight marketing flavor ('The mistake that costs real money') but each sentence carries usable 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?

No output schema and no annotations exist, so the description should explain the return shape (e.g., that it returns a string), which it does not. It does cover precision guarantees and pricing, partially compensating for the missing structured metadata.

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 amount/from/to, and the baseline is 3. The description echoes that accepted units include token decimals, adding only marginal meaning 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?

States a specific verb (Converts) plus the exact resource scope (wei, gwei, ether, any token decimals), which no sibling tool covers. An agent can immediately distinguish it from the evm_* and other util_* tools.

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 implies when the tool is useful (unit conversion) but gives no explicit when-to-use vs alternatives, no prerequisites, and never references related siblings like evm_balance or evm_token_price where a value might be converted. Usage is inferable but not stated.

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, and it does add real behavioral context: the generation source (platform CSPRNG), the batch cap, and the cost/payment model ($0.005 per call over x402/USDC). What it omits is any statement of uniqueness or format guarantees, but for a UUID v4 generator the disclosed traits are the ones that matter.

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?

A single tightly packed sentence front-loads the core capability, then layers scope, use cases, and cost with zero filler. Every clause 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 generator with a fully covered schema, the description supplies purpose, limits, sourcing, and pricing, which is enough to call it correctly. The absence of an explicit statement on output format is a minor gap given UUID v4 is a well-known format.

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 single 'count' parameter is already documented as 1-100 with a default of 1. The description's 'up to 100 per call' merely corroborates that range, adding no syntax or format detail beyond the schema. Baseline 3 is 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?

States a specific verb and resource (generate UUID v4s) plus distinguishing qualities: cryptographically random, CSPRNG-sourced, up to 100 per call. An agent can differentiate this from random_password or random_number without opening any 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?

Names concrete use cases (idempotency keys, request ids, correlation ids) that clarify when to reach for this tool, and the 'must not collide' note hints at the quality requirement. It stops short of explicitly excluding alternatives like random_password, so it is clear context without routing rules.

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 discloses determinism, that there is no network call, that it will report whether check digits were actually verified versus format-only, and the cost ($0.005 per call via x402/USDC). It omits error/edge behavior (e.g., unknown country prefix, non-EU input), 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?

Five compact sentences, all earning their place: what it does, what it guarantees, its determinism, its intended use, and its pricing. The core capability is front-loaded and nothing is redundant.

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, offline validator with no output schema and no annotations, the description covers purpose, behavior, determinism, and cost, and even hints at the return content (whether check digits were verified). Only the exact response shape and error cases remain unspecified, which is acceptable given the tool's simplicity.

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 is fully documented in the schema itself, including tolerant handling of prefix and spacing. The description adds only that a country prefix is central to validation, 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 and resource (validates an EU VAT number) and enumerates exactly what is checked: country prefix, country-specific format, and the check-digit algorithm where it exists. This clearly distinguishes it from adjacent utilities like util_iban or util_phone in the sibling list.

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 a context of use ("cleaning a list of companies one at a time") and notes it is offline vs. a network-backed check, which is useful implicit guidance. However, it never states when to prefer this over an alternative or when it is inappropriate (e.g., a company whose VAT must be verified live against VIES), leaving the boundary implied rather than explicit.

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