Agent Data Tools

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

Goes well past the annotations (readOnly/openWorld/non-idempotent) to disclose pricing ($0.01/call, failed calls free), payment paths (x402 USDC or card key), a legal restriction on storing/resale/training, and the failure mode ('Says so when the sources do not answer it'). The non-idempotent, charged-per-call economics are surfaced explicitly, which is exactly the context annotations cannot carry.

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 capability and output format before terms and pricing, and nearly every clause carries decision-relevant information. Minor redundancy: 'each call is charged, so repeats are not free' restates the earlier price line and the readOnly safety claim is largely covered by the annotations.

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 carries the full return-value burden and does: citations format, source list contents, and the negative case when sources are insufficient. Cost, licensing, and safety are all present — 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 the single parameter already documents the 400-character limit, so the schema does the heavy lifting. The description adds only an example question string, which illustrates shape but not semantics beyond the schema.

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

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

States a specific verb+resource ('Answer a question from the live web') and enumerates the internal pipeline (Brave search, top pages read, Llama 4 Scout synthesis) plus the output shape (inline [n] citations, source list). Clearly separable from siblings that return raw text or raw search results.

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 a current, sourced answer rather than raw search results' gives an explicit selection rule, and the worked example (q=What is the x402 payment protocol?) anchors it. It stops short of naming specific sibling alternatives such as ai_fact_check or ai_chat, so an agent must infer the boundary itself.

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

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

Beyond the readOnly/destructive annotations it discloses billing behavior that materially affects invocation strategy: $0.002/call via x402 USDC or a card key, first 25 free, failed calls free, and an explicit warning that repeats are not free (explaining idempotentHint=false). It also states no provider account is needed and that the call changes nothing.

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

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

Purpose and free-tier/cost facts are front-loaded, and every sentence carries operational information. The single example ('prompt=Explain x402 in one sentence..') is truncated and adds little, and the tail end (pricing, read-only note) is densely packed into one run-on 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?

With 8 parameters, rich annotations and full schema coverage, the description covers cost, model identity and routing adequately. The one gap is the response shape: there is no output schema, yet the description never says what is returned (answer text plus optional tool_calls), which matters for the function-calling parameters.

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 prompt, system, messages, tools, maxTokens, temperature, tool_choice and response_format are already fully documented. The description only echoes a few of these (optional system prompt, up to 1,024 output tokens, adjustable temperature), adding little beyond the schema; baseline 3 applies.

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

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

States a specific verb+resource ('send a prompt, get an answer') and pins the exact model (Llama 4 Scout, 17B active/16 experts) with its output limit and temperature range. It distinguishes itself from siblings by naming ai_chat_large for harder reasoning and pointing to /v1/chat/completions for other open models.

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 explicit use cases (drafting, reasoning steps, Q&A, any quick LLM call with no provider account) and an explicit alternative with the condition that selects it ('harder reasoning at ai_chat_large'). An agent can route between this and its sibling without inferring anything.

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?

Annotations already cover safety (readOnly, non-destructive, openWorld, non-idempotent), and the description adds the economically critical context they cannot: $0.01 per call via x402 USDC or card key, failed calls free, and that repeated identical calls are still billed. That cost-on-repeat disclosure is exactly the kind of behavioral fact that changes agent strategy.

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?

Model choice, cost and usage guidance are front-loaded in a compact block, and almost every clause earns its place. Minor bloat from the redundant 'Same call as /ai/chat with a stronger model' repetition and a stray double period in the example.

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 covers models, limits, price and the read-only nature of the operation, which is what an agent needs before calling. It stops short of describing the response shape (e.g. whether raw text or a JSON envelope with usage/cost is returned), a small gap for a text-generation endpoint.

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

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

Schema description coverage is 100%, so all five parameters are already documented in structured fields. The description restates the optional system prompt, the 1,024 output-token ceiling and adjustable temperature, and adds only the useful nugget that llama-3.3-70b is the default model. That meets the baseline but does not meaningfully exceed 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 opens with a concrete verb and resource (send a prompt, get an answer) and names the exact backing models including the default. It explicitly positions itself against the sibling ai_chat as the same call with a stronger model, so an agent can distinguish 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?

It states the selection condition clearly: use when the 8B model is not enough, for reasoning, drafting and Q&A, and names ai_chat as the alternative for lighter work. A worked example (prompt=Explain x402 in one sentence) anchors the expected input shape.

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?

Annotations already declare readOnly, non-idempotent, open-world, non-destructive, so the bar is lower; the description goes further by disclosing cost ($0.01/call), the free tier (first 25, failed calls free), and the payment paths (x402 USDC or card key /credits). 'Each call is charged, so repeats are not free' usefully explains the non-idempotent hint. 'Reads or computes only and changes nothing' repeats readOnlyHint rather than adding, but does not contradict it.

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

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

Front-loaded with the core capability and input/output shape in the first sentence, with secondary use cases and billing in the second. The pricing sentence is dense but earns its place because cost drives re-call behavior; nothing is filler.

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

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

For a simple two-parameter tool with no output schema, the description covers what comes back (best label, reason, ranking), the cost model, and the side-effect profile. An agent has enough to decide whether to call it and what to expect in the response.

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

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

Schema description coverage is 100% and both parameters are documented there, so the schema carries the semantics. The description restates the 2-20 label constraint, but adds no syntax detail (e.g. how commas inside labels are handled) or guidance on label design beyond what the schema already says.

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 operation with its input shape (text plus 2-20 candidate labels) and output shape (best label, reason, ranking), which is far more than the title restated. It is implicitly distinguishable from siblings like ai_sentiment or ai_moderation because the caller supplies arbitrary labels, though no sibling is named 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?

Concrete use cases are given: routing tickets, tagging content, intent detection, moderation queues. There is no explicit exclusion or comparison to overlapping siblings (ai_sentiment for polarity, ai_moderation for policy checks), so the agent must infer the boundary itself.

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

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

Goes well past the annotations: it discloses per-call pricing ($0.01 via x402 USDC or a card key), the 25 free calls, that failed calls are free, and that repeats are not free — which explains the idempotentHint=false in billing terms rather than merely restating it. It also explicitly confirms the readOnly/non-destructive profile ('Reads or computes only and changes nothing'), adding auth/payment context the annotations do not carry.

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 output contract, then uses, then a concrete input example, then cost. Dense but nearly every sentence carries distinct information; the example and pricing sentence are both functional, though the example is marginally expendable.

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 exactly what is returned and its dimensionality. Input limits, language coverage, cost model and side-effect profile are all covered, so 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 there is only one parameter, so the schema already documents `text` fully. The description's 'up to 4,000 characters' and the inline example echo that, adding format intuition but no genuine semantics beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb+resource with the exact output shape (1,024-dimension vector for up to 4,000 characters, 100+ languages) and names the underlying model BGE-M3. This makes it trivially distinguishable from generative siblings like ai_chat, ai_summarize_text or ai_classify.

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?

Explicitly lists intended uses: semantic search, RAG retrieval, clustering, deduplication. However it gives no when-not guidance or comparison to alternatives such as ai_classify or ai_keywords, so an agent must infer that embeddings are for vector/retrieval work rather than labeling.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=false, but the description adds meaningful context beyond them: per-call pricing ($0.01/call via x402 USDC or card key), first 25 free, failed calls free, and the fact that repeats are charged. It also states output behavior—null for missing fields—which is important for an extraction 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 purpose is front-loaded in the first sentence, followed by usage, then pricing/safety information. Every sentence adds something useful, though the pricing/safety sentence is slightly dense and could be split for readability.

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 extraction tool with no output schema, the description covers purpose, output shape, billing model, and safety profile. Combined with a fully described input schema and informative annotations, an agent has everything needed to decide when and how to call it.

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

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

Schema coverage is 100%, so the two parameters (text and fields) are fully documented in the schema with character limits and field-count constraints. The description only implies 'named fields' and does not add syntax or format details beyond what the schema already 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?

States a specific verb+resource ('pull named fields out of unstructured text') and the return shape (JSON object with null for missing fields). This is clearly distinguishable from sibling tools like ai_classify, ai_summarize_text, or ai_answer, which transform text in other ways rather than extracting named fields.

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

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

Gives a clear usage statement: 'Use to turn messy text into structured data for an agent,' with example source types (emails, invoices, listings, bios). It does not explicitly name alternative tools or exclusions (e.g., use ai_classify for categories), so it stops short of a 5.

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

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

With annotations present, the description still adds substantial context: pricing ($0.01/call via x402 USDC or card key), failed calls free, repeated calls charged (consistent with idempotentHint=false), and Brave API terms restricting reuse of results. It also discloses the verdict vocabulary and the output shape (explanation, [n] citations, sources).

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

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

Front-loaded with what the tool does and returns, then caveats, then use case, then pricing. Dense but nearly every sentence carries operational information; the price/payment sentence is long but justified for an agent deciding whether to 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, and the description compensates by describing the return: a verdict from a fixed set (supported, contradicted, mixed, unverified), a short explanation, numbered citations, and the sources. Nothing an agent needs to decide or interpret the call is missing.

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

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

Schema coverage is 100% and there is only one parameter, so baseline is 3. The description adds an example claim ('The x402 protocol uses the HTTP 402 Payment Required status code.') that shows the expected granularity, going slightly beyond the schema's length constraint.

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 (check a claim against the live web) and spells out the pipeline (Brave search, page reads, Llama 4 Scout verdict). No sibling tool in the list does fact verification, and the description makes that unique role obvious.

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: 'Use to screen a statement before an agent repeats or acts on it.' It also sets expectations with 'A model's reading of a few search results, not an editorial fact-check.' It doesn't name an alternative tool for cases where a plain answer (ai_answer) would suffice, so it stops short of explicit alternative routing.

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

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

Annotations already cover read-only, non-destructive, non-idempotent, and open-world behavior, but the description adds meaningful context about pricing, the free quota, failed-call billing, and repeat charges. It also restates read-only behavior, though without contradicting the annotations.

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

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

