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 latency (~1 second), the text-layer limitation that makes scanned pages return empty, the billing model ($0.01/call over x402 USDC, charged only if Markdown is delivered), and the absence of any API key or account requirement.

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 when-to-use condition, then capabilities, limitations, and pricing in a single dense paragraph. Every sentence carries information, though the pricing/payment sentence is long enough to slightly slow scanning.

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 explains the return value in detail — Markdown with headings, tables and page markers plus a token count — and flags the main failure mode (no text layer). 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 description coverage is 100%, so url, document, and filename are already well documented in the schema. The description restates the either/or input choice ('pass an https URL or base64') but adds no syntax, size limits, or format-selection nuance beyond what the schema provides, 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 a document into clean Markdown — and enumerates the supported input formats (PDF, Word, Excel, PowerPoint, HTML, CSV, XML). It is clearly distinguishable from siblings like web_read (fetches pages) or ai_transcribe (audio) by scoping to a document the agent was handed.

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 trigger is explicit: 'Use when an agent must read a document it was handed.' It does not name alternatives or exclusions (e.g., use web_read for live pages, ai_transcribe for audio), so routing to siblings is left to inference, but the use context itself 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 so well: it discloses latency (~2 seconds), output format, 24-hour URL validity, optional base64 return, pricing ($0.02 per call), charging only on delivery, payment via x402/USDC, and no API key/account requirement. These are meaningful behavioral details 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?

The description is dense and front-loads the main usage scenario and output format. It has slight redundancy in repeating 'hand straight to the next step/tool', but overall it remains efficient and appropriately sized.

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?

Given no annotations and no output schema, the description fully explains the return value (hosted URL valid 24 hours, optional base64), model, image size/format, cost, auth/payment, and latency. An agent has enough information to call it and understand the result.

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 prompt, steps, and inline. The description reinforces steps 1-8/default 4 and inline=true/base64, but this mostly duplicates schema semantics rather than adding new parameter meaning.

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: generate a 1024x1024 JPEG from a text prompt using FLUX.1 [schnell]. It is clearly a text-to-image tool rather than an edit/describe/styled sibling, but it does not explicitly name or contrast those alternatives.

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

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

It gives clear usage context: use when an agent needs a picture it can pass directly to the next step, and it explains when to add inline=true for base64. It lacks explicit when-not guidance or named alternatives such as ai_image_edit or ai_image_styled.

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 transparency burden and delivers key behavioral traits: ~1 second latency, 'only charged if the description is delivered', no API key/account, and $0.005 per call via x402 (USDC). It does not cover rate limits or error modes, but the payment and auth details are unusually specific and 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?

The description is front-loaded with the core trigger and how-to, then adds chaining context and billing/auth details. Each sentence serves a purpose, though the 'pairs with the rest of the chain' sentence is slightly tangential and could be trimmed without losing much.

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-parameter tool with no output schema and no annotations, the description is complete enough: it implies a text result, explains how to supply the image and prompt, and covers billing and auth. It omits error behavior and output format specifics, but the schema already fully documents the inputs, so these gaps are minor.

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 all four parameters have descriptions, so the baseline is 3. The description mentions URL/base64 and 'ask anything' for the prompt, which aligns with the schema but adds no new syntax, format, or constraint details beyond what is already documented.

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 action: passing an image URL or base64 to get words back, from a one-line caption to reading a sign. This distinguishes it from generation or editing siblings like ai_image, though it never names those alternatives explicitly. The title reinforces the purpose, but the description could be sharper about what it is not.

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 clearly says when to use it ('Use when an agent has an image and needs words it can act on') and how to invoke it ('pass an https URL or base64 and ask anything about it'). It also suggests a workflow chain with translate and speech tools, but does not state when not to use it or name specific alternative tools for different image tasks.

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 to lean on, the description carries the full burden and does so well: 10 MB per-asset limit, a hosted URL valid 24 hours, billing only on delivered edits, $0.02 per call over x402/USDC, and no API key or account required. These are exactly the operational traits an agent cannot infer from the schema.

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

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

The use case and mask semantics are front-loaded, and every clause contributes. The payment/pricing sentence is dense but relevant for an unauthenticated paid endpoint; still, the run-on single-sentence structure could be split for faster scanning.

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 an 8-parameter, single-required-input tool with no output schema, the description covers inputs, size limits, the return value (24-hour hosted URL), cost and payment method. An agent has everything needed to decide to call it and interpret the result.

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 baseline is 3, but the description synthesizes what the schema states per-property: the mutual exclusivity of url/image and mask/mask_url as URL-or-base64 alternatives, plus the shared 10 MB cap. It stops short of touching sampling knobs like steps, guidance or seed, which remain schema-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?

The description names a specific verb and effect — "change part of an image and leave the rest untouched" — plus the concrete mechanism (mask-based inpainting repainting only the white area). This clearly separates it from sibling image tools like ai_image, ai_image_styled and ai_image_describe, which generate or analyze whole images.

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

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

"Use when an agent must change part of an image and leave the rest untouched" gives a clear triggering condition and implicitly excludes full-image generation or description. It never names an alternative sibling or states a when-not case explicitly, so it falls 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?

No annotations are provided, so the description carries the full burden and does so well: ~2 second latency, seed-based repeatability, return format (hosted URL valid 24 hours, optional base64 via inline=true), no API key/account, pricing ($0.01/call over x402 USDC), and the unusual billing rule that you are only charged if the image is delivered. These are exactly the traits an agent cannot infer from structured fields.

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?

One dense, front-loaded paragraph: use case first, then model/style, then parameters, then return values, then cost/auth. Every sentence contributes a fact an agent would otherwise have to guess, with no repetition of schema text.

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 supplies the return contract (hosted URL, 24h validity, optional base64), plus cost, auth, and latency. For an 8-parameter generation tool with full schema coverage, 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 baseline is 3; the description adds intent beyond the schema by saying the seed is for a repeatable result, that width/height are caller-chosen, that a negative prompt is supported, and that inline returns base64. It doesn't touch steps or guidance, but those are fully documented 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 verb and resource (generate an illustration from a text prompt), names the underlying model and its style bias (DreamShaper 8 LCM, painterly/character art, not photoreal), and gives a rough latency. An agent can immediately tell this apart from ai_image (photos) and ai_image_edit without opening either schema.

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

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

Explicit when-to-use: 'Use when an agent needs an illustration rather than a photo', reinforced by the painterly/non-photoreal contrast. It implies the alternative (photo generation) but doesn't name ai_image or ai_image_edit directly, so routing is clear for the main case but not explicitly enumerated.

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: URL validity (24h), output formats per language, size reporting, optional base64 via inline, the 2000-char input limit, charge only on delivery, pricing ($0.01), no API key/account, and x402/USDC payment. These are the exact 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?

A dense single paragraph with zero filler; the usage condition and key constraints are front-loaded. It is packed with clauses, slightly heavy for one sentence chain, but every clause carries operational 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, yet the description fully describes the return (URL, format, size, optional base64) plus limits and payment. Nothing material is missing 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 coverage is 100%, so baseline is 3; the description adds value by explaining that inline=true yields the base64 alongside the URL and by mapping lang values to the underlying engine per language. Minor redundancy with schema on the 2000-char limit, but net additive.

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 specific resource (English/Spanish via Aura-2, others via MeloTTS), the six supported languages, and the output artifact (audio URL, MP3/WAV). The 'heard and not read' framing distinguishes it cleanly from siblings like ai_transcribe (the reverse) and ai_image, so an agent can select 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?

It states an explicit when-to-use condition ('when an agent must be heard and not read') and constrains to the six supported languages, which rules out unsupported cases. It doesn't name a specific alternative tool to use when the condition fails, but the usage context is clear enough for selection.

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: accepted input forms (https URL or base64 POST), supported formats, 10 MB cap, ~100 languages, billing model ($0.02/call over x402 USDC, charged only on delivery), and no API key/account required. These are exactly the prerequisites and cost constraints an agent needs before invoking a paid external service.

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 usage trigger, then input specs, then return values and pricing – a sensible order and no filler sentences. It is a single very dense sentence chain with semicolons, which costs a bit of scannability.

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 takes responsibility for describing returns (text, detected language with probability, duration, timed segments, optional word timestamps), plus cost and auth. Nothing an agent needs to call this correctly is missing.

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

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 url, audio, words, and language. The description restates the format list and the words=true behavior but adds no syntax or edge-case 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 ('speech-to-text', 'handed audio and needs text') and names the concrete engine (Whisper large v3 turbo). It is clearly distinguishable from siblings like ai_speech and ai_translate, which handle the opposite or a different transformation.

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

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

'Use when an agent is handed audio and needs text it can work with' gives a concrete triggering condition. It does not name an alternative or an explicit when-not case (e.g., when to reach for ai_translate instead), 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 so: it discloses cost ($0.005/call via x402/USDC), that billing only occurs on delivery, that no API key or account is required, the 2000-character cap, and that long texts are split by sentence while preserving order and line breaks. That is exactly the kind of operational context an agent needs before paying for a 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-loaded with the 'Use when...' trigger, then limits, chaining and pricing in a compact block with no filler sentences. The payment-mechanism detail (x402/USDC) is slightly dense but still decision-relevant.

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, and the description covers cost, limits, segmentation behavior and chaining, which is most of what matters. It never states what the response looks like (translated string vs object, detection result), which is the one remaining gap for a no-output-schema 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 all three parameters are already documented, including ISO-code-or-English-name for 'to' and auto-detection for 'from'. The description restates these facts and adds no syntax, format or constraint details 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?

Names a specific verb (translate), the resource (text), the engine (Meta M2M100 1.2B) and the scope (about 100 languages), so an agent knows exactly what it gets. It does not explicitly say why an agent would pick this over llm_completion or chat_completions for translation, so sibling differentiation is only implied by the tool's exclusivity.

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

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

'Use when an agent must say something in a language it was not given' is a concrete trigger condition, and the chaining note with /v1/ai/transcribe and /v1/ai/speech tells the agent where this fits in a pipeline. There is no explicit when-not guidance (e.g. against using a general LLM for translation).

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?

Given that there are no annotations, the description provides crucial behavioral traits that are not in the schema: it specifies that the tool is 'FREE,' lists specific content like 'a real example of the input and of the output each one returns,' and details the cost structure.

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 perfectly sized (one sentence), highly direct, and front-loads the most critical business constraint (free usage and emergency trigger).

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?

Since this is a zero-parameter metadata retrieval tool, the description is extremely complete. It defines the scope (all 78 tools) and the depth of information provided (costs, examples, payment methods), leaving no ambiguity for the agent.

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?

Since the schema coverage is 100% (no parameters), the baseline score applies. The description supports this by explaining that the tool will provide the necessary contextual information (inputs/outputs) for all listed tools, even if they require 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 clearly defines the tool's purpose as cataloging all available tools and providing specific metadata (input examples, output examples, cost) for each. It effectively distinguishes itself from the specific function of sibling 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?

It provides an explicit critical path for usage: 'Call this first if a tool answered HTTP 402.' This guides the agent to use the catalog exactly when it is most needed—when a specific tool has failed.

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 exist, so the description carries the full burden and does so: flat $0.005 per call regardless of prompt size, x402/USDC payment, no API key/account/rate limit, automatic failover across models, and billing only on delivery. It also warns that the model parameter is ignored on purpose, which prevents a costly misunderstanding.

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 'use when' trigger, then the compatibility guarantee, then cost/payment facts. Slightly redundant: the no-account/no-token-metering/no-key idea is restated in both the first and second sentences.

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 cost, payment mechanism, failover, model-parameter behavior, and the response shape (by reference to OpenAI) with no output schema to lean on. What remains thin is the mechanics of the x402 payment handshake and how a failed/undelivered call is actually handled by the client.

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 baseline is 3; the description adds the framing that parameters follow the OpenAI API exactly, which gives an agent a mental model for messages/prompt/max_tokens. The pricing-relevant claim ('does not change the price') for size is stated at the description level rather than per-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 verb+resource (chat completions with the exact OpenAI request/response shape) and its distinguishing property (no account, no token metering). An agent knows the shape of the call immediately. It stops short of naming sibling llm_completion to make the distinction airtight.

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

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

'Use when an agent must call an LLM with no account and no token metering' is an explicit use condition, and the flat-price/no-key framing further clarifies the context. There is no explicit 'use X instead when...' routing and no exclusions, even though llm_completion sits right next to it 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?

No annotations exist, so the description carries the full load, and it discloses the cost model ($0.005 per call, paid over x402/USDC), the output style (short, concrete, not a platitude), and reproducibility via seed. It omits what a payment failure or exhausted exclusion list looks like, and does not describe the response payload.

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 usage trigger, followed by output character and cost. The 'not a fortune cookie' clause is slightly flavorful but earns its place by delineating quality expectations.

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-required-param generator with no output schema and no annotations, the description covers purpose, output character, cost, and reproducibility. It is only slightly short of complete because the actual returned fields and payment-failure behavior are left 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%, so all four parameters are already documented with enums and defaults. The description restates them (topic filtering, id to avoid repeats, seed for reproducibility) without adding syntax or edge-case guidance beyond the schema, which is the baseline 3 case.

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: return one piece of practical advice about work, life or money, explicitly contrasted with a platitude/fortune cookie. It is clearly distinguishable from siblings like content_joke or content_fact by content type, though it never names those alternatives.

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

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

Gives a concrete trigger — end a reply with something usable rather than a platitude — which tells the agent exactly when to reach for it. It stops short of stating when NOT to use it or naming a sibling to prefer 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 behavioral burden and discloses key non-schema behavior: per-call cost, x402/USDC payment, return of an id for repeat avoidance, and seed-based reproducibility. It does not describe error behavior or rate limits, but it covers the important operational traits.

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 usage condition is front-loaded and the remaining details are dense and relevant. 'Takes parameters' is mildly redundant, but the cost/payment note and repeat-avoidance explanation earn their 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 four-optional-parameter content tool with no annotations or output schema, the description is largely complete: it covers the fact, topics, languages, id return, seed behavior, and payment. It stops short of describing the exact response shape or error cases.

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 optional parameters are already documented. The description reinforces the purpose of seed and id/exclude for reproducibility and repeat avoidance, but adds little parameter syntax or 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?

The description states a specific resource and scope: one curious fact, optionally by topic and language, for non-repeating use. It distinguishes itself from creative siblings like content_joke, content_riddle, and content_roast by emphasizing something true and factual.

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 usage condition: use when an agent needs something true to say and must not repeat itself across a session. It does not explicitly name alternatives or when-not-to-use cases, but the factual-content framing implies differentiation from joke/riddle/roast tools.

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 discloses the response shape (split into setup and payoff as well as joined), that an id is returned for de-duplication, seed-based reproducibility, and a concrete price with the payment rail ($0.005/call over x402 USDC). The pay-per-call requirement is exactly the kind of fact an autonomous 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?

It is front-loaded with the trigger condition and the concrete artifact, and every later sentence adds a distinct fact (split output, id, seed, price). The phrase 'Takes parameters' is pure filler and the opening clause is slightly convoluted, so it is not flawless.

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 value — and it does, down to the setup/payoff split that matters for narration plus the id. Combined with cost and payment mechanism, an agent has everything needed to decide, call, and use the result.

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 a real semantic link the schema leaves implicit: the returned id is what feeds the `exclude` parameter to avoid repeats. The seed and language defaults are echoed rather than extended, which keeps it from a 5.

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 deliverable (a two-sentence horror story) with its two axes of variation (English or Spanish; domestic/technological/cosmic/folk themes), which cleanly separates it from the other content_* siblings like content_joke or content_riddle. An agent can pick it 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 opening clause gives a clear usage condition: call this when something short and *timed* (setup, pause, payoff) is needed rather than plain printed text. It does not name explicit alternatives or say when another content_* tool would be the better pick, so it stops short of a full routing rule.

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 does well on several points: it discloses a per-call price ($0.005), the payment rail (x402/USDC), that an id is returned, and that a seed makes answers reproducible. It is silent on error behavior, rate limits, and the shape of the returned payload.

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 dense sentences, front-loaded with the when-to-use clause before the mechanics. Most of it earns its place, though the 'unlike the usual one-liner endpoints' aside is slight self-promotion that a reader could do without.

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, zero-annotation tool with no output schema, the description covers what an agent needs: trigger condition, filtering options, uniqueness handling via ids, reproducibility, and the payment requirement. Return-field detail beyond the id is the only real gap.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds purpose-level meaning: the id return value explains why 'exclude' exists, and 'reproducible answer' explains the seed's intent. That goes beyond the schema's mechanical 'same seed always returns the same joke.'

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: return one joke, in English or Spanish, filtered by category (programming, crypto, general). It implicitly separates itself from other single-value content tools by noting it 'takes parameters,' though it never names a sibling such as content_riddle or content_horror_story.

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 opening clause gives a clear triggering condition: 'Use when an agent must fill a pause without repeating itself,' and the exclude/id mechanic supports that anti-repetition use case. There are no explicit exclusions or named alternatives, which keeps it 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 burden well: it discloses the return payload (answer plus lowercase SHA-256), the verification purpose of the hash, and the commercial model ($0.005 per call via x402/USDC), which is critical operational context. It omits error/failure behavior and does not flag that the plaintext answer is returned alongside the hash, which slightly undercuts the 'without reading the solution first' framing.

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 'Use when' clause and with pricing last. Slight marketing phrasing ('The hash is the point') spends words on persuasion, but the content is dense and nothing is redundant with the 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?

For a no-annotation, no-output-schema tool, the description covers what matters: what comes back, the cost model, and the verification use case. The one gap is the internal tension of returning the plaintext answer while advertising blind checking, plus no note on response shape beyond the two values.

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 are already documented, including seed determinism and exclude. The description only echoes the difficulty and language filters and adds nothing about seed or exclude 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: returns one riddle filtered by difficulty, in English or Spanish, together with the answer and its lowercase SHA-256 hash. It also explicitly differentiates from siblings ('no other riddle endpoint lets you do this'), so an agent can pick it out of the content_* family 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?