The description is a single front-loaded paragraph with no irrelevant sections. The pricing and billing sentence is dense but still earns its place by clarifying cost behavior.

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 tool with full schema coverage and no output schema, the description supplies purpose, return ordering, use cases, and billing details. Nothing critical for correct invocation appears to be missing.

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

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

Schema description coverage is 100%, so both parameters are already well documented in the schema. The description does not add parameter-level meaning beyond the schema; 'most relevant first' describes return ordering rather than input 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 the extracted resource (keywords and key phrases) and its ordering (most relevant first), and the title adds the explicit extraction verb. It does not clearly distinguish this tool from nearby siblings such as ai_extract_json or ai_summarize_text.

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 useful use cases (tagging, SEO, search indexing, topic detection) but does not say when to choose this over alternatives or when not to use it. Usage is implied rather than explicitly routed.

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

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

Beyond the annotations (readOnly=true, openWorld=true, destructive=false), the description discloses pricing ($0.01/call via x402 USDC or card key), that failed calls are free, that repeat calls are charged, the 2,048 output-token ceiling, and that reasoning traces are stripped from the answer. That is exactly the extra context annotations cannot carry, and it is consistent with readOnlyHint.

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 model identity, access paths, cost and behavior are front-loaded in a dense but readable block, and every clause carries information. It is slightly run-on (the stray double period after the example, the trailing clause about repeats) but not padded.

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

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

With no output schema, the description carries the return-value burden and does explain that the answer comes back without reasoning and is capped at 2,048 tokens, plus cost and payment paths. It does not describe the response envelope or error shapes, which is the remaining gap for a paid single-shot call.

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

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

Schema description coverage is 100%, so prompt, system, maxTokens and temperature are already documented with limits and defaults. The description restates the prompt/system pairing and the output-token cap but adds no format or interaction detail (e.g., how temperature affects reasoning), 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?

The description names a specific verb ('Chat with') and a specific resource — DeepSeek R1 distilled into Qwen 32B — and explicitly separates it from generic siblings like ai_chat by saying 'Use when an agent wants this model by name.' It also names the equivalent API route ("deepseek-r1" on /v1/chat/completions), so the model identity is unambiguous.

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 selection rule ('Use when an agent wants this model by name') and a concrete example call, which implicitly routes generic chat needs to the non-model-specific siblings. It doesn't explicitly name ai_chat as the fallback or state when not to use it, so it stops short of full alternative routing.

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

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

Goes well past the annotations: discloses per-call price ($0.01), payment rails (x402 USDC or card key), that failed calls are free, that repeats are charged and non-idempotent, and that no account/provider key is needed. That is exactly the cost/auth/failure context annotations cannot convey.

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

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

Front-loads model identity and the core action, then layers pricing and payment detail efficiently. It is dense but nearly every clause carries information; minor noise like the stray double period in the example slightly hurts polish.

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

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

With no output schema, the description does say what comes back (the answer, capped at 1,024 output tokens) and covers cost, auth, and failure handling for a paid external call. An agent has enough to invoke it correctly, though the response envelope shape is only loosely implied.

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 (prompt, system, maxTokens, temperature) are already documented with limits and defaults. The description only restates the 1,024-token output cap and the optional system prompt, adding essentially nothing beyond the schema; baseline 3 applies.

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

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