'Use when an agent has to run a guessing game and must mark the answer without seeing it first' gives a clear triggering condition. It contrasts with unnamed alternatives rather than naming a sibling to use instead, so there is no explicit when-not guidance, but the selection 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 behavioral burden and usefully discloses paid usage ($0.005 per call over x402/USDC), bilingual output, seedable determinism, and repeat-free behavior. It does not describe the response shape, error behavior, or rate limits, but the key non-obvious traits are present.

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 use case is front-loaded and the description is compact enough for an agent to scan. There is some marketing repetition in the repeated 'actual stack' framing, but it still earns most of its space by covering targets, severity, determinism, and payment.

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-generation tool with full schema coverage and no output schema, the description covers the essential context: when to use it, target/severity options, determinism, language, and payment. It could be stronger by clarifying the return format or failure modes, but it is largely 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%, so all five parameters are already well documented. The description reinforces target and severity options and mentions seed/language behavior, but it adds little beyond the schema and does not explain exclude semantics.

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: a lighthearted developer roast aimed at a chosen stack target. It also scopes the tool by target, severity, language, and seed, so an agent can tell this apart from generic joke or content 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?

It gives a clear triggering context: a code-review agent that wants to joke about the actual stack in front of it. It also contrasts this with generic roast endpoints, though it does not explicitly name when to prefer sibling tools like content_joke or when not to use this tool.

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 behavioral burden and does well: it discloses deterministic UTC-date selection, cross-user consistency, past-date reproducibility, supported languages, and per-call x402 payment. It does not cover error behavior or invalid input handling, so it is 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?

The description is front-loaded with the usage condition and key return content, then adds determinism and pricing. It is slightly repetitive in restating same-word guarantees and includes light marketing language, but nothing is seriously 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 two-parameter tool with no output schema, the description is complete enough: it explains the returned fields, the language options, deterministic date behavior, reproducibility, and pricing. An agent has enough context to select and 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 already documents both parameters, including date format, default behavior, and language values. The description reinforces the deterministic/reproducible nature of the date parameter but adds little syntax or semantics 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?

The description clearly names the resource and what is returned: the word of the day with definition, part of speech, and an example sentence. It also differentiates the tool from ordinary random-word endpoints by emphasizing deterministic selection from the UTC date.

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 condition: when an agent runs something daily and everyone must get the same result. It also explains that past dates are reproducible, though it does not explicitly name sibling alternatives or state when not to use the tool.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the data source, exact matching only, return contents on a hit, snapshot date, no API key/account requirement, and per-call cost with x402 payment.

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 the usage condition and contains no filler. Each sentence adds actionable information about scope, matching behavior, return values, cost, or authentication.

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

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

For a simple one-parameter check with no output schema or annotations, the description is complete enough: it explains what is checked, what a hit returns, matching strictness, snapshot date, access requirements, and pricing.

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

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

The single address parameter is already fully documented in the schema. The description adds useful context by stating the 16-currency scope and exact matching behavior, though it does not need to do much more for a one-parameter tool.

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 gives a specific verb and resource: it checks a crypto address against the OFAC SDN list. It also explicitly distinguishes the result from a risk score, which helps separate it from sibling tools such as evm_verdict or evm_token_safety.

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 clearly states the usage condition: use when deciding whether an agent may transact with an address at all. It also implies when not to use it by saying it is not a risk score, but it does not explicitly name alternative tools for risk scoring.

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 paid nature ($0.02, USDC over x402), that a 402 challenge quotes the price before signing, that nothing is charged if no capability fits, and the 3-step chaining with result pass-through. Gaps remain on partial-failure behavior in a chain and on how the multi-step result is assembled.

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 when-to-use condition and kept to a single paragraph of relevant material. The pricing is restated twice ("from $0.02" per job, then "$0.02 per call"), a redundant and slightly inconsistent line that costs it a point.

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

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

For a meta-tool with 71 underlying capabilities and no output schema, the description covers input, chaining limits, and pricing but never says what the caller gets back from a chained run or how per-step outputs are presented. That return-shape gap is the main thing an agent still has to guess.

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 job, input, and max_steps are already documented with examples in the schema. The description adds only indirect meaning (that the job may span up to 3 chained capabilities, which contextualizes max_steps), leaving baseline 3 appropriate.

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

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

States a specific verb and resource: describe a job in plain words, and the tool selects among 71 capabilities, fills parameters, and chains up to 3 steps. It is unmistakably the orchestrator/meta-tool relative to the flat list of single-capability siblings like ai_translate or web_read, so an agent can tell what it is 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?

"Use when an agent has a job to get done and does not know which tool or in what order" gives a clear selection condition that implicitly routes the agent away from direct sibling invocation when the right tool is already known. What's missing is an explicit exclusion or a cost/precedence trade-off versus calling a specific sibling directly.

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 pricing ($0.005/call over x402 USDC), absence of rate limits, API keys or accounts, and the return shape (exact wei string plus ether plus chain). It omits error behavior for malformed addresses and whether the read is point-in-time, which keeps it short of a 5.

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

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

Two dense sentences: the use case and return contract come first, the routing exclusions second, the commercial terms last. Every clause carries information an agent would otherwise have to guess.

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 explain the return value and does (wei exact integer string, ether, source chain). Combined with chain coverage, cost model and auth posture, 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% and both parameters are documented there, including the chain enum and the base default. The description reinforces the chain list but adds no format or syntax detail 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 the exact verb, resource and scope: native coin balance of any address across five named chains, returned as wei and ether. It is immediately distinguishable from erc20-balance and portfolio siblings by name.

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?

Opens with an explicit use condition (deciding whether a wallet can pay before building a transaction) and names two exclusion routes with their endpoints. Nothing is left for the agent to infer about when to pick this tool.

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 exist, so the description must carry the whole burden — and it does disclose cost ($0.005/call), payment rail (x402/USDC), absence of rate limits, API keys, and accounts, which is exactly the operational context an agent needs before calling. It stops short of saying what happens when 'chain' is omitted (default chain?) and gives no indication of failure behavior for an unsupported chain.

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 decision context and the returned values, then the exclusions, then the commercial terms — a sensible ordering with no filler sentences. The pricing/payment sentence is dense but earns its place for an agent that must budget calls.

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 names the three returned values (height, timestamp, head age). For a one-optional-param read tool that is nearly sufficient; the only real gap is the default-chain behavior when 'chain' is omitted.

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

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

Schema coverage is 100% and the enum-like value list is already in the schema, so the description adds little on the single optional 'chain' parameter. It implies single-chain scope via the contrast with evm_chains but never states the default chain when the argument is left out.

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 returns: latest block height, its timestamp, and chain-head age. It also draws an explicit boundary against evm_tx (single transaction outcome) and evm_chains (multi-chain comparison), so an agent can separate it from its closest siblings without opening 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?

Opens with the decision it supports ('decide whether what it just read on-chain is fresh, or whether a node is behind') and then names two alternatives with the conditions that select them. Both when-to-use and when-not-to-use are stated explicitly.

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: read-only scope, five-chain support, exact return shape (raw 32-byte plus asUint, decode it yourself), and operational/cost traits (no API key, no rate limit, $0.005 per call paid over x402 in USDC). These are precisely the traits an agent can't infer from the schema.

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

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

Front-loaded with the triggering condition, then the exclusion list, then cost/access notes — a well-ordered four-sentence block with no filler. The first sentence is densely packed (behavior, chains, return shape) and would read better split, which keeps it just short of a 5.

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 explains what comes back (raw 32-byte result plus asUint) and that decoding is the caller's job — the key completeness gap for an escape-hatch tool. Payment and rate-limit conditions are also covered, leaving nothing an agent needs before calling 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 `to`, `data`, `from`, `block`, and `chain` are already documented by the schema. The description confirms the calldata-encoding expectation and the five-chain scope but adds no format, selector, or block-tag guidance 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: runs any read-only call with your own calldata on five chains and returns the raw 32-byte result plus asUint. It explicitly positions itself against the sibling family of typed routes (evm_balance, evm_erc20_balance, evm_nft_owner, evm_token_info), so an agent can distinguish it 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 an explicit selection rule ("Use when an agent needs a contract value that none of the typed routes covers") and an explicit exclusion list ("Do not use for balances, allowances, token data or NFT owners"), naming the alternative behavior in each case. It also frames itself as "the escape hatch, not the first choice," which is a clear priority signal.

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 full evidence bundle returned, notes staleness of the chain head, gives economic cost ($0.02/call over x402 in USDC), and states no API key or account is needed. It never explicitly says the transaction is not broadcast/signed, nor what happens when canSend is false, which keeps it short of a 5 for a tool an agent may act on.

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 trigger condition is front-loaded and the payment facts are placed last where they belong. The middle is one very long clause chaining seven return values, which is dense but each item corresponds to a distinct decision input, so little 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 5-parameter tool with no annotations and no output schema, the description compensates well by narrating the return payload in prose. Remaining gaps are the exact response shape (how canSend and the supporting fields are structured) and any failure or staleness-threshold behavior, which matter since there is no output schema to fall back on.

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 all five parameters (from, to, data, value, chain) are already documented in the input schema and the baseline of 3 applies. The description adds only indirect signal — 'gas this exact transaction needs' hints that data/value affect the estimate — but gives no format or default 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?

Opens with a concrete decision verb-phrase — 'answers canSend' — plus an enumerated list of the facts it returns (balance, gas, cost, revert simulation, nonce, contract detection, head staleness). It explicitly positions itself against the granular read siblings by stating 'Replaces five separate reads,' so an agent can tell it apart from evm_balance, evm_gas, evm_nonce, or evm_estimate_gas.

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

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

'Use when an agent is about to sign a transaction and must decide whether it will go through right now' gives a precise trigger condition. The 'replaces five separate reads' line routes the agent away from composite-vs-granular confusion, though it does not name the specific alternatives (evm_call, evm_estimate_gas) or state a when-not case such as post-broadcast status checking.

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 auth requirements (no API key, no account), cost and payment rail ($0.005 per call over x402/USDC), and the exact per-chain return fields including staleness. It stops short of saying what a chain that is down looks like in the response (omitted vs. ok=false) or any rate/failure behavior, which keeps it below 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, each doing distinct work: selection criteria, exclusions, and cost/auth. The decision-relevant guidance 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?

No output schema exists, so the description enumerates the return fields itself, and it covers the payment model an agent must know before calling. For a zero-required-param read tool this leaves nothing material unsaid.

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 already documents the enum values and the 'all when omitted' default. The description's 'every supported chain in a single call' corroborates but adds no syntax or format detail 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 — enumerate every supported chain with chain id, block height, head staleness in seconds, and ok — in one call. It explicitly distinguishes itself from evm_block, evm_gas, and evm_fees, so an agent can route 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?

Front-loads the use case ('when an agent has to pick a chain that is actually answering before it commits to one') and gives explicit exclusions naming the sibling endpoints for single-chain lookup and gas/fee pricing. Both when-to-use and when-not-to-use are 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 does substantial work: it discloses the data source and liveness ('read straight from Ethereum mainnet'), the non-error failure signal ('with found telling you when there is no record'), authentication ('No API key'), and cost/payment ('$0.005 per call, paid over x402 (USDC)'). The remaining gap is what happens if neither of the two optional parameters is supplied, which the description never addresses.

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

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

Three compact sentences, each with a distinct job: usage trigger, exclusions, then cost/auth. The trigger is front-loaded, and the pricing sentence is dense but earns its place because it tells the agent a real cost is incurred per 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?

With no annotations and no output schema, the description still covers the data source, the bidirectional result, the 'found' flag, auth, and cost. It stops short of describing the response shape beyond the flag and of clarifying that at least one of the two empty-required parameters must be given, which is the one operational ambiguity left.

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 schema already documents mutual exclusivity ('Use instead of name'), so the baseline would be 3. The description earns a bump by specifying that reverse resolution returns the *primary* ENS name, a semantic detail absent from the schema, and by naming the 'found' output flag that signals an empty result.

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 (resolves) and resource (ENS name / address) and explicitly frames both directions: forward resolution and reverse resolution to the primary name. An agent can distinguish this from every sibling in the evm_* family 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?

Opens with an explicit usage trigger ('Use when an agent has a name where it needs an address, or the other way round, before it can act') and then names two concrete exclusions with their sibling paths: /v1/util/address for format validation and /v1/evm/is-contract for wallet checks. When-to-use, when-not-to-use, and the alternatives are all present.

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 supplied, so the description carries the full burden. It does disclose cost ($0.005 per call over x402 USDC), that no API key is needed, and that the response includes a derived 'unlimited' flag — strong value. It stays silent on failure modes (non-contract token, missing decimals, unset allowance returning zero) and on rate limits, which matter for an agent deciding whether to retry.

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?

Effectively three sentences: trigger, return shape, exclusions, then cost/auth. Front-loaded with the usage trigger, and every clause carries information. The return-shape sentence is a long run-on ('raw and formatted with its decimals, plus unlimited, which flags...') that could be split for scanability.

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 describing the return payload (raw amount, formatted amount, unlimited flag). Payment and auth are covered. The one gap is the optional 'chain' parameter — the description never says whether it defaults or must be chosen, which an agent needs 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?

Schema coverage is 100%, so the schema already documents owner, spender, token and the chain enum, and the baseline would be 3. The description does not add syntax detail, but it does add meaning by framing owner/spender as the two parties of an approval relationship, which clarifies the roles better than the bare schema strings.

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: reads how much of a token a spender may still move on the owner's behalf, with raw and decimal-formatted values plus an 'unlimited' flag. It is unmistakably distinct from evm_erc20_balance and evm_token_safety, both of which it names.

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?

Explicit when-to-use (about to approve a spender, or auditing a prior approval) and explicit when-not-to-use, naming the two sibling endpoints by path that cover the adjacent questions (holdings, token safety). Nothing is left to inference.

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

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

With no annotations, the description carries the full burden and does: it discloses the exact return shape (raw integer string, decimals, formatted amount, symbol), that no API key or account is needed, and the $0.005 per-call cost paid over x402 in USDC. Pre-payment and auth requirements are exactly the behavioral context 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?

The usage trigger is front-loaded and every clause carries information (return fields, exclusions, pricing). The main sentence is dense and runs long, which slightly hurts scannability, but 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?

Return values, cost, auth model, and sibling routing are all covered, which is more than enough for a 3-parameter read tool with no output schema. The only gap is the chain parameter's optionality and default chain, left unaddressed.

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 address and token are already documented as 'Wallet to look up' and 'ERC20 contract address'. The description reinforces 'any address for any token' but adds nothing about the optional chain parameter or its default, so it stays at the baseline.

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

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

States a specific verb and resource — 'the ERC-20 balance of any address for any token' — and explicitly names what it is not (native coin balance, allowance). An agent can separate it from evm_balance and evm_erc20_allowance 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?

Gives the triggering condition ('confirm a wallet holds enough of a token before it swaps, pays or settles') and two explicit exclusions with the sibling endpoints to use instead. When-to-use and when-not-to-use are both 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 does well: it discloses cost, payment method (x402/USDC), no API key/account requirement, and key output semantics including wouldRevert. It does not explicitly state that the call is read-only/simulated and does not submit the transaction, which is an important behavioral detail for an agent.

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 the usage condition and remains tightly focused. The exclusions and payment/auth details each add concrete value without excessive 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, but the description enumerates the important return values: gas, current gas price, ether cost, and wouldRevert. Together with the full schema coverage, explicit exclusions, auth, and pricing information, it is complete enough for an agent to call 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 schema already documents all five parameters, including chain values and optional fields. The description does not add parameter-specific syntax or constraints beyond the schema, 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?

The description states a specific purpose: estimate gas for an exact transaction call, including gas price, ether cost, and wouldRevert. It clearly distinguishes this from sibling tools by explicitly excluding plain-transfer gas pricing (/v1/evm/gas) and EIP-1559 caps (/v1/evm/fees).

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 precise when-to-use condition: an agent is about to sign a transaction and needs to know failure risk and cost. It also gives explicit when-not-to-use cases and names the alternative endpoints for those cases.

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 delivers: no API key, no account, $0.005 per call paid over x402 in USDC, and the data source (last 20 blocks of real fee history). It does not describe the shape of the returned tiers or what happens if chain is omitted, which is the remaining 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?

Front-loaded with the activation condition, followed by exclusions and then cost/auth in a single dense block. Every clause carries information an agent needs; nothing is restated from the 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?

For a one-optional-parameter, no-output-schema tool, this covers trigger, exclusions, cost, auth, and computation source — enough to call it correctly. The only shortfall is the undocumented default/omission behavior for chain.

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 already lists base|ethereum|polygon|arbitrum|optimism in the schema. The description adds nothing about the parameter itself — notably not whether chain can be omitted or what the default is — so this lands at the high-coverage 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+resource (suggest EIP-1559 fee caps) with concrete scope: base fee plus maxFeePerGas/maxPriorityFeePerGas at slow/normal/fast, derived from the last 20 blocks. It explicitly distinguishes itself from evm_gas (legacy price) and evm_estimate_gas (per-call pricing), so an agent can route 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?

Explicit when-to-use (building an EIP-1559 transaction and needing caps that actually get mined) and explicit when-not-to-use, naming both siblings by their alternative routes. No inference required.

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 that the value is spot price and not a forecast, that there is no API key or account needed, that pricing is flat, and that each call costs $0.005 via x402 (USDC). It does not state rate limits, caching/freshness windows, or whether results are chain-defaulted, which is why it stops short of 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 use condition and the payload, then the exclusions, then the cost/access terms. Every sentence earns its place, though the parenthetical endpoint paths and the payment tail make it denser than strictly necessary.

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-optional-param tool with no annotations and no output schema, the description covers what is returned (wei, gwei, transfer cost in ether), what it is not (forecast, fee caps, call pricing), and the access/cost model. The only remaining gap an agent might want is the behavior when `chain` is omitted and the response shape.

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 optional parameter, so the schema already fully documents the accepted chain values. The description adds nothing about the chain parameter, not even which chain is used when it is omitted, 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 specific verb and resource: returns the chain's current gas price in wei and gwei plus the ether cost of a plain transfer. It also explicitly separates itself from evm_fees (EIP-1559 caps) and evm_estimate_gas (pricing a specific call), so an agent can route correctly 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 an explicit trigger ('when an agent is about to send a transaction and needs to know what it costs right now'), an explicit exclusion with the alternative endpoint for each ('Do not use for EIP-1559 fee caps ... or to price a specific call ...'). Both siblings are named with their routes, which is as strong as guidance gets.

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 non-obvious traits: a per-call price ($0.005) settled over x402 in USDC, and a self-describing result field (timingMatters) that signals when the answer is meaningless for a chain. It does not cover rate limits, failure modes, or latency, 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?