States a specific verb (chat) and resource (OpenAI's open-weight gpt-oss-120b reasoning model), and pins the exact model name, which is the key differentiator against siblings like ai_model_gpt_oss_20b. It never explicitly contrasts itself with those siblings, so the differentiation is implicit rather than stated.

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

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

"Use when an agent wants this model by name" plus a concrete example gives clear selection context, and the OpenAI-compatible endpoint note helps agents routing by model string. It stops short of naming alternatives (e.g., when to pick gpt_oss_20b or ai_chat instead), so there are no explicit exclusions.

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

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

Annotations already declare readOnly/openWorld/non-idempotent, and the description goes well beyond them: exact price ($0.002/call via x402 USDC or card key /credits), failed calls are free, each call is charged so retries cost money, no account or provider key required, and the 1,024 output-token ceiling. That is precisely the cost/auth/retry 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?

Front-loads the model identity and access method, then pricing and safety in a tight sequence; nearly every sentence earns its place. Minor blemishes: the example 'prompt=Explain x402 in one sentence..' has a doubled period and is marginally decorative.

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-parameter chat tool with no output schema, the description covers what comes back (the answer, capped at 1,024 tokens), how to pay, that no key is needed, and that calls are billed individually. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so prompt, system, maxTokens and temperature are already documented with ranges and defaults. The description restates prompt/system and the token cap and adds a worked example, but adds no format or interaction semantics beyond the schema — baseline 3 applies.

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

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

States a specific verb+resource (chat with OpenAI's gpt-oss-20b reasoning model) plus the access path (one paid HTTP call, or the OpenAI-compatible /v1/chat/completions as model "gpt-oss-20b"). It explicitly distinguishes itself from the generic ai_chat and from its size sibling gpt_oss_120b by naming the exact model and telling the agent to use it 'when an agent wants this model 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?

'Use when an agent wants this model by name' gives a clear selection condition versus the generic chat siblings, and the price note hints at cost trade-offs. It stops short of explicitly naming an alternative for when cost or the larger 120B model matters, so no exclusion is spelled out.

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?

Adds substantial context the annotations cannot carry: price ($0.005/call), failed calls free, payment paths (x402 USDC or card key /credits), no account or provider key required, and the 1,024 output-token cap. The "reads or computes only and changes nothing" statement is consistent with readOnlyHint=true, and "repeats are not free" aligns with idempotentHint=false.

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 model identity and payment model, which are the deciding facts. Slightly run-on and marred by a doubled period in the example, but nearly every sentence carries distinct information.

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

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

For a 4-parameter stateless chat tool with no output schema, the description covers cost, limits, auth, and the alternate endpoint, so an agent can call it correctly. The response format (plain answer text) is only implied by "get 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 coverage is 100%, so the schema already defines prompt, system, maxTokens, and temperature with ranges and defaults. The description only echoes the prompt/system pair and the output token cap, adding no syntax or format detail beyond structured data — 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 (chat with) plus the exact resource: Mistral Small 3.1 24B, with license and OpenAI-compatible alias. This makes it trivially distinguishable from sibling model tools like ai_model_qwen3_30b or ai_model_deepseek_r1.

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 wants this model by name" gives an explicit selection condition, and the /v1/chat/completions alias offers an alternative access path. It does not compare against the other ai_model_* siblings, so an agent choosing between models gets no comparative 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?

Beyond the annotations, the description discloses pricing ($0.002/call), billing paths (x402 USDC or card key via /credits), that failed calls are free, that repeats cost money, that no account or provider key is needed, and that reasoning traces are stripped from the output. That is exactly the extra context annotations cannot express.

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 model identity and call shape, then cost and access details. It is a dense run-on with a slightly awkward example fragment ("Example: prompt=Explain x402 in one sentence.."), but nearly every clause carries useful 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 single-call inference tool with no output schema, the description covers cost, auth alternatives, output limits, what the response omits (reasoning), and side-effect-free behavior. An agent has everything needed to decide to call it and predict the charge.

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 length, system prompt, maxTokens range/default, and temperature range. The description adds only the 1,024 output-token cap and an example prompt, which duplicates the schema's maxTokens note without adding format or tradeoff guidance (e.g. how temperature affects this model).

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 (chat), a specific model (Alibaba Qwen3 30B-A3B MoE, Apache 2.0), and the exchange shape (send prompt + optional system prompt, get answer). This sharply distinguishes it from siblings like ai_model_gpt_oss_120b or ai_model_mistral_small that share the same pattern.

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 wants this model by name" gives an explicit selection rule against the other ai_model_* siblings, and the OpenAI-compatible alias note clarifies an alternate route. It stops short of saying when to prefer a sibling like ai_chat_large instead, but the routing intent is clear.

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

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

Beyond annotations, it discloses pricing ($0.005/call), payment paths (x402 USDC or card key), that failed calls are free, that repeats are charged, and that the tool only reads/computes and changes nothing. It also notes no account or provider key is required and that output is capped at 1,024 tokens.

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 model identity and core action, and most sentences carry useful pricing or behavior context. It is slightly dense and includes minor redundancy around the token limit, but no major waste.

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

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

For a paid, no-auth LLM call tool, the description covers identity, cost, payment, limits, safety profile, and endpoint alternative. With complete schema coverage and annotations, an agent has enough to call it correctly; an output schema is unnecessary for a familiar chat-completion response.

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

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

Schema description coverage is 100%, so all four parameters are already self-documenting with types, defaults, and limits. The description adds only a brief mention of prompt/system and an example prompt, without extra semantics for maxTokens or temperature 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 — chat with Alibaba's Qwen2.5 Coder 32B code model through a paid HTTP call — and explicitly identifies the model by name. It also distinguishes this tool from generic chat siblings by saying to use it when an agent wants this model specifically.

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 wants this model by name,' and notes the OpenAI-compatible endpoint alternative. It does not explicitly compare against sibling tools like ai_chat or ai_model_qwen3_30b, so it falls short of full when/when-not 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?

Adds substantial context beyond the annotations: pricing ($0.002/call via x402 USDC or card key), the first 25 free, failed calls free, and the key insight that repeats are charged — which explains why idempotentHint is false. It also confirms the read-only, no-side-effects nature and the 8,000-character ceiling.

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 purpose and taxonomy, then usage, then pricing. The final sentence is dense but each clause (free tier, failed-call billing, non-idempotency) 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?

For a one-parameter tool with no output schema, the description covers what comes back (safe/unsafe plus named hazard categories) and the cost model. Only the response envelope/format remains unspecified, 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 is already documented in the schema. The description's 'Up to 8,000 characters' and the example repeat rather than extend that, 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 ('Classify a text as safe or unsafe with Meta's Llama Guard 3'), names the exact hazard taxonomy and its size, and is clearly separable from siblings like ai_classify or ai_sentiment. The example input pins down the expected call shape.

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 contexts ('screen user messages, model outputs or content before an agent posts or acts on it') and points to the alternate OpenAI-shaped endpoint at /v1/moderations. No explicit exclusion versus ai_classify, so it stops short of full when/when-not 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?

Annotations already declare readOnlyHint and destructiveHint=false, yet the description still adds real context: pricing model, free-tier terms, and that failed calls are free. 'Each call is charged, so repeats are not free' usefully reinforces the idempotentHint=false annotation. It doesn't describe latency or output length limits, 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?

The core purpose and output format are front-loaded in the first sentence, followed by usage and an example. The pricing/key sentence is dense but earns its place by warning the agent that calls are billed and non-idempotent.

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 generation tool with no output schema, the description covers what comes back (Markdown headings and bullets), what goes in, and the cost model. Only the depth parameter's effect on output shape is left unexplained.

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

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

Schema coverage is 100%, so both parameters are already fully documented. The description's example clarifies what the 'text' value looks like in practice but adds nothing about the 'depth' parameter (1-3 heading levels), leaving it to 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 output artifact ('structured Markdown outline of headings and bullet points') plus the two input modes: a supplied text or a topic. It does not explicitly differentiate from near-siblings like ai_summarize_text or ai_rewrite, so it stops short of a 5.

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

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

Gives concrete use cases ('plan articles, reports, talks and documentation') and a worked example, which is clear usage context. It never says when not to use it or names an alternative tool for overlapping tasks such as summarizing.

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?

Goes well beyond the annotations by disclosing truncation limits (2,000 chars per doc, 40,000 total), the 50-document cap, the return shape (index, score, text, best first), and pricing ($0.002/call, first 25 free, failed calls free). It also resolves the idempotentHint=false annotation with a concrete reason: 'each call is charged, so repeats are not free'.

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

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

Front-loads the core operation and stays to a single dense paragraph with no filler. The pricing clause is long but earns its place because it explains the non-idempotent charging behavior; a slight tightening would push this to 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?

There is no output schema, yet the description fully documents the return payload and ordering, plus limits, cost and side-effect profile. For a 3-parameter tool of this complexity, an agent has everything needed to call 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%, so baseline is 3; the description still adds real meaning by specifying per-document and total character truncation and the semantics of top_n ('keeps only the best'). The documents parameter's input encoding is already in the schema, so no further lift is needed.

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 specific verb+resource+metric: 'Order up to 50 documents by how well each answers a query, with a relevance score from 0 to 1', and names the underlying model (BAAI bge-reranker-base, a cross-encoder). This clearly separates it from sibling embedding/chat tools like ai_embed and ai_chat.

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?

Explicitly states the use case: 'Use to pick what a model reads after search or vector retrieval', and points to a Cohere-style alternative endpoint at /v1/rerank. It does not spell out when NOT to rerank or contrast against sibling tools such as ai_embed, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, destructiveHint=false and idempotentHint=false; the description reinforces the non-idempotency with an operational reason ('each call is charged, so repeats are not free'). It also discloses cost, billing paths (x402 USDC or card key /credits), the 25-free allowance, and that failed calls are free — real behavioral context annotations cannot express. Return-format detail is the only gap, and no output schema exists.

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

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

Purpose, styles, use cases, example, then cost/safety in one tight block — front-loaded and free of filler. The pricing and billing clauses are dense but each carries distinct 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?

For a simple 2-parameter transformation tool with annotations covering the safety profile and no output schema, nothing needed to invoke it correctly is missing: input shape, example, meaning-preservation guarantee, cost, and repeat-call behavior are all present.

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

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

Schema description coverage is 100% (both params documented, enum listed, default professional stated), so the schema already carries parameter meaning. The description only repeats the style list and gives one sample text value; it adds no syntax or edge-case guidance 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 (rewrite) and resource (text) plus the full set of target styles, and adds the invariant 'keeping the meaning and language.' This distinguishes it cleanly from siblings like ai_summarize_text, ai_translate, and ai_chat.

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

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

Gives concrete usage contexts ('polish emails, replies, product copy and messages') and a worked input example, so an agent knows when this is the right call. It does not name an alternative or an explicit when-not case (e.g. shortening vs summarizing), so it stops short of 5.

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

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

Beyond the annotations it discloses refresh cadence (~every minute), cost ($0.01/call via x402 USDC or card key, first 25 free, failed calls free), and that repeats are not free — which directly explains the idempotentHint=false annotation. It also clarifies the empty-result behavior ('normal when nothing is reported'), so the agent knows an empty response is not an error.

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 capability and the field list before the calling convention, cost, and safety note. It is dense but every sentence carries information; the payment sentence is a bit long, which keeps it just short of the top score.

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 a single optional parameter, the description fairly complete: it names the returned field groups and their reasons, the freshness, the empty state, and the cost. It does not describe the response envelope (single object vs list of events), which is the one loose end for an agent parsing 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%, so the baseline is 3, but the description adds an example (airport=LGA) and the semantic that omitting the parameter covers the whole country and that no events means normal operations. That last point is genuinely new relative to the schema's 'default: all US airports with events'.

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: live FAA National Airspace System status for US airports, enumerating ground stops, ground delay programs, arrival/departure delays with min/max/trend, and closures. No sibling tool in the list covers aviation status, so there is no ambiguity to resolve, and an agent can tell exactly what this returns.

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

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

It gives a clear use context ('before travel planning, logistics or customer notices') and explains the two calling modes: an IATA code for one airport, or nothing for the country. What is missing is any exclusion or named alternative, though no sibling tool overlaps this domain, so that gap is minor.

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?

Annotations already cover read-only/destructive semantics, but the description adds what they cannot: per-call cost ($0.01 via x402 USDC or card key), the 25-call free tier, failed calls free, and an explicit reason why idempotentHint=false matters ("each call is charged, so repeats are not free"). That cost-and-repeat guidance is decision-relevant information an agent would otherwise have to discover by spending money.

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

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

Purpose is front-loaded, followed by use cases, example, pricing, and safety note — a sensible order. Minor blemishes: a doubled period in the example ("within minutes..") and a dense pricing clause that packs several facts into one 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?

With one parameter, no output schema, and annotations already declaring safety, the description covers language, cost, and side-effect profile; the return value is sketched (label + confidence). It could be slightly more explicit about the exact response shape, but nothing needed to call it correctly is missing.

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

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

Schema coverage is 100% and the single `text` parameter is already documented with its 4,000-character limit. The description reinforces the English-only constraint and supplies an example value, but adds no syntax or formatting detail beyond the schema — baseline 3 is appropriate.

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

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

States a specific verb and resource — predicts positive/negative sentiment of English text with a confidence score — plus the underlying model (DistilBERT fine-tuned on SST-2). An agent can immediately distinguish it from generic siblings like ai_classify or ai_moderation because the output is a fixed two-way label with a score.

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 to triage reviews, support messages, social posts and replies" gives concrete when-to-use scenarios. It stops short of naming alternatives or exclusions — e.g. that non-English input should be routed through ai_translate first, or that multi-label taxonomy work belongs to ai_classify.

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?

Goes well beyond the annotations: it discloses cost ($0.01/call, 25 free, failed calls free), the payment paths (x402 USDC or card key via /credits), the return shape (base64 audio plus content type), and warns that repeats are charged because the tool is not idempotent. That directly reinforces the idempotentHint=false and readOnlyHint=true annotations with actionable context.

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

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

Purpose and limits are front-loaded, then use cases, then pricing. It is dense but nearly every clause carries new information; the pricing/payment sentence is long but justified given there is no other place to learn the cost.

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

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

With no output schema, the description correctly compensates by stating the return is base64 audio with its content type, alongside input limits, language support, and billing behavior. Nothing material for a correct call 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 enum for lang and the 1,000-character limit on text are already documented in the schema; the description mainly restates the character cap and the language list. Baseline 3 is appropriate since the description adds no format or syntax detail the schema lacks.

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 ('turn text into natural speech as an audio file') plus the engine (MeloTTS) and supported languages, which cleanly separates it from siblings like transcribe (the inverse) and ai_translate. An agent can route here 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?

Names concrete use cases (voice replies, audio notes, accessibility, phone/chat bots) and provides a worked example. It gives no explicit exclusions or 'use X instead' routing against siblings such as transcribe or ai_chat, so it stops short of a 5.

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

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

Annotations already indicate read-only, non-destructive, non-idempotent, open-world behavior, but the description adds critical operational details: cost per call, free failed calls, first 25 calls free, and that repeats are not free because each call is charged. It also reinforces that the tool only reads/computes and changes nothing.

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 purpose and usage, then adds pricing and safety context efficiently. It is slightly dense but every sentence is relevant to an agent deciding whether and how to call the 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?

With no output schema, the description supplies the return shape (a few sentences plus bullet key points), usage boundaries, input limit, and cost/auth behavior. An agent has enough context to call it correctly and understand the main operational constraints.

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 thoroughly. The description restates the 12,000-character input limit but does not add meaning beyond the schema for the sentences 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?

The description states a specific verb and resource: summarize up to 12,000 characters of supplied text into a few sentences plus bullet key points. It also distinguishes the URL case by directing agents to /summarize, making the tool's scope clear.

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

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

It names concrete use cases (long emails, documents, transcripts, tool outputs) and explicitly routes web-page-by-URL work to the /summarize alternative. This is clear when-to-use guidance rather than implied context.

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

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

The description adds substantial behavioral detail beyond the annotations: pricing at $0.01 per call, payment via x402 USDC or a card key, first 25 calls free, failed calls free, and that repeated calls are charged because the operation is not idempotent. It also confirms the tool reads or computes only and changes nothing, which aligns with the readOnlyHint and destructiveHint=false annotations.

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 purpose, then moves immediately into language-code guidance and an example before covering pricing and side-effect behavior. Each sentence adds useful information for invocation or cost awareness, with no significant 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 three-parameter translation tool with fully covered schema descriptions and clear annotations, the description is complete enough to call correctly. It covers purpose, parameter format, cost model, free tier, and confirms that the operation changes nothing, leaving no critical gaps for an 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?

Schema description coverage is 100%, so the parameters are already well documented in the schema. The description adds some helpful examples of target ISO codes and a full example call, but most of its parameter guidance repeats what the schema already provides, making the baseline 3 appropriate.

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

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

The description states a specific verb and resource: translate text between about 100 languages using Meta's M2M100 model. It also gives concrete usage context (localising messages and documents) and an example, so an agent can distinguish it from sibling AI tools like ai_rewrite or ai_summarize_text.

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 to use the tool for localising messages and documents, and explains that the target language should be an ISO code while the source language is optional. It does not explicitly contrast when to choose this over related siblings, but the usage context is clear enough for correct 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?

Annotations cover safety (readOnly, non-destructive) but the description adds the pricing model ($0.01/call, first 25 free, failures free), the error contract (404 for missing contract, 422 for non-ERC-20, both uncharged), and explains why idempotentHint=false matters: 'each call is charged, so repeats are not free.' That is real value beyond the annotations.

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 what/why, then input resolution, then pricing. Every sentence carries information, though the pricing sentence is long and 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 naming the return fields (raw allowance, token-denominated allowance, unlimited flag). Combined with the error and pricing contract, an agent has everything needed to call this correctly 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%, so baseline is 3. The description still adds resolution semantics the schema lacks: token accepts a ticker or a 0x contract, with 404/422 behavior on bad input. It doesn't extend owner/spender meaning, but those are already well 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?

States a specific verb+resource+chain - ERC-20 allowance on Arbitrum One - and spells out the three returned facts (raw allowance, token units, unlimited flag). Explicitly distinguishes itself from arb_token_balance, which the sibling list confirms exists.

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 both positive triggers ('check an approval before a swap', 'audit risky open approvals') and an explicit alternative with its condition ('for the owner's balance use arb_token_balance'). An agent can route without opening either schema.

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?

Goes well beyond the annotations: discloses that malformed addresses return 400 and are uncharged, the $0.01/call x402 or credits pricing, the first-25-free allowance, and that repeats are not free (which meaningfully explains the idempotentHint=false annotation). Also reaffirms read-only semantics with concrete consequence ('reads or computes only and changes nothing').

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

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

The purpose and return shape are front-loaded in the first clause, followed by routing guidance, then error/pricing detail. Dense but every sentence carries information an agent would otherwise lack, with no filler.

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

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

With no output schema, the description still specifies return values (wei and ETH), the state snapshot (latest block), and error semantics. Combined with the single fully documented parameter, 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 coverage is already 100%, so the baseline is a 3, but the description adds a concrete example address, clarifies 'any 0x wallet address' (including contracts per the schema), and documents validation behavior for malformed input. That is real added value over 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 the specific resource (native ETH balance), the underlying method (eth_getBalance), the scope (Arbitrum One, latest block) and the units (wei and ETH). It explicitly differentiates itself from arb_token_balance and wallet_portfolio, so an agent can route correctly among the many sibling balance 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?

Gives the concrete decision rule: use this to check gas/transfer funding, use arb_token_balance for ERC-20s, and wallet_portfolio for all holdings at once. This is explicit when-to-use plus named alternatives, the top of the scale.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, idempotentHint=false, so the safety profile is covered. The description adds genuinely new context: a non-existent block returns 404 uncharged, failed calls are free, and repeat calls are billed — matching idempotentHint=false. It slightly re-states 'reads or computes only and changes nothing', which annotations already convey.

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 purpose and return fields, then routing guidance, then error/billing notes. It is dense but slightly overloaded by the pricing sentence ('$0.01/call via x402 USDC or a card key (/credits), first 25 free'), which is useful but verbose for a description.

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

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

For a one-parameter, read-only block lookup with no output schema, the description covers purpose, return fields, error behavior, cost model, and sibling routing — everything 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 coverage is 100%, so the schema documents the single param, but the description still adds value by specifying 'decimal number' format and an example ('number=latest') plus the implicit default behavior.

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 ('Latest block number and block details on Arbitrum One, or any block by decimal number') and enumerates the returned fields. It is clearly distinguishable from the chain-specific siblings (eth_block, base_block, op_block, polygon_block) and from fee 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?

Gives explicit when-to-use ('timestamps and confirmation counts') and an explicit alternative for the adjacent need ('for current fees use arb_gas'). It also supplies a usage example ('number=latest'), leaving little 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?

Annotations already declare readOnly/openWorld/non-destructive/non-idempotent, so the bar is lower, but the description still adds real context: 8 KB calldata cap, reverts return 422 with the reason and are uncharged, execution pinned to the latest block, and the pricing model ($0.01/call, first 25 free). The 'repeats are not free' note is consistent with idempotentHint=false rather than contradicting it.

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

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

Front-loaded with what the tool is and when to use it, and every sentence contributes (limits, pricing, revert behavior). It is a single dense paragraph and the pricing/credits detail is slightly over-weighted relative to its selection value, keeping it just under 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, and the description discharges that burden by explaining the return is raw undecoded return data that must be decoded with the function's ABI. Together with block semantics, revert behavior, and cost, an agent has everything needed to invoke and interpret the result correctly.

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

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

Schema coverage is 100%, so baseline would be 3, but the description adds meaning beyond the schema: the calldata format is spelled out (4-byte selector plus arguments) and demonstrated with a real selector, and the 8 KB size limit is only stated here. The optional 'from' parameter is left to the schema, which is acceptable given full 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 ('Read-only contract call on Arbitrum One (eth_call)') plus the exact scope: ABI-encoded calldata to a contract at the latest block, raw return data, no transaction or gas. It also distinguishes itself from the family of dedicated readers like arb_token_balance/arb_token_info by saying it covers 'any view function that has no dedicated tool'.

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

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

Explicitly routes the agent: use this for view functions lacking a dedicated tool, and the concrete example (USDC totalSupply, selector 0x18160ddd) shows the intended call shape. Cost and retry conditions (charged per call, repeats not free, failed calls free) are stated, which is the practical guidance an agent needs before calling.

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?

Annotations already cover read-only, non-destructive, non-idempotent, open-world, but the description adds genuinely new behavior: reverting transactions return 422 with the reason and are uncharged, and each successful call is billed so repeats are not free. The pricing/payment path (x402 USDC, card key, first 25 free) further clarifies cost consequences. Only the precise response shape for success is left implicit, which is minor for a no-output-schema tool.

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

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

Front-loaded with the verb and resource, then inputs, then alternatives, then behavior and pricing — a sensible ordering with no filler sentences. It is slightly long, and the payment/billing block is dense, but every clause carries actionable information.

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

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

For a four-parameter, read-only estimator with no output schema, the description covers what is returned (gas units, gwei, ETH), the failure mode (422 with revert reason, uncharged), the cost model, and which sibling to use instead. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds real nuance: value is expressed in ETH and the sender is required only when the call depends on it. The inclusion of a concrete example address (to=0x...dEaD) also anchors the expected address format beyond the schema's generic '0x recipient or contract address'.

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 — estimate gas for a transaction on Arbitrum One — and names the underlying method (eth_estimateGas) plus exactly what is returned (gas units, gwei, ETH cost). It explicitly distinguishes itself from the sibling arb_gas, which only reports gas price, so an agent can route correctly 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 concrete when-to-use triggers ('before sending a transaction or to price a batch') and an explicit when-not/alternative ('for the gas price alone use arb_gas'). It also states the preconditions for inputs ('sender when the call depends on it'), 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?

Well beyond the annotations, it discloses the billing model ($0.01/call via x402 USDC or card key, first 25 free, failed calls free) and explains why repeats are not free, which is precisely the context behind idempotentHint=false. It also confirms 'reads or computes only and changes nothing', reinforcing readOnlyHint with plain language.

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

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

Front-loaded with what the tool returns, then use case, then pricing — a sensible ordering with no filler sentences. The pricing clause is dense but earns its place for a paid endpoint; the sentence count is slightly high for a zero-required-parameter read.

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 carries the return-value burden itself, and it does: it lists the exact fields and a concrete derived figure (21,000-gas ETH transfer cost). Combined with the usage and pricing context, nothing an agent needs to call or interpret this tool 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 `only` filter is already fully documented in the schema and the baseline of 3 applies. The description adds nothing about `only` and in fact says 'Takes no input', which mildly understates the optional projection parameter and could discourage an agent from using it.

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

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

The description states a specific verb and resource ('Current gas price on Arbitrum One'), names the underlying RPC method (eth_gasPrice), and enumerates exactly what comes back (gas price, base fee, suggested priority fee, plain-transfer cost). It also explicitly separates itself from arb_receipt, so an agent can distinguish it from at least one sibling without opening a schema.

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

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

It gives concrete when-to-use guidance ('before sending a transaction or to decide whether to wait') and names an alternative for a different need ('for the fee a past transaction actually paid use arb_receipt'). The remaining gap is that arb_estimate_gas — the sibling most easily confused with a gas-pricing tool — is never addressed or excluded.

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?

Annotations already cover read-only and destructive behavior, and the description adds genuinely new operational context: $0.01/call via x402 USDC or card key, first 25 free, failed calls free, and that repeats are not free — which explains the non-obvious idempotentHint=false. It also reinforces that the call reads/computes only and changes nothing.

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 resource and return shape, then usage, then example, then cost. The pricing/billing sentence is slightly dense but carries real decision value; nothing is gratuitous filler.

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

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

There is no output schema, so the description must describe the return shape, and it does so field by field (base fee, fullness, percentiles, aggregated low/avg/high). Combined with the cost model and sibling routing, 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 the parameter's range and default (5-100, default 20) are already documented in the schema, so the description's restatement adds no new constraint. The description does clarify what the window is used for and how it maps to returned statistics, but the parameter meaning itself is fully covered by structured data.

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 — gas price history on Arbitrum One via eth_feeHistory — and enumerates the returned fields (base fee, block fullness, 10/50/90th percentile priority fees, low/avg/high over the window). It explicitly contrasts with the sibling arb_gas for the current price alone, so an agent can pick 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?

Names concrete decision contexts (judge whether fees are rising, pick a priority fee, time a transaction) and gives the explicit alternative for the other case: 'for the current price alone use arb_gas'. That is an unambiguous when-to-use / when-not-to-use 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?

Annotations already declare read-only, non-destructive, non-idempotent, open-world, but the description adds context the annotations cannot: malformed addresses are rejected with 400 and uncharged, pricing is $0.01/call with the first 25 free, failed calls are free, and the explicit note that 'each call is charged, so repeats are not free' explains the idempotentHint=false in operational terms. It also confirms 'reads or computes only and changes nothing,' reinforcing the safety profile with the billing model an agent needs before retrying.

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

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

The core capability is front-loaded in the first sentence, with usage guidance, error behavior, example, and pricing following in a logical order; nothing is padding. It is slightly overpacked—pricing, example, and billing rules share a single dense sentence—but every clause carries information an agent needs for a paid, non-idempotent 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 one required param and no output schema, the description carries the return-value burden and does so by naming the three outputs (bytecode size, proxy flag, implementation). The only gap is the exact response shape or how a plain wallet is represented, which an agent can infer but not confirm.

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% (the single 'address' param is described), so baseline is 3. The description adds value beyond the schema by pinning the address to Arbitrum One semantics, supplying a concrete example value, and stating the failure mode for malformed input (400, uncharged), which tells the agent how to pre-validate.

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 ('check whether a 0x address on Arbitrum One is a smart contract or a plain wallet') and enumerates what the answer contains: bytecode size, EIP-1167 minimal-proxy status, and implementation address. That detail distinguishes it from arb_proxy and the parallel *_is_contract siblings without the agent opening any schema.

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

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

Gives an explicit when-to-use ('before sending funds or approving a spender') and names an alternative with the condition that selects it ('for a fuller risk verdict use check_counterparty'). This is the when/when-not/alternative pattern at full strength.

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?

Annotations already cover safety and world-openness, and the description adds genuinely new context: per-call pricing ($0.01 via x402/card key), first 25 free, failed calls free, and that repeats are charged — which explains the non-intuitive idempotentHint=false. It also summarizes the return payload (up to 100 logs with block, tx hash, topics) despite there being no output schema. It does restate "reads only, changes nothing," which duplicates readOnlyHint.

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 verb, chain, and RPC method, then contract, then the sibling exclusion, then pricing. Dense and mostly waste-free; the inline example address and the repeated read-only assurance are the only expendable bits.

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

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

For a 3-param read tool with no output schema and full annotation coverage, the description supplies purpose, routing, return shape, cost model, and defaults. Only edge behavior (invalid address, zero-log results, whether the 100-log cap truncates silently) is 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 the description largely restates it: the 1–1,000 / default 50 range for blocks is already in the schema, as is the topic0 filter. It does add value in two spots — that topic0 is specifically a 32-byte hash and that returns cap at 100 logs, which effectively bounds how much of the scanned block range is observable — but the example address is decorative. Baseline 3 is appropriate.

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

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

States a specific verb+resource+chain: "Recent contract event logs on Arbitrum One (eth_getLogs)" with the exact scope (last N blocks) and filters. It also names the sibling it is not, arb_receipt, so an agent can discriminate 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 ("watch transfers or contract events") and an explicit alternative with its selecting condition ("for one transaction's outcome use arb_receipt"). Nothing is left to inference about routing.

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

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

Annotations already cover read-only/no-destroy/open-world status, but the description adds real value beyond them: error contracts (404 missing contract, 422 non-ERC-721, both uncharged), pricing ($0.01/call via x402 or card key, first 25 free, failed calls free), and that repeats are billed — consistent with idempotentHint=false. It never states the response shape beyond name/symbol, and doesn't mention rate limits, which keeps it shy of a 5.

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

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

Front-loaded with the core operation and the sibling disambiguation, then error and billing facts. Dense but mostly earned; the pricing/charging sentences are the longest portion relative to the operation's simplicity, so not perfectly tight.

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 discloses what comes back (balance plus collection name and symbol), the two failure modes and their billing treatment, and the prerequisite that both arguments are 0x addresses. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3; the description still adds meaning by saying both inputs are 0x addresses and that the contract must be a valid ERC-721 collection (else 422), which ties the parameter to a failure mode. It adds no format examples or distinctions 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 precise verb and resource: counts how many NFTs of one ERC-721 collection a wallet holds on Arbitrum One (balanceOf), plus returns collection name and symbol. Explicitly distinguishes itself from arb_nft_owner ('for who holds one token id use arb_nft_owner'), so an agent can pick between the two 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?

Names two concrete use cases (gate check before a token-gated action; verifying a wallet still holds a collection) and routes the alternative case (who holds a specific token id) to arb_nft_owner. Both when-to-use and when-not-to-use are 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?

Goes well beyond the annotations: it discloses output truncation for strings over 1,000 chars (e.g. on-chain SVG), 422-uncharged for nonexistent tokens, metadataError for unreachable metadata, the ipfs.io gateway path, and the $0.01/call price with a 25-call free tier. The note that repeats are charged is consistent with idempotentHint=false and explains the cost model annotations cannot express.

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 capability and its distinguishing scope are front-loaded, then behavior, error cases, example, and pricing in a sensible order. It is dense and the pricing/cost sentence is long, 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?

There is no output schema, so the description carries the return contract — it names the returned fields, the truncation rule, and the metadataError signal. Combined with the error and pricing notes, an agent has everything needed to call and interpret this tool.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds a concrete worked example (contract=0xC364...FE88, tokenId=1) that fixes the expected address and token-id format for call construction. It does not add further constraints beyond that, so it lands just above baseline.

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

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

States a specific verb and resource — reads the tokenURI and the resolved JSON metadata (name, description, image, attributes) for one ERC-721 token id on Arbitrum One. It also names the sibling it is not (arb_nft_owner) and its chain-specific scope, so an agent can distinguish it from eth_/base_/op_/polygon_nft_metadata 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?

"Use to show or check what an NFT is; for its owner use arb_nft_owner" gives an explicit when-to-use plus the routing alternative. It also names the supported metadata sources (data:, https, ipfs://) so an agent knows which tokens it can resolve.

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?

Adds real behavioral context beyond annotations: 404 for a missing contract, 422 for a nonexistent token, both uncharged, plus per-call pricing and the note that repeats are charged (consistent with idempotentHint=false). The description could still describe the response shape, but the safety/error/cost profile is well covered.

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

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

Purpose and the two sibling alternatives are front-loaded, followed by errors, example, and pricing. Every sentence carries information, though the billing/credits sentence is somewhat dense and could be trimmed without loss.

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 the description does state that the result includes the current owner, collection name, and symbol. Combined with the error semantics and pricing, this is nearly complete, with only the exact response field structure left implicit.

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% (contract address, token id), so the schema already documents both parameters. The example with a concrete contract and tokenId=1 is helpful but only marginally beyond the schema, 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?

Names a specific verb and resource ('Owner of an NFT on Arbitrum One... the wallet that holds one ERC-721 token id right now (ownerOf)') and explicitly distinguishes itself from arb_nft_balance and arb_nft_metadata, which cover token counts and metadata respectively.

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 when-to-use triggers (verify holder before a trade, mint gate, airdrop) and names both alternatives with their scope for count and metadata, so the agent can choose without opening other schemas.

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?

Goes well beyond the annotations: it discloses that both confirmed and pending nonces are returned, that malformed addresses fail with a 400 and are uncharged, and that successful calls are billed per call (which explains the idempotentHint=false). Pricing-tier details are useful but border on promotional rather than operational.

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

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

Front-loads purpose, then usage, then error/pricing, so the important part is read first. It is dense but every clause carries information; the pricing sentence is the weakest use of space.

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

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

With no output schema, the description compensates by saying the result covers both confirmed and pending counts, which is what an agent needs to interpret the return. It doesn't say how the two values are distinguished in the response body.

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 baseline is 3; the description adds an expected format cue and a worked example address, which is more than the schema's bare '0x address' string. It does not state whether ENS names are accepted.

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 ('Read the transaction count (nonce) of a 0x address') scoped to Arbitrum One, and separates itself from the sibling arb_balance by name. An agent can pick it over eth_nonce/op_nonce purely from the chain qualifier.

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

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

Gives two concrete use cases ('build the next transaction', 'tell whether an address has ever sent anything') and an explicit alternative route ('for its balance use arb_balance'). Nothing is left to inference about when to reach for 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so safety framing is partially redundant rather than additive. What the description genuinely adds is cost behavior (per-call charge, repeats not free, failures uncharged) and the failure taxonomy (400 malformed vs 404 no code) — useful, but the pricing paragraphs are commercial boilerplate that wouldn't change a tool-selection decision. It stops short of saying what the response contains beyond 'names the kind found'.

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 capability and the alternative routing are front-loaded in the first two sentences, which is the right ordering. Efficiency is slightly hurt by three clauses of payment/credits detail at the end that most callers won't act on, but nothing is genuinely 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?

With no output schema, the description still indicates the return content ('names the kind found') and lists the proxy standards checked, which is enough to set expectations. Failure modes and cost are covered; only the exact shape of the response is left to discovery, a minor gap for a single-parameter read 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?

Only one parameter and schema description coverage is 100%, so the schema already carries the meaning and the baseline is 3. The description does add a concrete address example and implicitly ties the parameter to the Arbitrum chain, which is modest added value, but no format constraints beyond the schema's '0x contract address'.

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 ('Find the implementation behind a proxy contract on Arbitrum One') and enumerates exactly which storage slots / bytecode patterns it inspects, so an agent knows the precise capability. The chain is named, which separates it from the eth_proxy/base_proxy/op_proxy/polygon_proxy siblings despite the parallel naming scheme.

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 ('before trusting or decoding a contract whose code can be swapped by its admin') and an explicit alternative with a selection rule ('for a fuller risk verdict use contract_risk'). The 400/404 semantics also tell the agent what failure looks like without trial and error.

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?

Beyond the readOnly/openWorld/non-idempotent annotations, the description adds important operational context: pending hashes return 404 uncharged, failed calls are free, pricing is $0.01/call via x402 or card key, and repeats are charged again. These are material behavioral and billing details an agent should know before calling.

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

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

The purpose and return content are front-loaded, and the description is dense but readable. Some clauses repeat annotation-level facts, such as read-only behavior and non-free repeats, but the extra pricing and error details generally 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 one-parameter tool with no output schema, the description supplies enough detail: it enumerates the receipt fields, explains the 404 case, and discloses billing behavior. An agent has what it needs to call and interpret this tool correctly.

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

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

Schema coverage is 100%, so the single hash parameter is already well documented. The description still adds a concrete example and clarifies that a pending or unknown hash produces a 404 rather than a normal receipt, which is useful handling semantics beyond the schema.

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

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

The description states a specific resource and chain (transaction receipt on Arbitrum One / eth_getTransactionReceipt) and enumerates the returned fields: status, gas used, effective gas price, fee, logs, and contract creation. It explicitly distinguishes itself from arb_tx by saying sender, value, and calldata belong there.

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 — confirming that a payment or call went through — and names arb_tx as the alternative for sender/value/calldata. It also explains the pending/unknown-hash case as a 404 response.

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?

Beyond the annotations (readOnly/openWorld/non-destructive/non-idempotent), the description adds material operational facts: malformed address or slot returns 400 and is uncharged, failed calls are free, and each successful call is charged so repeats are not free. It also discloses the dual return representation. This is real context rather than restatement.

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

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

Front-loaded with the core action and return shape, then usage, errors, pricing in a sensible order. Slightly redundant at the tail: 'each call is charged, so repeats are not free' restates the earlier 'Price $0.01/call' clause and could be trimmed.

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

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

No output schema exists, and the description compensates by describing the returned 32-byte word in both numeric and address form. Combined with error behavior and cost model, an agent has everything needed to call it correctly 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 the baseline is 3; the description earns an increment by explaining that a slot may be a decimal index or a 0x 32-byte key and that keyed form is used for mapping and proxy slots — meaning the schema does not convey. It also supplies a concrete address example.

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: 'Read one raw storage slot of a contract on Arbitrum One (eth_getStorageAt)'. It also pins the return shape (32-byte word as number, and as address when applicable), which lets an agent distinguish it from arb_call, arb_balance, and the other arb_* readers 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?

Explicitly names the use case ('contract state that has no getter, owners or implementation pointers') and routes the proxy case to the sibling: 'for proxies use arb_proxy'. Both when-to-use and when-to-use-something-else are 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?

Goes well past the annotations: discloses pricing ($0.01/call via x402 or credits, first 25 free, failed calls free), error semantics (404 for no contract, 422 for a non-ERC-20 contract, both uncharged), and confirms nothing is mutated. 'Each call is charged, so repeats are not free' also explains the otherwise puzzling idempotentHint=false.

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

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

Front-loads the result shape and the sibling distinction, which is the right ordering, and every clause carries information. It is a dense single paragraph with mild redundancy — pricing is stated and then restated as 'each call is charged, so repeats are not free'.

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 correctly compensates by describing the return fields, and it covers errors, cost, and the sibling alternative. The only substantive gap is the mischaracterization of the token parameter's accepted forms, which is the one thing an agent could get wrong when 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 baseline is 3. The description does add the 40-hex-character address format, but its claim that 'Both inputs are 0x addresses' conflicts with the schema's token parameter, which accepts tickers like USDC or WETH — an agent reading only the prose could wrongly reject a ticker input.

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

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

States a specific verb and resource (fetch an ERC-20 balanceOf result for a wallet on Arbitrum One) and enumerates exactly what comes back: raw amount, decimals, symbol, human-readable amount. It explicitly separates itself from arb_balance for the native coin, so an agent can pick it over the dozens of sibling *balance tools without opening any schema.

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

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

Gives a concrete use case ('check stablecoin or token holdings before a transfer or trade') and names the alternative with the condition that selects it ('for the native coin use arb_balance'). None of the other 90+ siblings are confused with 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?

Goes well beyond the annotations by disclosing the commercial model ($0.01/call via x402 USDC or card key, first 25 free, failed calls free), the failure mode (non-ERC-20 address returns 422 and is uncharged), and the fact that repeats are charged — which explains the idempotentHint=false flag rather than contradicting it. It also restates the read-only nature in agent-facing terms ('reads or computes only and changes nothing').

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

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

Front-loads the purpose and the alternative before the operational detail, and every sentence carries information an agent needs. The payment clauses are dense and could be tightened, but none are pure waste given the unusual per-call billing model.

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

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

With no output schema, the description compensates by enumerating the returned fields (name, symbol, decimals, total supply), and it covers the input forms, the error path, the cost, and the sibling alternative. An agent has everything needed to select and invoke it correctly on the first try.

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 concrete worked example address (0xaf88…5831) and the semantic consequence of passing a non-ERC-20 address (422, uncharged), which the schema does not convey. It stops short of covering ticker-vs-address resolution behavior (e.g. unknown ticker handling), so it is not 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 verb and resource — look up name, symbol, decimals and total supply of an ERC-20 contract — and pins the chain (Arbitrum One) which is exactly what distinguishes it from the ~7 sibling *_token_info tools. It also explicitly names the sibling it is not (arb_token_balance) so the 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?

Gives two concrete positive use cases (identify an unknown token address, format raw amounts) and one explicit exclusion with the correct alternative: 'for a holder's balance use arb_token_balance'. The chain scoping is unambiguous, so there is nothing left to infer about when to call 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?

Adds substantial context beyond the annotations: result cap of 50, newest-first ordering, default token, and the crucial clarification that repeats are not free because billing — not state — drives idempotentHint=false. The only gap is that it doesn't say what an empty result or a token with no transfers looks like, but the read-only/non-destructive profile is fully consistent.

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

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

Purpose is front-loaded and every clause carries information (scope, ordering, cap, alternative, error path, pricing). It is dense to the point of being a single run-on block, and the pricing/credits tail is longer than most agents need.

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 returned fields (direction, counterparty, amount, transaction) and their ordering and cap. Inputs, caveats and cost model are all covered, so nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns extra by restating the blocks range (1-2,000, default 1,000), the USDC token default, and giving a concrete checksummed address example. It doesn't clarify ticker-vs-contract resolution edge cases, which stays 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 ('List a wallet's recent transfers of one ERC-20 token'), plus chain, direction (in and out), window and result cap. It also names the sibling it is not (arb_token_balance for current balance), 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?

Explicit when-to-use cases ('confirm a payment arrived or see what was sent') and an explicit alternative ('for the current balance use arb_token_balance'). It even covers the failure path: malformed addresses are rejected with 400 and uncharged.

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?

Annotations already declare readOnlyHint, openWorldHint, destructiveHint=false and idempotentHint=false; the description still adds real signal beyond them: unknown hash returns 404 uncharged, failed calls are free, each call is metered so repeats cost money (which is what idempotentHint=false actually implies for billing). It also restates the no-side-effects guarantee, reinforcing rather than contradicting the annotations.

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 purpose and routing before pricing and example detail, and every clause carries information. It is a dense single block though — pricing, example, and safety caveats are stacked together rather than separated, which costs a little 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?

One required parameter, no output schema, annotations present — and the description still covers return fields, the not-found case, cost model, and side-effect profile. Nothing an agent needs in order to decide and call correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns extra by supplying a concrete worked example hash and the error semantics of an unknown value (404, uncharged). It doesn't add anything about the hash format beyond the schema, but the example and failure behavior are genuine value-adds.

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?

Specific verb+resource ("Look up an Arbitrum One transaction by hash") followed by an enumeration of what comes back (sender, recipient, value in ETH, nonce, gas limit, selector, block). It explicitly carves itself away from arb_receipt (success/failure, fees) and arb_logs (events), so an agent can pick the right sibling 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 use case ("see what was sent or whether it exists") and names both alternatives with the condition that selects each. This is the when/when-not/alternatives pattern at full strength.

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?

Annotations already declare readOnly/openWorld/non-destructive, but the description adds substantial context beyond them: the pricing model ($0.01/call via x402 USDC or card key, first 25 free, failed calls free) and the fact that each call is charged so repeats are not free. The 'reads or computes only and changes nothing' line also reconciles with the counterintuitive idempotentHint=false by explaining the cost basis.

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?

Dense and front-loaded — the encoding options, output format, usage, and pricing all appear in a logical order with no filler. It is on the longer side, but nearly every clause carries actionable information for the agent.

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?

Though there is no output schema, the description explicitly states the return value (SVG plus a data URL ready for an <img> tag), covers encoding defaults, and discloses the cost model. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% so the schema already documents all five parameters, but the description adds genuine encoding semantics: the mod-103 check symbol for Code 128's numeric subset, and that EAN-13's check digit is computed or verified. These details go beyond the schema's terse field descriptions.

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

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

States a specific verb (generate) and resource (barcode as SVG), and names both supported symbologies (Code 128, EAN-13) plus their input constraints. Explicitly routes QR users to the sibling qr tool, so the agent can distinguish it 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 concrete use cases (shipping labels, product codes, tickets, inventory) and an explicit alternative ('for QR codes use qr'). Provides a worked example (text=AGENT-12345) and notes EAN-13's 12-or-13-digit requirement, so the agent knows exactly when and how to select 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?

Annotations already cover readOnly, destructive, and idempotent hints, so the bar is lower. The description adds genuinely non-redundant context: missing padding is tolerated, pricing model (first 25 free, $0.01/call, failed calls free), and reinforces non-idempotent cost behavior ('repeats are not free').

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 operation, then tolerance, then use cases, then pricing. The pricing sentence is longer than strictly needed but is behaviorally relevant to the calling agent; nothing is wasted on restating the name.

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 utility with no output schema, the description covers input forms (standard/URL-safe, padding tolerant), usage context, and cost behavior. Only the failure mode (what happens on invalid base64) is left implicit.

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 described as 'The base64 text'. The description goes beyond the schema by noting padding tolerance and giving a concrete invocation example (text=aGVsbG8gd29ybGQ=), which clarifies accepted input forms.

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: 'Decode standard or URL-safe base64 to UTF-8 text', including both variants handled. The sibling base64_encode is implicitly the inverse, and the title/description make the direction of the operation unambiguous.

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 to read encoded headers, tokens and data URLs' gives concrete use cases, which distinguishes it from base64_encode and hints at where the input comes from. No explicit when-not or named alternative, but the direction (decode vs encode) is clear from the definition.

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?

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), so the description's 'reads or computes only' is a mild restatement. The real added value is operational: per-call pricing, a free tier of 25 calls, and that failed calls are not charged — cost behavior an agent cannot get from annotations. It does not describe output formatting details beyond naming the two variants.

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

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

Purpose and second output are front-loaded, and every sentence carries information. The closing sentence is dense, packing pricing, free tier, failure policy and the repetition warning together with an inline '(/credits)' fragment, which slightly hurts readability but does not waste content.

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 has one simple parameter and no output schema, and the description compensates by saying exactly what comes back (standard base64 plus URL-safe variant). With annotations covering side-effect behavior and the description covering cost and return shape, 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% for the single 'text' parameter, so the baseline would be 3. The description adds a concrete example ('text=hello world') that clarifies the input is raw, unencoded text rather than an already-encoded string, which is a meaningful disambiguation.

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 ('Encode UTF-8 text as standard base64') and goes further by naming the second output ('URL-safe variant'). That distinguishes it cleanly from the sibling base64_decode and from other encoding tools like url_encode or hash.

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 concrete use cases ('data URLs, headers and basic auth strings') and a worked example, which is enough for an agent to place the tool. It does not explicitly say when to prefer a sibling (e.g. url_encode for percent-encoding) or when not to use it, 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?

Annotations already cover read-only and non-destructive, but the description adds information annotations cannot convey: pricing ($0.002/call via x402 USDC or card key, first 25 free, failed calls free) and the explicit warning that repeat calls are charged, which materially explains the idempotentHint=false billing behavior. It also reaffirms 'reads or computes only and changes nothing' and enumerates the return 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?

Front-loads what is checked and why, then behavior and pricing; three sentences with no filler. The pricing/free-tier clause is dense but justified for a paid tool, though it slightly crowds the middle of an otherwise tight definition.

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

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

With no output schema, the description compensates by listing the exact return fields, and it covers cost, safety profile, and intended workflow for a simple 3-parameter read tool. 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 description coverage is 100% and all three parameters (owner, token, spender) are documented in the schema with role and address format. The description restates the owner/spender relationship but adds no format, constraint, 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 precise verb and resource ('check how much of a wallet's ERC-20 token a spender contract is approved to move on Base') and even enumerates what comes back (raw/formatted allowance, symbol, decimals, unlimited flag). The 'approved to move' phrasing cleanly separates it from the sibling balance tools (base_token_balance) and the chain prefix separates it from eth_allowance/arb_allowance etc.

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

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

Gives two concrete usage contexts: pre-swap/pre-deposit approve checks and auditing risky unlimited approvals. It does not name an alternative tool or state when-not to use it, so it stops short of the explicit routing a 5 requires.

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?

The description goes far beyond annotations by detailing pricing ($0.01/call, first 25 free), operational failure modes (400 uncharged for malformed address), and the nature of the computation (reads/computes only, no changes). This is essential operational context.

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

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

While it is slightly lengthy due to the number of required operational details (pricing, failure modes, routing), it is well-structured. The most critical information (purpose, routing) is prioritized, leading to high utility.

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 definition is exceptionally complete, covering the functional intent, architectural constraints (read-only), operational constraints (cost, rate limits), and failure modes. No critical information needed for correct selection or invocation is missing.

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

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

With 100% schema coverage, the baseline is already high. The description adds value by providing a concrete example of a valid address and clarifying that the address must be a 0x wallet or contract.

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 precisely that the tool retrieves the native ETH balance of a 0x wallet address on the Base network. Furthermore, it clearly differentiates its function from related tools by directing users to `base_token_balance` and `wallet_portfolio` for specific needs.

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 definition provides excellent usage guidance by explicitly stating its intended use (checking gas payment capability or transfers) and providing clear alternatives for ERC-20 tokens and total holdings. This eliminates ambiguity 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, and the description's 'reads or computes only and changes nothing' largely restates them. It does add genuinely new context: 404 on nonexistent blocks is uncharged, and every call is billed so repeats are not free. Pricing detail is useful but is commercial rather than operational 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 core purpose, returned fields, alternative tool, and error behavior are all front-loaded. The trailing pricing/free-tier sentence is dense and somewhat boilerplate-heavy, but it is not padding for a paid x402 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?

There is no output schema, so the description carries the burden of describing returns, and it does so (hash, timestamp, transaction count, gas used and limit, base fee in gwei, producer). Combined with error semantics, cost, and the sibling pointer, nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100% and the single parameter already documents 'Block number, or latest (default)'. The description still adds value by specifying the number must be decimal and giving a concrete example ('number=latest'), which clarifies format beyond the schema text.

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

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

States a specific verb and resource (fetch latest block number or any block by decimal number on Base) and enumerates the returned fields. It also explicitly distinguishes itself from base_gas, so an agent can separate it from the many sibling *block/base_* 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?

Gives concrete when-to-use guidance ('Use for timestamps and confirmation counts') and names the alternative for a different need ('for current fees use base_gas'). It also notes the default/example input ('number=latest') and the not-yet-mined 404 case, leaving little 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?

Goes well beyond the annotations: latest block semantics, an 8 KB calldata cap, revert behavior (422 with reason, uncharged), pricing model ($0.01/call via x402 or card key, first 25 free), and the crucial warning that each call is charged so repeats are not free — which explains the idempotentHint=false. The 'changes nothing' clause reinforces readOnlyHint/destructiveHint without merely repeating them.

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

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

Front-loads what the tool is and when to use it, then constraints, then economics — good ordering with no filler. The pricing/free-tier sentence is dense and slightly overloaded into one line, but every clause carries information an agent needs (cost per call, free retries on failure).

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 stating the return is raw return data requiring ABI decoding, plus the revert path. Combined with the size limit, pricing, and block semantics, an agent has everything needed to invoke and interpret results without guessing.

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 real value: a worked example pairing a live Base USDC address with selector 0x18160ddd, the note that calldata is '4-byte selector plus arguments' in context, and the 8 KB size constraint. The optional `from` parameter is not mentioned in the description, leaving that entirely to 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+resource (read-only eth_call on Base) plus the exact scope: ABI-encoded calldata in, raw return data out, at latest block. It also distinguishes itself from the many sibling wrappers (eth_call, arb_call, op_call, polygon_call) by naming its chain, and from dedicated tools via 'any view function that has no dedicated tool'.

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

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

Clearly says when to use it: view functions that lack a dedicated tool, with a concrete USDC totalSupply example. It implies the alternatives (base_token_balance, base_storage, etc.) exist by saying 'no dedicated tool' but never names a single sibling, so the routing decision still requires the agent to scan the tool 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description still adds real value: revert behavior (422 with reason, uncharged), the billing model ($0.01/call, 25 free, failed calls free) and the non-idempotent cost note that explains idempotentHint=false. It does not mention latency or which errors besides revert can occur, so a 4 rather than a 5.

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

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

Purpose, inputs, alternatives, error behavior and pricing are front-loaded in that order with no filler. The pricing/credits sentence is the longest and is arguably the least essential, but it justifies the non-idempotent annotation so it still earns its place.

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

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

With no output schema, the description states the returned quantities (gas units, gwei, ETH) and cost basis, plus the failure mode and the fact that nothing is mutated or persisted. An agent has everything needed to call it correctly 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. The description goes modestly beyond it by framing value as ETH and telling the agent to supply sender only 'when the call depends on it', which is a usage hint the schema's '(default: an empty address)' does not convey.

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 ('Estimate the gas a transaction would use on Base') plus the underlying RPC method (eth_estimateGas) and the return units (gas, gwei, ETH). It explicitly distinguishes itself from base_gas, which only returns the gas price, so an agent can pick between the two 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 before sending a transaction or to price a batch' gives positive trigger contexts, and 'for the gas price alone use base_gas' names the alternative and the condition selecting it. Both when-to-use and when-to-use-something-else 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?

Goes well past the annotations: discloses pricing ($0.002/call via x402 USDC or card key, first 25 free, failed calls free) and that each call is charged so repeats are not free -- which explains the otherwise puzzling idempotentHint=false. It also confirms 'reads or computes only and changes nothing', consistent with readOnlyHint=true. Cost and billing behavior is exactly the kind of operational detail annotations cannot convey.

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

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

Front-loads the resource and chain, then the returned fields, then usage, then cost -- a sensible priority order with no filler sentences. It is on the long side because the return-field enumeration and the billing caveats are both spelled out, but each sentence carries information an agent needs.

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

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

There is no output schema, so the description usefully enumerates units (gwei vs wei) and the concrete computed values returned. Combined with the stated safety profile (read-only, no side effects) and the billing model, an agent has everything needed to call this correctly and predict the cost.

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

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

Only one optional parameter (`only`), and the schema description already covers it at 100% with an example and fallback behavior. The description says nothing about `only` or the result-key projection it enables, so it adds no meaning beyond the schema. Baseline 3 applies when the schema does the full job.

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 -- live gas prices read from the latest Base block (chain 8453) -- and enumerates exactly what is returned (base fee, priority fee in gwei, maxFeePerGas/maxPriorityFeePerGas in wei, block fullness, ETH/ERC-20 transfer fee estimates). This lets an agent separate it from base_estimate_gas (per-transaction estimation) and base_gas_history (historical series) 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?

Explicit timing guidance: 'Use before sending a transaction on Base or to decide whether to wait for lower fees.' That is a clear use context with no exclusions. It stops short of naming the sibling alternatives (base_estimate_gas, base_gas_history, pack_gas_tracker) or stating when not to use it, so it lands at 4 rather than 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?

Annotations already cover the safety profile (readOnlyHint true, destructiveHint false), and the description adds cost behavior that no annotation carries: $0.01/call via x402 USDC or card key, first 25 free, failed calls free, and that repeat reads are not free. The 'reads or computes only and changes nothing' line is consistent with readOnlyHint, though it sits slightly at odds with idempotentHint=false — the charge-per-call explanation resolves that rather than contradicting it.

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 first sentence front-loads the purpose and the return shape, followed by usage guidance, an example, and pricing. It is dense and every clause carries information, though the pricing/credits tail is long enough to slightly dilute the core message.

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 return contents (per-block base fee, fullness, percentile priority fees, window aggregates) and does so fully. Combined with the parameter range, cost model, and usage routing, an agent has everything needed to call it correctly 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?

With 100% schema description coverage, the schema already documents the single 'blocks' parameter with range 5-100 and default 20. The description restates the same range and default plus an example (blocks=20) but adds no interpretation of the parameter beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Gas price history on Base (eth_feeHistory)') and enumerates the returned quantities: base fee in gwei per block, block fullness, 10th/50th/90th percentile priority fees, and low/avg/high base fee. It also names the sibling it is not ('for the current price alone use base_gas'), so differentiation is unambiguous.

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 selection criteria ('judge whether fees are rising, pick a priority fee or time a transaction') and an explicit exclusion routing to base_gas when only the current price is needed. Nothing about when to choose this over its alternatives 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?

Beyond annotations (readOnlyHint, openWorldHint, idempotentHint=false, destructiveHint=false), the description adds pricing details ($0.01/call via x402 USDC or card key, first 25 free, failed calls free), error handling (malformed address returns 400 uncharged), and clarifies that repeats are not free because each call is charged. It also explicitly states 'Reads or computes only and changes nothing,' reinforcing the read-only nature.

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 purpose and then covers usage, error handling, example, and pricing. It is generally efficient, but there is slight redundancy in repeating the charging policy near the end.

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 the simple tool, one parameter, and no output schema, the description covers what is returned (bytecode size, proxy status, implementation), when to use it, error behavior, and pricing. Nothing essential for correct invocation is missing.

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

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

The single parameter 'address' is fully described in the schema, but the description adds a concrete example address and notes that a malformed address is rejected with 400, which provides extra semantic value beyond the schema's '0x address' label.

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 (check) and resource (0x address on Base), and enumerates the exact outputs: bytecode size, EIP-1167 proxy detection, and implementation address. It also distinguishes itself from the sibling check_counterparty for a fuller risk 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?

It gives explicit guidance: 'Use before sending funds or approving a spender; for a fuller risk verdict use check_counterparty.' This names the alternative and the condition that selects it, 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?

Annotations already declare readOnly/destructive/idempotent/openWorld, and the description still adds genuinely non-structured behavior: pay-per-call pricing ($0.01 via x402 USDC or card key, first 25 free, failed calls free), that repeats are billed and therefore not free, and the return size cap (up to 100 logs). That is exactly the kind of cost/limit context the annotations cannot express.

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 method and scope, then guidelines, example, and pricing in a sensible order. Slightly overloaded at the end: 'Reads or computes only and changes nothing' largely restates readOnlyHint/destructiveHint, and the billing terms earn their place but add bulk.

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 covers the return shape (up to 100 logs with block, transaction hash, topics), the scanning window, and cost per call. An agent has everything needed to decide to call it and to 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 the baseline is 3. The description still adds value: it clarifies topic0 is a 0x 32-byte event signature hash (useful for knowing to pair with keccak), restates the blocks default/range inline, and supplies a concrete address example.

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 the exact RPC method (eth_getLogs), the resource (contract event logs), the chain (Base), and the scope (last N blocks). It is immediately distinguishable from base_receipt and from the other chain-prefixed log tools by the explicit 'Base' prefix and event-log framing.

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 positive use case ('watch transfers or contract events') and an explicit exclusion routing to a sibling ('for one transaction's outcome use base_receipt'). No guidance on when to prefer base_token_transfers or the equivalent logs tools on other chains, but the core when/when-not pair is 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?

Goes well beyond the annotations by disclosing error semantics (404 for missing contract, 422 for non-ERC-721, both uncharged), the pricing model ($0.01/call, 25 free, failed calls free), and that repeat calls are charged — which explains why idempotentHint is false. It also confirms read-only/no-mutation, consistent with readOnlyHint=true and destructiveHint=false.

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

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

Purpose and the sibling routing are front-loaded in the first two sentences, and the error/pricing details are genuinely decision-relevant. It is dense but slightly sprawling, with payment mechanics taking up roughly half the 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 still says what comes back (balance plus collection name and symbol). Combined with error codes, cost model, and read-only confirmation, an agent has everything needed to call this correctly and interpret failures.

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 both parameters already documented as '0x wallet address' and '0x ERC-721 collection contract address'. The description only restates that both inputs are 0x addresses, adding no format, validation, or edge-case 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 — NFT balance of one ERC-721 collection for a wallet on Base — and even names the underlying call (balanceOf). It explicitly separates itself from base_nft_owner ('for who holds one token id use base_nft_owner'), so an agent can pick between the two siblings 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 concrete use cases (check a holder before a token-gated action, verify a wallet still holds a collection) and an explicit exclusion routing to base_nft_owner. When-to-use, when-not-to-use, and the alternative 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?

Annotations cover the safety profile, but the description adds substantial behavioral context beyond them: supported URI schemes, IPFS resolution through ipfs.io, truncation of strings over 1,000 characters, 422 handling for nonexistent tokens, metadataError reporting for unreachable metadata, pricing, and that repeat calls are charged. No contradiction with readOnlyHint/destructiveHint.

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 purpose and return shape, then adds only operationally relevant details: URI support, truncation, failure behavior, sibling routing, pricing, and mutation safety. Every sentence contributes to correct invocation or interpretation.

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 explains the return values (token URI plus JSON fields), truncation behavior, metadataError, and the 422 case. Combined with full parameter coverage and rich annotations, an agent has enough to call and interpret this tool correctly.

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

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

Schema description coverage is 100%, so both parameters are already documented as contract address and token id. The description adds a concrete example and confirms tokenURI behavior, but it does not add syntax or validation rules beyond the schema, so 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: read the token URI and pointed-to JSON metadata for one ERC-721 token id on Base. It also explicitly distinguishes itself from the sibling base_nft_owner, making the scope unambiguous.

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 ('Use to show or check what an NFT is') and names the alternative for a different need ('for its owner use base_nft_owner'). This is clear when/when-not guidance, not mere implied usage.

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?

Adds substantial context beyond annotations: error behavior (404 missing contract, 422 nonexistent token, both uncharged), pricing model ($0.01/call, first 25 free, failed calls free), and clarifies that the tool is read-only and changes nothing. It also explains why idempotentHint=false by noting each successful repeat incurs a charge.

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

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

Front-loads the definition in the first sentence, then layers usage, alternatives, error codes, a concrete example, and pricing without any filler. Every sentence contributes actionable information for correct invocation.

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

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

No output schema exists, but the description states what is returned (owner, name, symbol) and covers error codes, pricing, and safety profile. An agent has everything needed to call the tool correctly and understand the outcome.

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

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

Schema coverage is 100%, so both parameters are fully documented in the input schema. The description adds an inline example with plausible values for contract and tokenId, but does not add syntax or format details beyond what the schema already says.

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 (owner of an NFT), the exact resource (ERC-721 token id on Base), and the returned data (owner, name, symbol). It explicitly distinguishes itself from base_nft_balance and base_nft_metadata, 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?

Provides concrete scenarios (verify holder before trade, mint gate, airdrop) and names the alternative siblings for balance and metadata queries. The when-to-use and when-to-use-something-else rules are fully 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?

Adds real value beyond the annotations: both confirmed and pending counts are returned, malformed input yields a 400 with no charge, and cost is $0.01/call with 25 free and failed calls free — consistent with idempotentHint=false, since repeated calls are billed. The description could still say more about the response shape (two fields? field names?), but the billing and error behavior are unusually well disclosed.

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

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

Front-loaded with the core action, then use cases, then the sibling redirect, then pricing. Information-dense but nearly every clause is actionable; the pricing/payment clause is long and slightly crowds the functional content.

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 carries the burden of return values and it does indicate confirmed vs. pending counts, though not the exact response fields. For a single-parameter read tool with full annotation coverage, this is close to 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 coverage is 100%, so baseline is 3, but the description adds a concrete example address and states the validation contract (malformed address rejected with 400, uncharged), which is meaning the schema does not convey. It stops short of any format nuances beyond the 0x prefix.

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 ('Read the transaction count (nonce) of a 0x address on Base'), scopes it to confirmed plus pending, and explicitly redirects balance queries to base_balance. An agent can distinguish it from the ~18 sibling base_* tools and from eth_nonce/op_nonce by chain name alone.

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

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

Gives two concrete use cases (building the next transaction; determining whether an address has ever sent anything) and names the alternative tool for the adjacent task ('for its balance use base_balance'). Exclusions and selection criteria are explicit rather than inferred.

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

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

With annotations already covering readOnly/destructive, the description adds real context: 400 for malformed address and 404 for codeless address are uncharged, costing is $0.01/call with 25 free and failed calls free, and it explains why idempotentHint=false ('each call is charged, so repeats are not free'). Only the shape of the returned data is left unspoken.

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 capability, then usage, then failure modes, then pricing — good ordering. It is dense but every sentence (errors, price, 'failed calls free') carries decision-relevant information for an agent; the pricing tail runs a bit long.

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-param read-only tool with no output schema, this covers purpose, detection methods, error semantics, and cost. The only gap is that the returned structure (e.g., how the detected kind and addresses are presented) is not hinted at beyond 'names the kind found.'

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?

Single parameter at 100% schema coverage sets baseline 3, but the description adds a concrete example address showing the expected 0x hex form, which is slightly more than the schema's '0x contract address'.

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?

Specific verb+resource: 'Find the implementation behind a proxy contract on Base', and it enumerates the exact slots/standards checked (EIP-1967, beacon, admin, EIP-1822/UUPS, legacy OZ, EIP-1167). This is trivially distinguishable from sibling base_is_contract or base_storage.

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

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

Explicitly states when to use ('before trusting or decoding a contract whose code can be swapped by its admin') and names the alternative ('for a fuller risk verdict use contract_risk'). The when-not and routing to a sibling are both 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?