The trigger condition is front-loaded in the first clause, followed by outputs, exclusions, and pricing in a tight sequence with no filler. The main sentence is dense and long, which costs some readability but every clause adds 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, and the description compensates by enumerating the result components (current cost, percentiles, current position, timingMatters), which is exactly what an agent needs to interpret the response. Payment mechanics are also covered; only error and edge-case behavior is left 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 both `chain` and `blocks` are fully documented in the schema, making 3 the baseline. The description adds only a loose hint that the window is '~1000 blocks', which aligns with the blocks default of 1024 but gives no syntax or formatting 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?

The description names a specific resource (fee paid across the last ~1000 blocks of a chain) and specific returns (cost now, window percentiles, position of now, timingMatters) in one call. It is clearly distinguishable from evm_gas, evm_estimate_gas and evm_fees, which it also names explicitly.

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

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

It states the decision context directly ('Use when an agent can choose WHEN to send and must decide whether waiting would save anything') and gives two explicit exclusions with the alternative endpoints for each (/v1/evm/estimate-gas and /v1/evm/fees). Both when-to-use and when-not-to-use are covered.

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 return fields (isContract and bytecode size), the absence of an API key or account, the exact cost ($0.005), and the payment rail (x402/USDC). It does not state failure behavior for invalid or non-existent addresses, 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 decision scenario, then the return values, then the exclusions, then the cost/auth facts. Every sentence carries information an agent needs and none 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 read tool with no output schema, the description covers purpose, return shape, cost, and routing. The only gap is behavior on invalid or undeployed addresses (does it error or return false), which matters when bytecode size is part of the answer.

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 (chain with its allowed values, address) are documented there. The description adds only the framing of 'destination' for the address and no chain-selection guidance, 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 ('decide whether the destination is a plain wallet or a contract') and names exactly what it returns. It is clearly distinguishable from siblings like evm_balance, evm_code-adjacent tools, and evm_token_safety.

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?

Explicit when-to-use (about to send funds, before signing) plus explicit when-not to use, naming the two alternative endpoints (/v1/evm/token-safety and /v1/evm/verdict) with the reason each differs. Nothing is left to inference.

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

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

With no annotations provided, the description carries the behavioral burden and does so well: it says the data is read straight from the contract with no indexer, requires no API key or account, and costs $0.005 per call via x402 USDC. It implies a read-only operation but does not explicitly label it as such or discuss edge cases like burned or nonexistent tokens, so it falls short of a full 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 description is three tight sentences with the core purpose front-loaded, followed by exclusions and operational details. Every sentence contributes useful selection or invocation context, including cost and auth.

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, but the description names the key return values: current owner, tokenURI, and collection name. Combined with the explicit scope, exclusions, auth model, and pricing, it gives an agent enough information to call this tool correctly for a single-token lookup.

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 chain, tokenId, and contract. The description reinforces that the call is for an ERC-721 contract and one token id, but it adds no syntax, defaults, or parameter-level semantics beyond what the schema 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?

The description states a specific verb and resource: it returns the current owner of an ERC-721 token id, plus tokenURI and collection name. It clearly distinguishes the tool from wallet-wide holdings and ERC-1155 balances, so an agent can identify its scope without inspecting 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 an explicit use case ('when an agent must decide whether an NFT is still held by who it thinks') and explicit exclusions ('Do not use for a whole wallet's holdings or for ERC-1155 balances'). The one-token-id scope is stated directly, leaving little ambiguity about when to choose this tool.

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

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

With no annotations, the description carries the full behavioral burden and does disclose key facts: no API key, no account, and a $0.005 per-call x402 USDC payment requirement. It also explains what the pending nonce is for. It could be stronger by explicitly stating the operation is read-only and describing any rate-limit 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?

The description is front-loaded with the primary usage condition and packs output semantics, exclusions, auth, and pricing into a small number of useful sentences. Every sentence earns its place, with no redundant or vague 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?

Because there is no output schema, the description usefully explains the return values: confirmed nonce, pending nonce, and whether the address is a contract. It also covers payment and auth. A small gap remains around what happens when the optional chain parameter is omitted, such as a default chain.

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 address and chain, including the supported chain values. The description adds no parameter-level detail beyond the schema; it only explains the semantic meaning of the pending nonce in the output, so the baseline of 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?

The description clearly states the resource and purpose: fetching the confirmed nonce, pending nonce, and contract status for an EVM address. It distinguishes itself from evm_balance and evm_estimate_gas, though it does not explicitly address overlap with the sibling evm_is_contract even though contract status is one of the returned values.

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 use case ('when an agent signs transactions one after another and must not collide with one already in flight') and explicit exclusions with alternatives for affordability checks (/v1/evm/balance and /v1/evm/estimate-gas). This is exactly the kind of routing guidance an agent 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 provided, the description carries the disclosure burden and adds important context: it is a read-style balance lookup, returns formatted values with symbol and decimals, requires no API key or account, and costs $0.005 per call via x402 USDC. It does not cover failure behavior or rate limits, but the key operational traits are present.

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 the primary use case, then exclusions, then operational details like authentication and pricing. Every sentence adds useful routing or behavioral 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 simple read-only portfolio lookup with three parameters, the description covers the return contents, single-chain scope, batch behavior, and payment/auth model. It lacks exact output field names or error semantics, but no output schema is provided and the essential context 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 the schema already documents the chain, token list, and wallet address parameters. The description reinforces that balances are returned for every listed token on one chain, but it does not add syntax or constraints beyond the schema.

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

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

The description states a specific resource and action: retrieve a wallet's native balance plus the balances of listed tokens on one chain in a single call. It also explicitly distinguishes itself from sibling tools for single-token balance and token pricing.

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 both the intended use case and the exclusions: do not use for a single token (/v1/evm/erc20-balance) or for token valuation (/v1/evm/token-price). This gives an agent explicit routing guidance among sibling tools.

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 payout model ($0.005 per call, x402/USDC), the absence of auth ('No API key, no account'), and the key pending-state semantics ('found: false means it is not mined yet'). It stops short of stating how the optional chain parameter defaults or how reverts are represented in the payload, which is the 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 triggering condition is front-loaded, followed by return contents, the not-mined interpretation, the sibling exclusion, and the cost/auth terms. Every sentence maps to a distinct decision the caller must make; nothing is 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 does the heavy lifting: it enumerates the return fields an agent needs and explains the pending-state signal. Slightly short of complete because the chain parameter's default (when omitted) and the exact revert representation are unaddressed.

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 both parameters (hash, chain) are already documented with accepted values, so the description adds no syntax or format detail beyond the schema. Baseline 3 is appropriate; the description's value lies in behavior, not 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?

States a specific verb and resource ('the receipt by hash') and enumerates exactly what it returns: success/revert, gas used, fee paid in ether, log count. It explicitly carves out the sibling evm_tx case ('transaction's own fields like value or recipient'), so the agent can separate the two without opening either schema.

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

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

Gives a concrete triggering situation ('an agent is waiting on a transaction and has to answer did it work, and what did it cost') and a concrete exclusion with the alternative named ('Do not use for ... /v1/evm/tx returns both merged'). Both the when and the when-not are 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?

There are no annotations, so the description carries the full behavioral burden. It discloses that no API key or account is required, states the cost and payment mechanism, and specifies the return shape as hex and integer. It does not cover rate limits or failure behavior, which keeps it short of a 5 for a no-annotation tool.

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

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

The description is front-loaded with the primary use condition, then alternatives, then operational details. Every sentence contributes: usage, exclusions, return format, auth, and cost. 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 simple three-parameter read tool with no output schema and no annotations, the description supplies the missing context an agent needs: purpose, alternatives, return shape, auth requirements, and cost. Nothing essential is omitted for correct tool selection and 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 coverage is 100%, so the schema already documents address, chain, and slot syntax. The description adds meaningful interpretation of the slot parameter by naming concrete use cases: proxy implementation address, owner, and paused flag. That extra semantic context is useful, though the schema still does the primary parameter documentation.

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 operation and resource: reading a raw contract storage slot, returned as hex and as an integer. It explicitly distinguishes this from evm_call and evm_token_info, so an agent can tell when this tool is the right one without opening sibling 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?

It gives explicit use conditions ('when an agent must read something a contract does not expose with a getter') and explicit exclusions ('Do not use when the contract has a public getter' or 'for token data'), naming the alternative endpoints to use instead. The routing logic 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?

With no annotations, the description carries the burden and does well: it discloses that no API key or account is needed and states the cost ($0.005 per call, paid over x402 in USDC) plus the returned fields, which tells the agent this is a cheap read. It stops short of describing failure behavior for a non-contract or wrong-chain address, which matters for a lookup keyed on an arbitrary string.

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 trigger condition and the returned fields, then exclusions, then cost. The decimals aside ("a million times too big") is colloquial but earns its place as a usage rationale; the endpoint paths in parentheses are slightly redundant with the sibling names.

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, but the description enumerates the returned fields and the pricing/auth model, which is most of what an agent needs. The remaining gap is edge-case behavior (unknown chain, address with no code) for a tool whose only input is an unvalidated address string.

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 baseline is 3, and the description adds real meaning on top: it stresses that the input is a bare token address (not a symbol or pair) and explains why decimals is returned, which frames how the output should be used. It adds no guidance on default chain behavior when the optional chain parameter is omitted.

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 bundle and resource: returns name, symbol, decimals and total supply for any ERC-20 from a single address, in one call. It explicitly contrasts with evm_erc20_balance, evm_token_price and evm_token_safety, so the agent can distinguish it from its closest siblings 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?

Gives an explicit trigger condition ("a bare token address and must label or format it before showing or computing anything") and an explicit exclusion list naming three alternative endpoints with their paths. Both when-to-use and when-not-to-use are covered, leaving nothing 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 burden well: it discloses the data source (on-chain eth_call, not an aggregator), the pay-per-call model ($0.005 via x402 in USDC) and the returned fields, which is real behavioral value beyond the schema. It omits failure behavior — no pool, insufficient liquidity, unsupported token — and any latency or rate-limit expectations, which keeps it off 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 usage condition, then mechanism, return fields, sourcing and cost; every sentence contributes. The 'Via eth_call' fragment slightly restates 'the source is the chain itself', a small redundancy rather than a flaw.

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 listing the returned fields (pool address, fee tier, liquidity, sqrtPriceX96, tick, block) and the payment/auth requirement. The gap is the optional 'chain' parameter's default value, documented nowhere in schema or description, which matters for a tool with only one required argument.

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 parameters are already documented; the description adds only the pricing mechanism (deepest pool, quoted against USDC) as an interpretive gloss. It does not resolve the one real ambiguity — the optional 'chain' parameter has no stated default — so baseline 3 is right.

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 — spot price from the deepest Uniswap V3 pool against USDC — and names the supported chains, which cleanly separates it from siblings like evm_token_info, evm_token_safety, evm_call and fx_convert. An agent can tell what number it gets and where it comes from 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?

'Use when an agent must put a number on a token before trading or reporting, and be able to defend it' gives a clear triggering context, and 'No aggregator and no API key' explains the sourcing trade-off. It stops short of naming alternatives or stating when not to use it (e.g. tokens with no USDC pool), so it is clear context without explicit exclusion criteria.

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?

There are no annotations, so the description carries the burden, and it discloses several important facts: the result is deterministic, the call costs $0.01 via x402 (USDC), and it returns evidence (exact selector and byte offset) rather than a verdict. It does not explicitly state that the call is read-only or whether payment is required before the result is returned, so it falls slightly short of complete behavioral 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?

The trigger condition comes first, followed by detection scope, return semantics, determinism, and cost, in that order. All five sentences add information, and none 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?

Since there is no output schema, the description correctly explains what the result contains (evidence selectors plus offsets, and ownership-renounced status) and covers chains and pricing. It does not describe the response envelope or structure (for example, a per-check boolean versus a list), but for a two-parameter read tool this 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?

The input schema already documents both parameters at 100% coverage, including the chain list. The description merely restates the supported chains in prose, and it adds no syntax, formatting, or defaulting rules beyond what the schema provides. A score of 3 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?

The description uses the specific verb-resource pair 'pre-trade risk check on a token' and states that it analyzes deployed bytecode and live state across five named chains. It lists exactly which powers are detected (mint, pause, blacklist, upgradeable proxy, mutable buy/sell tax) and whether ownership is renounced, so an agent can clearly tell it apart from evm_token_info (metadata), evm_balance, or crypto_sanctions.

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

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

'Use when an agent must decide whether to touch a token at all' gives an explicit trigger condition, and the cost line ('$0.01 per call') helps an agent weigh whether it is worth calling. However, it does not name alternatives (such as evm_token_info or crypto_sanctions) or state any case in which the agent should not 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 so: it discloses the response contents, that it merges two RPC calls into one, that no API key/account is needed, and the exact cost ($0.005/call over x402 USDC). Pricing and auth requirements are behavioral facts an agent cannot infer from the schema.

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

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

Front-loaded with the use case, then exclusions, then behavior, then cost — a logical order with no filler. It is dense and slightly overpacked into a few long clauses, but every sentence contributes 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, and the description compensates by enumerating the returned fields and combined-call semantics. With no annotations, it still covers auth, pricing, and scope, leaving nothing an agent needs 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 description coverage is 100% and both parameters (hash, chain) are documented there. The description adds no format, syntax, or chain-default guidance beyond the schema, so this sits at the baseline for full schema coverage.

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: fetches a transaction by hash merged with its receipt in one call, listing exactly which fields (sender, recipient, value, gas used, success/revert, block). It explicitly names the sibling tools (evm_receipt, evm_estimate_gas) whose territory it does not cover, so the agent can distinguish it without opening 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?

Gives an explicit trigger scenario ("agent has sent a transaction and must decide what to do next"), plus two explicit exclusions with the alternative to use instead: evm_receipt for mined-or-not checks and evm_estimate_gas for pre-signing judgement. Nothing is left to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses provenance ('label and card come from the bytecode and live state, never from a model'), cost ($0.02 per call over x402/USDC), and idempotency ('a repeated requestKey is never charged twice') which is the key non-obvious billing behavior. It stops short of stating failure modes (non-ERC20 address, unsupported chain) or latency, 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?

Front-loaded with the trigger ('Use when...') followed by output shape, provenance, billing and disclaimer in that priority order — every clause carries information. It is one long colon-and-dash chain, though, and the four-label enumeration occupies a large share of the sentence.

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

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

There is no output schema, so the description must describe the return: it does (label, headline, plain reading, paste-ready card, per-selector evidence). Cost and idempotency are covered. What an agent still cannot infer is the default when 'chain' is omitted and what happens on an unsupported chain or a non-contract address.

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 requestKey description already spells out the 409/stored-answer/charged:false mechanics and the 24-hour paying-address binding. The description only echoes the idempotency promise and adds the 'five chains' count, so the schema is doing the heavy lifting. Baseline 3 is right.

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 ('a verdict on any ERC20 on five chains') and enumerates the exact output vocabulary (no-owner-powers, owner-can-intervene, owner-controls-balances, not-a-token), which is unusually precise. It never names or contrasts the obvious siblings evm_token_safety and evm_token_info, so an agent cannot tell from this text alone which of the three 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?

'Use when an agent needs one answer it can act on' gives a situational trigger, and the phrase 'Research, not investment advice' bounds expectations. But there is no explicit when-not, no named alternative for a deeper scan (evm_token_safety) or raw metadata (evm_token_info), and no stated prerequisite such as needing the token address already resolved.

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 does so well: it discloses the returned fields (rate used, publication date, euro-crossed flag), daily publication cadence, reproducibility, 90-day date limit, and cost/payment method. This is substantially more than the schema or annotations 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 description is front-loaded with the usage trigger, then efficiently covers scope, return values, distinction from live quotes, and cost. Every sentence adds useful information 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?

There is no output schema and no annotations, yet the description explains the return fields, publication timing, date limits, currency coverage, and payment model. For a simple four-parameter conversion tool, 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 description coverage is 100%, so the schema already documents all four parameters, including defaults for amount and date. The description reinforces the currency universe and date window but does not add syntax or formatting details beyond what the schema provides, 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?

The description states a specific verb and resource: convert money between currencies using the European Central Bank's official reference rates, with a clear ~30-currency and 90-day scope. It also explicitly distinguishes itself from a live market quote, so an agent can tell what this tool is and is not.

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 opening 'Use when an agent has to convert money in a figure someone will audit' gives a clear triggering condition, and 'not a live market quote' supplies an exclusion. It does not name an alternative tool for non-auditable or live conversions, but the context is otherwise strong.

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 payment mechanism (USDC over x402), that no account or API key is needed, automatic failover across several models, and typical sub-1s latency. It does not describe failure behavior when failover is exhausted or the response shape, 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?

The price is asserted three times ('flat $0.005 per call', '$0.005 per call, paid over x402', plus the title) and the 'no account/no API key' point is restated. The pricing hook is front-loaded, but roughly a third of the text 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 paid inference call with no output schema and no annotations, the description covers the unusual essentials an agent must know: cost model, auth (none), payment rail, failover, and latency. Only the return format and error semantics are left 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 schema already documents prompt, sistema, and maxTokens. The description adds only a marginal hint that token count does not change price, which the schema's maxTokens note already states. 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: 'POST a prompt, get the completion', plus the differentiating flat-rate pricing model. It does not name or contrast with the sibling chat_completions, so it is clear but not sibling-differentiated.

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 explicit guidance on when to pick this over chat_completions or the many content_* generation tools. The only contrast offered is against unnamed 'metered gateways', which is a market comparison, not a routing rule for 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, the description carries the full burden and does so well: it discloses model selection/failover, flat per-call pricing ($0.005), x402 USDC payment, and that billing occurs only if the answer is delivered. These are meaningful operational traits 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?

One dense paragraph, front-loaded with the use case and the exclusion, followed by pricing and failover details. Every sentence adds information or prevents a mis-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?

There is no output schema, but the description references the Anthropic response shape (content blocks, stop_reason) and request shape sufficiently for a client already targeting that API. Slightly more detail on the response envelope could help, though it is not essential.

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. The description adds conceptual meaning by explaining that model is ignored, system is a distinct field, and messages follow Anthropic text-block semantics, which helps an agent avoid misusing the shortcut.

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 capability: call a model via an Anthropic Messages API-compatible endpoint with no account, preserving request/response shape. It explicitly distinguishes itself from the OpenAI-shaped sibling chat_completions.

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 an explicit when-to-use condition (client written against Anthropic Messages API) and an explicit when-not-to-use condition (OpenAI shape, pointing to /v1/chat/completions). Alternatives are named, not merely implied.

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

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

With no annotations, the description carries the full burden and does most of it: it discloses output contents (each result plus head/tail tally), randomness quality (cryptographic, not Math.random), auth requirements (no API key, no account) and cost ($0.005/call via x402 USDC). Minor gaps remain on rate limits, failure modes, or response shape, but pricing and auth disclosure is unusually strong.

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 triggering condition and free of filler, but the first sentence is a long run-on that chains use case, output shape, and randomness quality together. Nothing is wasted, though it could be broken for scannability.

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, no-annotation, no-output-schema tool, the description covers what it returns ('each result and the tally'), how it authenticates, what it costs, and when not to use it. An agent has everything needed to call it and to pay for 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%, with the count range (1-100) and default of 1 already documented in the schema. The description mentions 'one or more fair coins' but adds no format, cost-per-coin, or edge-case semantics 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 concrete verb+resource: 'one or more fair coins, each result and the tally of heads and tails,' with the cryptographic-randomness qualifier. It explicitly names the siblings it is not (random_pick at /v1/random/pick, random_shuffle at /v1/random/shuffle), so the agent can route without opening 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?

Opens with an explicit use case ('break a tie or split a test and cannot be seen to have chosen') and immediately follows with negative routing to the two alternatives for >2 options and list ordering. The decision boundary is fully 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 load and does so well: it discloses the CSPRNG plus rejection sampling, explains why that matters for fairness versus a plain modulo, and states the cost model ($0.005 per call, paid over x402 in USDC) — an unusual and important operational constraint. It stops short of stating latency, limits on simultaneous calls, or failure behavior when payment is missing.

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 when-to-use clause, then fairness rationale, then exclusions, then pricing — a logical order with no filler. The first sentence is dense and run-on, packing trigger, output shape, and examples into one breath, which slightly hurts scanability.

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 two-optional-parameter tool with no output schema and no annotations is fully covered: the description explains the return payload (per-die rolls, total, notation), the randomness guarantee, and the payment requirement. An agent has everything needed to invoke it and interpret results.

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 both parameters are documented with ranges and defaults in the schema itself, so the description only adds the framing 'any number of faces'. Baseline 3 applies, with modest extra credit because the notation output (3d6) implicitly links count and faces to the result format.

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 immediately differentiates from siblings by naming /v1/random/pick and /v1/random/password as the wrong tools. The returned artifacts (individual rolls, total, standard notation like 3d6) further pin down what the tool produces.

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?

Explicit trigger is given ('when an agent has to produce a roll a player or an audit will check'), and two explicit exclusions route the agent to random_pick for choosing from a list and random_password for secrets. Nothing is left to inference about when this tool is the right choice.

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

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

No annotations are supplied, so the description must carry the load, and it goes well beyond the schema by naming the sampling algorithm and the bias guarantee. The repeated range check when unique=true constrains misuse. It stops short of covering edge cases (count exceeding range width), response shape, or being a fake-data source.

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: use case, exclusions, cost. Front-loaded and waste-free. The first sentence is long and carries several facts, so parsing is slightly dense compared to the rest of the document.

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

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

With no annotations or output schema, the description must supply routing, algorithm, and cost. It does all three. What is missing is return format (scalar vs list when count > 1) and error behavior when unique=true and count exceeds the range width.

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

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

Schema coverage is 100%, so the baseline is 3, and the description earns more: it foregrounds 'with or without repeats' (the unique flag) and states the range-width requirement when repeats are excluded. It does not explain count semantics or the min/max relationship explicitly in the description.

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

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

The description states a concrete verb and resource ('uniform random integers between your own bounds, with or without repeats') and distinguishes itself from random_pick and random_password. An agent knows exactly what this produces 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?

Explicit positive condition ('use when an agent needs numbers in a range') and explicit negative routing to two named siblings for picking items and for secrets. That is the full when/when-not/alternative triad.

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 discloses key traits: CSPRNG source, entropy return, four alphabets including a legible one for human readability, and per-call cost with payment method. It omits minor details like error handling or rate limits, but covers the essential behavior for a generator.

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 three sentences, front-loaded with the primary use case, and every sentence adds distinct value: purpose, key features, alternative, and cost. No wasted words.

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

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

Given no output schema and no annotations, the description sufficiently covers what the tool does, its output (entropy in bits), alphabets, and cost. It could be slightly more explicit about the exact return format (e.g., array of objects with password and entropy fields), but it is largely 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 coverage is 100%, so the parameter meanings are already fully documented. The description adds only a small clarification about the legible alphabet having no look-alike characters, but otherwise does not expand on count or length beyond what the schema provides. 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?

The description states a specific verb (mint) and resource (strong random passwords), and explicitly distinguishes from util_uuid for unique IDs. It also highlights the unique value of returning entropy in bits, making the tool's 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?

It provides explicit when-to-use (mint a secret and justify its strength) and when-not-to-use (IDs that only need uniqueness, with a named alternative /v1/util/uuid). This leaves no ambiguity about tool selection.

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 behavioral burden and usefully discloses that no API key or account is required, that calls cost $0.005 via x402/USDC, and that the result reports how many items were available. It does not cover rate limits or exact response/error behavior, 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?

The description is front-loaded with the decision context and exclusions, then closes with concise operational facts about auth and cost. Every sentence contributes useful selection or invocation 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 simple three-parameter utility with full schema coverage and no output schema, the description covers use case, alternatives, repeat behavior, auth, cost, and source-count output. It stops short of describing exact return formatting or edge cases such as insufficient items without repeats.

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 documented by the schema. The description reinforces repeats and count-from behavior but adds little syntax or constraint detail beyond the structured 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?

The description states a specific verb and resource: it picks one or more items from a supplied list. It also distinguishes this from the closest siblings by explicitly excluding ordering the whole list and drawing a number in a range.

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 use condition — several options with no reason to prefer any — and explicit exclusions pointing to /v1/random/shuffle and /v1/random/number. An agent can route correctly without consulting other tools.

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 to lean on, the description still discloses the important non-obvious traits: the algorithm and its uniformity guarantee, that no API key or account is needed, and the exact cost ($0.005/call via x402 USDC). It does not cover rate limits, failure modes, or what happens with duplicate items, which keeps it below 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 usage trigger and only three sentences total, each carrying a distinct payload (purpose/guarantee, exclusion, pricing/auth). The first sentence is dense and slightly run-on, but no sentence 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?

For a single-parameter tool with no output schema, the description covers the things an agent most needs before calling: the correctness guarantee, the alternative, and the payment/auth model. Return shape (presumably the reordered list) and edge-case behavior are left implicit, 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 100% and the single parameter already documents comma-separated vs JSON array input. The description adds nothing about the items parameter, so the baseline of 3 for a fully documented schema 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 (shuffle a list) and immediately qualifies the guarantee: uniformly random, Fisher-Yates over the platform CSPRNG. It explicitly names the sibling it is not (/v1/random/pick), so an agent can distinguish it from random_pick without opening either schema.

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

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

Gives an explicit when ('an order nobody can claim was arranged') and an explicit when-not with the alternative named ('Do not use to take just one or a few items (/v1/random/pick)'). It even explains why a naive approach (sorting by a random key) is not a substitute.

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 exist, so the description carries the full burden, and it discloses the two things an agent most needs to know beyond the payload: cost ($0.005 per call) and the payment mechanism (x402/USDC). It also characterizes the return payload in detail, including that prefix lists are sampled. It stops short of stating failure behavior for unknown or unannounced ASNs, so it is not fully 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?

Front-loaded with the trigger condition and tightly packed, with no filler sentences. It runs slightly long by repeating the endpoint paths in the exclusion clause, but every clause carries routing or payload information.

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

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

With no output schema and no annotations, the description compensates by enumerating return fields and stating price and payment rail, which is what an agent needs before spending money. The remaining gap is error/empty-result behavior for invalid or dormant ASNs.

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 and schema coverage is 100%; the schema already documents that the AS prefix is optional ("15169 or AS15169"). The description adds nothing about the asn argument, 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 (ASN lookup) and enumerates exactly what comes back: RDAP registry record, AS name, country, RIR, and currently announced IPv4/IPv6 prefixes. It distinguishes itself from the address-lookup and domain-lookup siblings by name, so an agent can pick it without opening a schema.

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

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

Explicit when-to-use ("when an agent has an origin ASN and must decide who is behind a network and whether it is still live") plus explicit exclusions routed to alternatives ("Do not use for one address (/v1/red/ip) or for a domain (/v1/red/whois)"). It even positions the call in a sequence: "The natural second call after /v1/red/ip."

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 no API key/account required, a concrete price ($0.005 per call) and the payment rail (x402/USDC), and clarifies the read-only nature and data source (CT logs, historical issuance rather than live serving). It even compensates for the absent output schema by enumerating the returned fields.

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 a 'Use when...' trigger, then the crucial scope clarification, then commercial/access facts — a sensible ordering. It is dense but nearly every clause adds information; the parenthetical field list is the only slightly heavy element.

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, no-annotation, no-output-schema lookup tool this is close to complete: trigger, data source, scope boundary, returned fields, access requirements and price are all present. Remaining gaps are minor operational details — rate limits, behavior on very large domains, and error semantics.

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 self-documenting; the baseline of 3 applies. The description adds conceptual value ("every hostname each certificate covers") that frames what the subdomains flag affects, but it does not explain the domain param's URL/email normalization — that detail lives only 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 verb and resource — audit every currently valid publicly issued certificate for a domain, read from Certificate Transparency logs — and enumerates the fields returned (issuer, validity window, expiry, revocation, hostnames). It also draws the key conceptual line, 'reports what was ISSUED ... not what the server is serving today', which separates it from live-TLS-style siblings like red_domain_check.

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

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

"Use when an agent must audit what certificates exist for a domain" gives a clear triggering context, and the follow-on sentence sharpens it into a concrete use case (finding certificates you did not know existed). It stops short of naming an alternative sibling or an explicit when-not-to-use case, so it is a strong 4 rather than 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 zero annotations, the description still covers the non-obvious behaviors: every list is re-verified with its RFC 5782 test entry so a dead zone reads as 'unavailable' rather than clean — a failure mode that materially changes interpretation. It also discloses no aggregate score, inclusion of delisting URLs, per-call pricing ($0.005 via x402/USDC) and the IPv4-only restriction.

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 usage condition, then behavior, then cost — no filler sentences. The density is high but every clause (list count, raw codes, test-entry rechecks, delisting URL, price) carries decision-relevant 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, yet return values (per-list raw code plus published reason text), the delisting URL, and the dead-list degradation path are all described, so an agent can interpret results without extra calls. Minor gap: nothing on rate limits, concurrency behavior, or what an all-clean response 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 already 100% and the single parameter's IPv4-only constraint is documented in the schema itself. The description adds only the phrase 'one IPv4 address', which restates the schema rather than extending it — baseline 3 for a fully-covered single-param tool.

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

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

States a concrete verb and resource ('checks one IPv4 address against nine public DNS blocklists at once') and names the specific lists, which separates it from the generic red_ip lookup and the domain/email checks. The agent knows exactly what it gets back — raw per-list codes, not a verdict.

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

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

'Use when an agent must decide whether an IP is already known for abuse' gives a clear triggering condition. It does not explicitly exclude neighbouring tools such as red_ip (reputation/geo lookup) or red_domain_check, so the routing to alternatives is left to inference 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 well: it discloses live DNS rather than cache, no API key or account required, per-call cost of $0.005 settled over x402 in USDC, and that calls are one-domain-at-a-time. Gaps remain around rate limits, behavior on an unregistered domain (error vs. structured result), and latency/timeout.

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 trigger condition, then the returned data set, then operational facts (auth, cost, batching) — a logical progression with no filler. The data enumeration is long but every item is decision-relevant for trust evaluation.

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 what comes back, and it does by listing each DNS signal collected. It is nearly complete for a single-parameter tool; only the result shape (structured object vs. text) and unregistered-domain behavior are left unspecified.

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?

A single required parameter with 100% schema description coverage, so the schema already explains that URLs and email addresses are reduced to their host. The description's framing ("whether a domain is real and reachable") reinforces intent but adds no new input semantics. Baseline for this configuration is met.

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 uses a specific verb and resource ("check a domain") and enumerates exactly what the call returns: registration status, A/AAAA, nameservers, MX, SPF/DMARC, DNSSEC, and parked detection. That enumeration lets an agent distinguish it from red_dnsbl (blocklists) and red_whois (registration records) 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?

"Use when an agent must decide whether a domain is real and reachable before trusting it" gives a clear use condition, and "built for going through a list of domains one at a time" sets the batching expectation. It stops short of naming when to prefer red_dnsbl, red_whois, or red_email_check instead, so no explicit exclusions are offered.

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 well: it discloses data provenance (two lists pinned to a commit, live MX/SPF/DMARC), scope limits (no SMTP probe, so mailbox existence is not verified), auth/cost model (no API key, $0.005 per call via x402/USDC), and the structure of the result. It stops short of error modes, timeouts or rate limits, which matters somewhat for a paid network-dependent 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-loaded with the decision context, then verdict semantics, then provenance, then cost — a sensible order with almost no filler. The exact list counts (12,141 / 4,897 / 1,018) are slightly noisy but do signal maintained coverage, so they mostly earn their 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 describe return values itself — and it does: a 0-100 score, an enumerated verdict, and per-point evidence tied to the proving field. Combined with the pricing and no-key disclosure, an agent has everything needed to call and interpret 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?

One parameter at 100% schema coverage, so the schema already documents the input fully. The description reinforces the one-address-per-call granularity ('scores one email'), but adds no syntax, normalisation, or batching semantics beyond that.

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 0-100 with a named verdict set (ok, risky, disposable, undeliverable, invalid) and itemised evidence. It is unmistakable against siblings like red_domain_check, red_dnsbl or red_asn, which operate on different subjects.

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 triggering decisions — before writing to an address, or cleaning a list before sending — so the agent knows when to reach for this rather than a generic DNS or domain tool. No explicit exclusions, but the use contexts are sharply drawn enough to route correctly.

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 well: it names the two data sources, describes the data retrieved, states key limitations, says it is designed for one-at-a-time lookups, and discloses the $0.005 x402/USDC payment requirement. It does not describe error behavior or response freshness, 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 description is front-loaded with the usage condition, then follows with sources, exclusions, batching behavior, and cost. Every sentence contributes specific information, and the length is appropriate for a paid lookup 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?

Although there is no output schema or annotations, the description names the key returned data elements: holder, country, date, abuse contact, and origin ASN. It also covers the payment model and limitations, leaving an agent with enough context to call and interpret the 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%, and the single parameter is already documented as an IPv4 or IPv6 address. The description adds only the framing of one address per call, which is useful but not substantially beyond the schema.

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

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

The description states a specific verb-and-resource target: looking up one IPv4/IPv6 address for ownership intelligence via RDAP and ASN data. It clearly scopes the tool against adjacent capabilities by excluding city-level geolocation and VPN/proxy detection, so an agent can distinguish it from related red_* and evm_* 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?

It gives an explicit use case: deciding whether to block or trust an IP. It also states what the tool deliberately does not cover, but it does not name sibling alternatives such as red_asn or red_whois for cases where those would be more appropriate.

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 well: it declares the data source (IANA bootstrap to RDAP), auth requirements ('No API key, no account'), the pricing model ($0.005/call via x402 USDC), and the important edge case that a TLD lacking an RDAP server is reported as such rather than as unregistered. That last disclosure prevents a real misinterpretation of the result.

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?

Opens with the usage trigger, then the data source, then the returned fields, then cost/auth — a sensible front-loaded order with no filler. Every clause contributes either routing information or behavioral context.

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

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

The tool is simple (one required parameter, no output schema), and the description compensates by enumerating the returned fields (creation/expiry/last-change dates, age, days to expiry, registrar, EPP status, nameservers, DNSSEC, abuse contact). An agent can decide and call correctly without further information.

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 that a URL or email is reduced to its host. The body text adds nothing about the domain argument, so this sits at the baseline for a well-documented single 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 verb and resource ('registration data read from the registry's own RDAP service') and explicitly contrasts with port-43 whois scraping, which pins down what kind of data this returns. It doesn't distinguish itself from adjacent siblings like red_domain_check or red_cert, so an agent must infer that 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?

Names two concrete trigger conditions: judging how established a domain is, and checking when it expires. There are no explicit exclusions or named alternatives, but the stated triggers are clear enough to route most calls correctly.

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 names the verdict categories, the score, the match structure (excerpt, offset, intent), the decoding passes (base64, hex, URL, reversed), invisible-character detection, determinism, the truncation honesty about what it could not inspect, and the payment/auth model (x402 USDC, flat price, no key). Not a 5 only because latency/error semantics 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?

Front-loaded with the trigger condition, then return shape, then capabilities, then exclusion and pricing — a sensible information hierarchy. Dense but not bloated; only the pricing/payment sentence is arguably separable from invocation guidance.

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 explain returns — it does, naming the verdict, score, and match fields. It also covers capabilities, limits, and payment. Minor gap: no explicit error or rate-limit behavior.

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 both parameters (text, source) are fully documented in the schema, including the 32 kB truncation behavior. The description adds no syntax or usage 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?

Names a specific verb (classify) and resource (untrusted text entering a model context), and explicitly distinguishes itself from the sibling it could be confused with (/v1/evm/token-safety). An agent can tell exactly 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?

States the triggering condition (untrusted text — email, web page, another tool's output — entering a model's context) and the exclusion (not for ERC20 contracts, use token-safety). Both when-to-use and when-not are 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 so well: it discloses the tz database source, the exact return contents (both sides with offset, abbreviation, DST flag, UTC instant, hour difference), edge-case warnings for nonexistent or ambiguous local times, and the cost/payment mechanism ($0.005 per call via x402 USDC). Those are exactly the traits an agent could not infer from structured fields.

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 trigger condition is front-loaded and every sentence contributes (conversion scope, return shape, DST edge cases, price). It is dense and slightly run-on with stacked colons, but no sentence is filler.

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