x402 Bazaar

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

No annotations are provided, so the description carries full burden. It fully discloses that the tool queries Base RPC, costs $0.02 per call, explains pricing headers, free calls per day, and that no wallet or API key is required. This is comprehensive transparency.

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 extremely concise: it front-loads the purpose with 'Instant profile of any Base address', then lists specific data, and ends with pricing and access details. Every sentence adds value with no redundancy.

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 single required parameter and no output schema, the description adequately explains what the tool returns (EOA vs contract, balances, tx count, activity level), how to access it (pricing, header), and prerequisites (none). No additional context is needed.

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 schema has 100% coverage for the single parameter 'address', but the description adds the context that it is a 'Base address', which narrows the meaning. This adds value beyond the schema.

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

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

The description clearly states it provides an 'Instant profile of any Base address' including specific data like EOA vs contract, ETH+USDC balance, transaction count, and activity level. This distinguishes it from siblings such as 'address-trust' or 'wallet-summary'.

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 explicitly states the tool is 'Useful for counterparty and wallet checks,' giving clear usage context. However, it does not specify when not to use it or mention alternatives among the many sibling tools.

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

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

No annotations provided, so the description carries full burden. It discloses that the tool reads an onchain attestation and returns a verdict. It mentions pricing model and that no wallet/API key is required. However, it does not discuss rate limits, latency, or potential errors. Since no annotations exist, the description adds moderate transparency but could be more detailed.

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 question and provides key details (verification source, output, pricing) in a concise manner. Although slightly verbose with pricing details, the information is well-organized and efficient. Could be trimmed slightly, but overall good.

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

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

The description covers the tool's purpose, mechanism, output (verdict + trust score), and usage context (pre-transaction gate). It also explains pricing and free call availability. Since no output schema is provided, the description adequately describes the return values, making it complete for a simple 1-param 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% with a single parameter 'address' described as 'Address to check'. The description reinforces this with 'Required input: address'. It adds no additional semantic information 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 clearly states the tool's purpose: checking if a counterparty is Coinbase-verified or an anon/sybil. It specifies the verification source (EAS attestation) and output (verdict + trust score). It distinguishes from siblings by mentioning pairing with sign-guard/spend-audit.

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

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

The description provides context for use ('who am I dealing with?' check, pre-transaction gate) and implicitly suggests when to use (when assessing counterparty trust). It does not explicitly state when not to use or list alternatives, but the sibling context and pairing advice give good 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?

Describes the output ('drain-surface verdict' with 'ERC-20 revoke queue'), pricing, and access method, but does not explicitly state if the operation is read-only (no annotations provided, so description carries burden). Disclosed behavioral traits are clear and 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?

Contains multiple clauses and pricing details that could be separated or streamlined. Still front-loaded with purpose, but marketing tone adds some verbosity.

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?

Explains the tool's unique value relative to siblings and mentions output type, but lacks explicit structure of the verdict or revoke queue. Given no output schema, more detail would improve completeness.

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?

Input schema has 100% coverage with 'wallet' described as 'Wallet address'. The description reiterates it as required input but adds no further semantics or validation rules, meeting the baseline for full schema coverage.

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

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

Clearly states the tool's unique function: checking all ways a wallet can be drained without a fresh signature, combining ERC-20 approvals and Base Account spend permissions, distinguishing it from sibling tools like approval-advisor and spend-audit.

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 contrasts with other tools: 'Approval tools miss the spend permissions; spend-permission tools miss the approvals.' This tells the agent when to use this as the only combined check for complete exposure.

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

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

No annotations present. The description discloses it uses Claude to explain and lists pricing/header requirements, but does not state if the tool is read-only, stores data, or has rate limits.

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

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

Front-loaded with main purpose, but includes extraneous pricing and header details that could be separated. Slightly verbose for the core functionality.

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

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

Covers purpose, input, output example, and pricing. Missing explicit blockchain context, but address implies Ethereum-like. No output schema, but description adequately explains return format.

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

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

Schema coverage is 100% with a simple 'address' parameter described. The description adds no additional semantic detail beyond 'Required input: 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?

The description clearly states the tool combines security flags with ABI function names and explains dangerous capabilities in plain English. It distinguishes itself from siblings like contract-abi and contract-danger by mentioning 'goes beyond raw flags' and providing a danger level.

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

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

The description implies usage via 'Required input: address' and 'Goes beyond raw flags', but lacks explicit when-to-use vs. alternatives. No exclusions or comparisons to sibling tools are provided.

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

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

With no annotations, the description carries full burden. It discloses key behavioral traits: guaranteed valid JSON via Claude structured outputs, 16K char limit, list=true behavior for arrays, pricing ($0.03/call), credit token access, and free daily call. It does not mention error handling or field absence behavior.

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

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

The description is front-loaded with the core purpose and has a logical flow from functionality to constraints to pricing. It is somewhat lengthy but every sentence adds value; minor redundancy 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?

Given no output schema, the description adequately explains return values: exact keys requested in guaranteed JSON format, with array for list=true. It covers constraints (16K chars, up to 10 fields) and pricing, leaving no major gaps for agent invocation.

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

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

Schema coverage is 100%, but description adds significant meaning beyond schema: fields limited to 10, list=true extracts repeated records as arrays, and text is required. Pricing and usage context enhance understanding.

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

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

The description clearly states the tool converts unstructured text to structured JSON using the verb 'turn' and specifies the resource 'text' with output 'clean, schema-enforced JSON'. It distinguishes itself from sibling 'ai-extract-batch' by emphasizing 'one call' and being the 'universal parse step' for single documents.

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

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

The description explains when to use the tool: for extracting structured data from any text up to 16K chars, not crypto-specific. It implies alternatives through sibling naming (ai-extract-batch) but lacks explicit when-not-to-use guidance or comparison to siblings.

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

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

No annotations provided, so description carries full burden. Discloses pricing ($0.10/call, 1 free/day), character limit (6K), payment via x-credit-token, no wallet needed, and alternative input format (||| separator). Fully transparent.

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

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

Four sentences with front-loaded core purpose. Each sentence provides essential info, though pricing details could be separated. No fluff, but slightly longer than ideal.

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, but description states output is 'one schema-enforced JSON object per document'. Covers constraints (character limit, count), pricing, and authentication. Complete for an extraction tool without output schema.

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

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

Schema coverage 100% but descriptions are minimal ('Document 1'). Description adds meaning: explains how to send multiple texts via text1&text2 or texts= with |||, up to 10 texts, 6K chars, and field list usage. Significantly enriches parameter understanding.

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

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

The description clearly states it's the batch version of ai-extract for up to 10 texts, with verb 'extract' and resource 'fields across documents', and distinguishes from sibling ai-extract by calling it the 'pipeline version'.

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 built for parsing feeds, inboxes, scrape batches, receipt piles; mentions required input text1 and field format. Does not give explicit when-not-to-use but provides sufficient context for selection.

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

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

With no annotations provided, the description carries full burden. It transparently states the tool is a Claude-written brief, covering mood, highlights, launches, and cautions including rug risk flags. It also describes pricing model and authentication, leaving no hidden behaviors.

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 purpose and well-structured, though it includes pricing and authentication details that could be considered extras. However, these details are relevant for usage and do not create significant bloat.

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 tool has no parameters and no output schema, the description is comprehensive. It explains what the brief includes, pricing, authentication, and usage context, making it fully actionable without additional lookups.

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

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

There are zero parameters and schema description coverage is 100%, so the description's lack of parameter details is acceptable. Baseline for 0 params is 4, and the description compensates by explaining output content.

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

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

The description clearly states the tool provides a 'Claude-written situational brief of the Base token market'. It specifies the verb (writes), resource (Base token market), and scope (aggregates trending and newly-listed tokens). This distinguishes it from sibling tools that focus on individual token analysis.

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

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

The description explains that a single call gives 'market context instead of dozens of lookups', providing clear when-to-use guidance. It also mentions pricing and authentication headers, but does not explicitly exclude cases or list alternatives.

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

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

No annotations are provided, so the description carries the full burden. It discloses pricing, credit token header, free calls, and character limit (16K). It is a read-only summarization, and the description clearly states no destructive behavior. It explains how to use (send text, get JSON). Good transparency.

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 informative but slightly verbose, with some repetition (e.g., 'one micro-payment' and 'Priced $0.03'). However, it is well-structured with key points upfront: input, output, limits, pricing. Overall efficient for the information conveyed.

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

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

Given no output schema, the description explains the output as 'clean JSON' and bullet points. It covers input limits (16K), output count (3-5), pricing, and authentication. For a simple tool with one parameter, it is highly 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?

Only one parameter 'text' with schema description 'Text to summarize'. The description adds value by specifying the character limit (16K), output format (bullets), and that it is required. Since schema coverage is 100%, baseline is 3, but extra context justifies a 4.

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

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

The description clearly states the tool converts any text into crisp bullet points, compresses up to 16K characters, and outputs 3-5 bullet points. It specifies input as text and output as JSON. This distinguishes it from sibling tools like ai-translate and ai-extract, showing it is specifically for summarization.

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

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

The description says 'The digest step for agent pipelines that read more than they can carry in context,' implying when to use for condensing text. It mentions required input text and pricing. While it doesn't explicitly exclude other tools, the sibling list has no other summarization tool, so usage context 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?

With no annotations provided, the description carries full burden for behavioral transparency. It explains the tool aggregates risk, holder concentration, price/liquidity, and OFAC sanctions, and outputs a verdict. It also mentions pricing and free calls. However, it lacks details on error handling, rate limits, or what happens with invalid addresses.

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

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

The description is front-loaded with the primary purpose and key details. It includes pricing and usage context, which is useful but slightly verbose. Every sentence adds value, though some pricing information could be delegated to annotations. Overall it is well-structured but not perfectly concise.

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

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

Given no output schema, the description adequately explains the output structure ('structured verdict with key risks and positives'). It covers the main functionality and constraints (single parameter, pricing). It could mention error cases or response format more explicitly, but for a simple tool it is largely complete.

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

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

The input schema has 100% description coverage (address is described as 'Token contract address'), so the description adds no additional meaning beyond confirming the required input. Baseline score of 3 is appropriate since the schema already documents the parameter adequately.

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

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

The description clearly states the tool provides a 'Claude-written due-diligence verdict for a Base token' by aggregating multiple data points and synthesizing a structured verdict. It distinguishes itself from sibling tools like token-risk or token-info by offering a comprehensive, agent-ready intelligence report in one call.

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

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

The description gives clear context for when to use the tool (for a due-diligence verdict) and specifies required input (address). It also mentions pricing and that no wallet/API key is required. However, it does not explicitly state when not to use it or direct to alternative tools, which would enhance guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behaviors: character limit (6K), pay-per-call ($0.03), network (x402 on Base), optional credit header, free daily call, and return format (only translation, no wrapper). Missing details like error handling or rate limits, but the disclosed info is substantial.

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 moderately long but each sentence adds value. It is front-loaded with the main action ('Translate up to 6K chars to any language'). Some redundancy (e.g., mentioning required input twice) could be trimmed, but overall efficient.

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

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

Despite no output schema, the description fully explains what the tool returns ('only the translation back — no notes, no wrapper prose, safe to pipe straight into the next step'). Given the low complexity and simple parameters, this is sufficient. Pricing and header options further complete the context.

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

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

Schema coverage is 100% with descriptions for both parameters ('Target language' and 'Text to translate'). The description adds meaningful context: character limit for text, and that 'to' accepts any language. Also mentions required input text, reinforcing schema. This extra value justifies above baseline 3.

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

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

The description clearly states the tool translates text up to 6K characters to any language, using a specific verb ('Translate') and resource ('text'). It distinguishes from siblings, which are all blockchain/DeFi tools, so its translation purpose is unique.

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

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

The description specifies when to use: for localizing content, parsing foreign sources, and serving multilingual users. It also provides usage details like sending text and to parameters, and mentions pricing and header options. No explicit exclusions or alternatives are given, but the sibling set lacks other translation tools.

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

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

No annotations are provided, so the description carries the full burden. It discloses pricing, free tier, and access requirements, but does not explicitly state that the tool is read-only or non-destructive. The mention of 'risk read' hints at safety evaluation but lacks explicit behavioral details.

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 concise (3-4 sentences) and front-loaded with the primary purpose. Every sentence adds value: purpose, output details, pricing, and access. No wasted words.

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

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

Despite no output schema, the description clearly explains what the tool returns (action, risk read, notes). It covers input, output, cost, and authentication requirements. For a simple, single-parameter tool with no annotations, this is complete.

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

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

Schema coverage is 100% with the 'hash' parameter well-described as 'Transaction hash'. The description adds that it is a 'Base transaction hash', which is slightly more specific but does not fundamentally add meaning beyond the schema. Baseline 3 applies.

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

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

The description is highly specific: 'Plain-English explanation of any Base transaction' with a clear verb ('explains') and resource ('Base transaction'). It distinguishes from sibling tools like tx-decode by focusing on human-readable interpretations.

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

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

The description clearly states when to use the tool (when you need a plain-English explanation of a Base transaction). It provides context on the output (action, risk read, notes) but does not explicitly mention when not to use it or how it differs from alternatives like tx-decode.

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 discloses key behaviors: pulls token approvals, uses Claude for audit, and outputs risk level, USD risk, and recommendations. It also mentions pricing. However, it does not mention if the tool is read-only, rate limits, or error handling. With no annotations, this is a moderate gap.

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

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

The description is detailed and well-structured, front-loading the core purpose. While it includes pricing and usage notes, every sentence adds value. Slightly verbose but still effective.

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 input schema (1 parameter, no output schema), the description provides sufficient context: input, output nature, use case, and pricing. Missing error handling or example output, but overall complete enough for agent invocation.

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

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

Schema coverage is 100% for the single 'address' parameter. The description adds context about what the tool does with the address but does not elaborate on parameter format or constraints. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: pull active token approvals and generate a security audit with risk level, USD at risk, and revoke recommendations. It distinguishes itself from sibling tools like 'spend-audit' or 'token-approvals' by focusing on wallet security audit.

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

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

The description advises using the tool 'before trusting an address', giving clear usage context. However, it does not explicitly state when not to use it or list alternative tools, though the purpose is specific enough to differentiate.

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 explains that approvals are a drain vector and the tool ranks them by risk, implying a read-only operation. It also covers pricing and authentication requirements. Without annotations, it provides sufficient behavioral context but lacks an explicit statement about being non-destructive or how errors are handled.

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 paragraph that efficiently conveys purpose, ranking logic, and usage details. It is front-loaded with the primary function but could be slightly more concise by reducing repetitive details about pricing. Overall, it is well-structured and not overly verbose.

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 tool's complexity (ranking by multiple factors) and lack of output schema, the description adequately explains the output as a prioritised revoke queue and covers all necessary usage context (input, pricing, authentication). It is complete for a single-parameter 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?

The input schema covers 100% of parameters with a single 'address' parameter described as 'Wallet address'. The description adds minimal extra meaning beyond what the schema already provides, merely reiterating the requirement. Baseline of 3 is appropriate.

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

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

The description clearly states that the tool ranks a wallet's active token approvals by risk factors (USD-at-risk, unlimited-allowance, unlabelled-spender) and returns a prioritised revoke queue. It uses specific verbs and distinguishes from siblings like 'token-approvals' and 'revoke-builder' by focusing on risk prioritization.

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

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

The description indicates when to use the tool ('tell an agent exactly what to revoke first') and provides required input ('address') along with pricing and authentication details. However, it does not explicitly state when not to use it or compare directly to alternatives, though the context of revoking approvals 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?

No annotations provided, so the description carries full burden. It discloses pricing, prepaid header for unlimited calls, free calls per day, and that no wallet or API key is required. It also explains the output concept (decode per scope) without contradictions.

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 relatively concise given the complexity, with the main purpose front-loaded. It contains some redundant phrasing but overall each sentence adds value.

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

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

For a single-parameter tool with no output schema, the description fully explains the output concept (BLOCKLIST vs ALLOWLIST per scope), prerequisites (address), pricing, and usage context. It is complete and leaves no major gaps.

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

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

Schema description covers address as 'B20 token address' (100% coverage). The description adds value by explaining the address is required and tying it to the tool's purpose, but the schema already provides the basic meaning.

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

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

The description clearly states the tool decodes B20 transfer policy type (BLOCKLIST vs ALLOWLIST) per scope, with specific verb 'decoded' and resource 'per scope'. It distinguishes from sibling b20-safety by noting b20-safety flags existence while this decodes type.

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

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

The description provides context for when to use (to differentiate between blocklist and allowlist tokens) and contrasts with b20-safety. It does not explicitly state when not to use or list alternatives, but the context 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?

With no annotations, the description compensates by disclosing it is a read operation, pricing details ($0.03 per call, free daily call), and that no wallet or API key is required. No destructive side effects are indicated, and no contradictions exist.

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 well-structured, starting with purpose, then explaining announcements, and concluding with usage notes. While slightly verbose, every sentence contributes value, and important information is front-loaded.

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

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

Given the single parameter, no output schema, and no nested objects, the description adequately covers purpose, input, pricing, authentication, and the concept of announcements. It is sufficiently complete for a simple 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?

Schema coverage is 100% for the single required parameter 'address', which is described as 'B20 Asset token address'. The description reinforces this but adds no additional semantic detail beyond the schema, meeting the baseline for high 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?

The description clearly specifies the tool reads on-chain announcements (issuer notices, corporate actions) for B20 Asset tokens, using a specific verb and resource. It distinguishes from siblings by noting that ERC-20 tokens lack an equivalent channel, positioning it as an issuer-communications primitive.

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

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

The description states the required input (address) and implies the tool is for reading announcement feeds of B20 tokens. However, it does not explicitly provide when-not-to-use scenarios or compare with related sibling tools (e.g., b20-info, b20-dossier), leaving some ambiguity in tool selection.

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

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

No annotations, so description carries full burden. Discloses verification mechanism (factory registration + bytecode absence), verdict types, pricing ($0.02/call), auth (x-credit-token or free call/day), and network (Base). Lacks details on response format or latency, but overall strong.

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

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

Description is verbose but each sentence adds value: purpose, scam context, verification method, verdict, pricing, auth. Front-loaded with the core question. Could be slightly trimmed, but well-structured.

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

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

For a simple 1-parameter tool with no output schema or annotations, the description is complete: explains return values, usage context, pricing, and authentication. Agent has everything needed to select and invoke 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 has 100% coverage for the single 'address' parameter. Description adds no extra semantics beyond what the schema provides, only restates 'Required input: address'. 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?

Description clearly states the tool verifies if an address is a genuine B20 precompile or a fake lookalike, with three verdicts. It distinguishes from numerous B20 siblings by being the first check to run.

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 says 'Run FIRST on any B20' and explains why: scammers can fake other B20 read surfaces. This provides clear context for when to use it, though no explicit when-not-to-use is stated.

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

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

With no annotations, the description carries full burden. It discloses the operation is a scan (not a mutation), explains the scoring categories, and states no wallet or API key is needed. However, it does not explicitly confirm idempotency or describe error handling or rate limits beyond pricing.

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 moderately concise, front-loading the core action and then adding context on scoring, target users, input, and pricing. It could potentially be shortened without losing meaning, but it remains well-organized and informative.

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 tool has one parameter, no output schema, and no annotations, the description covers the purpose, input, scoring details, and authentication. It does not specify the exact output format, but it hints at the scores being returned. Overall, it provides sufficient context for an agent to use the tool correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by specifying the limit of up to 5 tokens, which is not in the schema. It also reiterates the comma-separated format, confirming the schema's description.

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

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

The description clearly states it performs a B20 safety verdict across up to 5 tokens, scoring for freeze/seize/pause/rebase/uncapped-mint and surfacing the worst score. It distinguishes itself from sibling tools like b20-safety by explicitly mentioning batching multiple tokens.

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

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

The description specifies target users (portfolio holders, agents screening several B20s) and mentions pricing and authentication options. However, it does not explicitly state when not to use this tool (e.g., for a single token, use b20-safety instead), though it is implied by the 'batch' context.

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

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

With no annotations, the description fully discloses behavior: what it audits, the verdict levels, pricing ($0.05/call), auth methods (x-credit-token or free daily call), and that no wallet or API key is needed. It also explains that a scope bound to a non-existent allowlist silently denies everyone, indicating thoroughness.

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 somewhat dense with jargon and includes pricing details that could be separated. While it front-loads purpose, it could be more concise and better structured for quick parsing.

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

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

Despite lack of output schema and annotations, the description covers inputs, behavior, verdicts, pricing, and auth. It is reasonably complete for a single-parameter tool, though an example or more explicit list of checks could enhance completeness.

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 one parameter 'address' described as 'B20 token address'. The description does not add significant new semantic information 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 clearly states the tool audits B20 token configurations for misconfigurations like dangling bindings and frozen lists, and returns a verdict. It uses specific jargon like 'bricked scopes' and distinguishes itself from sibling tools by focusing on config linting.

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

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

The description provides use cases ('Pre-launch lint for issuers, stuck-funds guard for holders and merchants') and required input, but does not explicitly state when not to use it or compare to alternatives. However, the context is clear enough for an agent to infer appropriate 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?

No annotations exist, so description fully discloses that it reads onchain events, reports controllers/centralization, and mentions pricing, x402 method, free tier, and no wallet/API key needed.

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?

Packed with information but front-loaded with key question and contrast. Every sentence adds value, though could be slightly tighter.

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

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

Covers purpose, input, output info (controllers, centralization, admin status), pricing, and prerequisites. Lacks example output, but adequate for a single-param tool with no output schema.

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

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

Schema coverage is 100% with a simple 'address' description. The description confirms it's required but adds little beyond the schema's stated purpose.

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

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

The description clearly states it reads who can control B20 (mint, seize, etc.) and distinguishes from sibling b20-safety by contrasting WHICH vs WHO. Specific verb 'reads' and resource 'role-based access control'.

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 contrasts with b20-safety, states 'before holding a regulated asset', and notes required input. No direct when-not-to-use, but context 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?

No annotations provided, so description carries full burden. Discloses pricing ($0.75 per call), authentication (x-credit-token), free daily call, and that no wallet/API key is needed. Describes report contents, but lacks details on rate limits or error states.

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?

Description is verbose with marketing language ('premium tier', 'Claude writes...'). While it front-loads the purpose and includes useful detail, it could be more concise. Structure is clear with a list of report components.

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 one parameter and no output schema, description thoroughly explains output: specific checks (seize/freeze/pause powers, supply cap, etc.) and verdict components (issuer-control score, seizure risk, red flags, recommendation). Also covers pricing and access, making it complete for a reporting 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 'address' with schema description 'B20 token address'. Description adds context by repeating 'Required input: address' but does not elaborate on format or constraints. Schema coverage is 100%, so baseline is 3.

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

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

Clearly states the tool produces an institutional AI report on a Base-native B20 token, listing specific components and differentiating from ERC-20 tools. The description uses specific verbs like 'composes' and 'writes'.

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

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

Implies usage for a full due-diligence report on a B20 token, but does not explicitly compare with sibling b20-* tools or provide exclusions. Mentions required input and pricing, but no guidance on when to choose this over alternatives.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool checks authorization and explains the consequences (seizure risk). It also mentions pricing and network (Base x402). However, it does not mention error handling, data freshness, or rate limits, leaving some gaps.

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

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

The description is front-loaded with the key question and action. It is structured logically: problem statement, what it does, companion reference, required inputs, pricing. It is slightly verbose with promotional language but remains clear and readable.

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 tool has only two parameters and no output schema, the description provides sufficient context: what it checks, consequences, required inputs, and pricing. It could mention the expected output format (e.g., boolean or status) but is otherwise complete.

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

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

Schema description coverage is 100% with basic descriptions for both parameters. The description adds value by explaining the purpose of the check, how the inputs are used, and the context of the policy. It goes beyond the schema by clarifying the stakes (freezing/seizure).

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

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

The description clearly states the tool checks wallet authorization under a B20 token's transfer-sender policy, explaining the consequence of being unauthorized (cannot transfer, can be seized). It distinguishes itself as the personal companion to b20-safety, making its purpose distinct among siblings.

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

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

The description explicitly lists required inputs (token, wallet) and provides a concrete use case ('Is YOUR wallet blocked or seizable?'). It also connects to b20-safety as a companion tool, but does not explicitly state when not to use it or list alternatives.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool performs multiple mutating actions (seize, freeze, rebase, pause, mint) collapsed into one verdict, and returns an auditable receipt. It also mentions pricing, free tier, and that no wallet or API key is needed. This provides good behavioral context, though it does not detail the receipt format.

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

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

The description is relatively dense but efficient. It front-loads the core concept ('One GO/HOLD/STOP verdict'), then lists the components, optional parameter, and pricing. Every sentence adds value, though the pricing details could be separated for better readability. Overall, it is well-structured for its length.

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 tool's moderate complexity (2 parameters, no output schema), the description adequately covers the main purpose, parameter meanings, usage context, and pricing. The lack of output schema is partially compensated by the mention of an 'auditable receipt', though the receipt content is not detailed. The description is sufficient for an agent to use the tool correctly.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds context: 'address' is the token address, 'wallet' is optional to check if the user is blocked. This aligns with the schema descriptions and does not add significant new meaning beyond clarifying the wallet parameter's purpose. 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 explicitly states the tool's purpose: a single call that combines multiple checks into a GO/HOLD/STOP verdict for a B20 token. It uses specific verbs ('seize', 'freeze', 'rebase', 'pause', 'uncapped-mint') and resource ('B20 token'), clearly distinguishing it from many B20 sibling tools.

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

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

The description indicates this is the primary tool to use before trading a B20 token ('the single call before trading a Base-native B20'). It implies it should be used first among sibling tools. It provides clear input requirements ('Required input: address') and optional wallet check. However, it does not explicitly state when not to use it or name alternatives.

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

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

No annotations provided, so the description carries full burden. It explains the tool reconstructs pre-mints, role grants, policy bindings, blocklist seeding, and outputs a verdict. Also covers pricing and authentication (x-credit-token header). Adds significant behavioral context beyond the schema.

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

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

The description is front-loaded with the core purpose, then details output and pricing. It is slightly verbose but every sentence adds value. Could be trimmed slightly, but overall efficient.

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

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

Given no output schema, the description explains the verdict types and what is reconstructed. For a single-parameter tool, it covers the key contextual needs: input, output, and usage conditions (pricing, auth).

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

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

Schema coverage is 100% with one parameter (address) described as 'B20 token address'. The description adds that it is required and provides context for the input, but does not add meaning beyond what the schema already states. Baseline 3 is appropriate.

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

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

The description clearly states the tool audits what the issuer did in the initCalls bypass window for a B20 token, reconstructing specific actions and providing a verdict. It is a specific verb+resource (audit genesis) and distinguishes from siblings like b20-config-audit or b20-mint-watch.

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

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

The description mentions required input (address) and pricing but does not explicitly say when to use this tool vs alternatives (e.g., b20-config-audit for ongoing config). It implies usage context but lacks exclusion or alternative guidance.

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

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

With no annotations, description fully discloses behavioral traits: real-time webhook capture, pricing ($0.05/call, optional prepaid header, 1 free/day), no wallet/API key needed. Comprehensive for a paid API 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?

Every sentence adds value: function, mechanism, pricing, usage modes. Packed but concise with no wasted words. Immediately front-loads core purpose.

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

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

For a single-parameter tool with no output schema or annotations, the description provides complete context: what it does, how to use, pricing, and expected outputs. Adequately covers all necessary information.

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

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

Schema coverage is 100% (one parameter described), so baseline is 3. Description adds meaning by explaining optionality leads to different outputs (live status vs. feed) and hints at return content, going beyond the schema's brief description.

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

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

Description clearly states real-time alerts for B20 token seizure events, distinguishes from b20-policy-watch as 'live layer', and explains two usage modes (address-specific or network feed). Specific verb+resource with sibling differentiation.

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

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

Explicitly states when to pass an address versus omit for network feed, and mentions differentiation from b20-policy-watch. Does not exhaustively list when not to use, but context is clear for a simple tool.

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

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

With no annotations, the description compensates by disclosing that the tool fetches data from a precompile, lists return fields, and states 'No wallet or API key required.' It also mentions pricing and payment methods. However, it does not explicitly confirm read-only behavior or describe rate limits beyond the free call per day.

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

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

The description is a single dense paragraph that front-loads the tool's purpose and output fields. It is informative without being overly verbose, though it could benefit from slight restructuring (e.g., separating pricing from functional 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?

Given the absence of an output schema, the description provides a thorough list of returned fields (variant, name, symbol, decimals, supply, policies, pause states, rebase). It covers input requirements and pricing adequately. Minor gaps include error handling and edge cases, but overall it is complete for a simple query 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?

The schema description coverage is 100%, so the description adds no significant meaning beyond what the schema already provides for the single 'address' parameter. The tool description merely repeats 'Required input: address,' which is already 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?

The description clearly states it provides a 'full profile' of a B20 token and lists specific fields (variant, name, symbol, etc.). It also distinguishes itself from sibling 'b20-safety' by calling itself the 'data companion', effectively differentiating the tool's purpose.

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

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

The description indicates the required input ('Required input: address') and positions itself as the data companion to b20-safety, implying when to use each. However, it lacks explicit 'when to use' vs. 'when not to use' guidance and does not address alternative tools within the extensive sibling list.

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

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

No annotations exist, so description carries full burden. It discloses the tool's output (variant, symbol, decimals, block), warns that new tokens may be unsafe, and details pricing and access requirements (no wallet/API key needed). Could mention rate limiting beyond free call.

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

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

Description is front-loaded with purpose and output details. It includes useful context (safety warning, pricing, access) but is slightly verbose. Every sentence adds value, though some operational details could be moved to 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?

For a simple listing tool with one optional parameter and no output schema, the description fully covers purpose, output format, context (B20, Base), safety advisory, and access constraints. No gaps for correct usage.

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?

Input schema coverage is 100% with 'limit' described as 'How many'. Description adds context that it returns a list of newest tokens, implying limit controls count, but does not elaborate further. 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 clearly states it lists newly minted B20 tokens on Base, specifying the returned fields (variant, symbol, decimals, block). It distinguishes from siblings by focusing on new launches, contrasting with safety tools like b20-safety.

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

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

Provides explicit guidance to run b20-safety before interacting with any token, implying when caution is needed. Mentions pricing and access methods but does not explicitly list alternatives or when not to use the tool.

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

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

With no annotations, the description carries full burden. It discloses pricing ($0.03/call, free tier), authentication (prepaid header, no API key required), and that it is a read operation (reads event history). It does not mention any destructive behaviors or rate limits, but the disclosed traits are sufficient for safe agent invocation.

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 fairly long but information-dense. It front-loads the core action, then adds pricing and authentication details. Some sentences (e.g., 'a field ERC-20 has no equivalent for') are informative but slightly extraneous. It could be more concise without losing clarity.

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 absence of an output schema, the description covers the return context implicitly ('reads a token's on-chain Memo event history'). It explains required input, optional filters, use case, and pricing. Missing explicit output format, but for a read tool, the description is nearly complete.

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

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

Schema coverage is 100%, but the description adds value by explaining the filter semantics ('bytes32', 'caller wallet') and the primary use case. It clarifies parameter roles beyond the schema descriptions, such as 'memo' being bytes32 and 'caller' filtering by wallet.

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

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

The description clearly states the tool reads Memo event history on B20 tokens, providing payment IDs and compliance tags. It uses specific verbs ('reads', 'adds') and resources ('B20 token', 'Memo event history'). However, it does not explicitly differentiate from sibling B20 tools, which counts against a perfect 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?

The description implies usage for settlement reconciliation with B20 stablecoins, and mentions required input (address). It does not provide explicit when-not-to-use guidance or alternatives from sibling tools. The usage context is implied but not fully 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?

With no annotations, the description carries full burden. It explains the tool reads on-chain data to determine mutability and rename history, mentions cost and header requirements, and clarifies no wallet/API key needed. Lacks explicit 'read-only' declaration but is otherwise transparent.

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

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

The description is packed with useful information but could be more front-loaded. It starts with a question followed by explanation, which is efficient but slightly verbose. Still, every sentence adds value.

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

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

For a single-parameter tool with no output schema and no annotations, the description adequately covers purpose, input, pricing, and access method. The output is not detailed, but the tool's function is clear.

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 a single 'address' parameter described as 'B20 token address'. The description adds no additional semantics beyond the schema, meeting the baseline but not exceeding 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?

Clearly states the tool reads two specific aspects (mutability and rename history) of a B20 token, with a specific verb 'reads' and resource 'B20 token metadata'. Distinguishes itself from many sibling b20-* tools by focusing on rename capability.

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 operational guidance (pricing, header) and a caution ('Trust the address'), but does not explicitly specify when to use this tool versus alternatives among the many sibling B20 tools. Usage is implied rather than explicitly contrasted.

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

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

No annotations provided, so description carries full burden. Discloses it's a read-only monitoring tool, includes pricing model ($0.03/call, free tier, prepaid credits), and mentions no wallet/API key required. Does not mention rate limits or side effects, but acceptable for this tool type.

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?

Single paragraph packs multiple pieces of information (purpose, sibling distinction, data details, pricing) without wasted words. Could be formatted more clearly (e.g., bullet points), but every sentence adds value.

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 2 plain parameters and no output schema, the description covers purpose, parameter constraints, and behavioral context (pricing, no auth). Lacks output format details, but that is not required when output schema is absent.

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%, but description adds value by specifying valid range for 'days' (1-90) and confirming 'address' is required. Provides context beyond schema names alone.

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?

Description clearly states the tool monitors token mints ('actual printing'), distinguishes from sibling 'b20-supply' (dilution ceiling vs actual mints), and specifies the data shown (amount, recipients, dilution category).

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 context ('live issuance feed for agents holding B20 stablecoins and RWAs'), parameter range (days 1-90, default 30), and required address. Could explicitly state when not to use or suggest alternatives beyond b20-supply, but adequate.

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

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

No annotations are provided, so the description carries full burden. It discloses return values, pricing, authentication (header or free daily call), and no wallet/API key requirement. However, it does not explicitly state that the tool is read-only or idempotent.

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 contains valuable information but is somewhat verbose and includes operational details (pricing, headers) that could be condensed. The structure is slightly stream-of-consciousness.

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 tool's simplicity (one parameter, no output schema), the description is fairly complete, explaining purpose, return values, and operational constraints. It adequately covers what an agent needs to know.

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 a single parameter (address) already described in the schema. The description adds minimal extra meaning beyond 'Required input: address', 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 clearly states the tool's purpose: checking if a B20 stablecoin's declared peg matches its actual DEX market price, with specific return statuses. It distinguishes this tool from siblings (e.g., b20-stablecoin) by focusing on peg verification.

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

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

The description explicitly says 'Run before settling in any B20 stablecoin', providing clear context for use. However, it does not explicitly state when not to use it or list alternative tools for similar checks.

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?

Explicitly states read-only behavior, signing nothing. Discloses pricing structure, header requirements, and free call allowance. No annotations provided, so description fully carries the transparency burden and does so thoroughly.

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 then provides additional details. It is packed with information but not excessively verbose. Could tighten a bit, but overall efficient and well-structured.

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

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

Given no output schema, the description adequately describes what is returned (DOMAIN_SEPARATOR, nonce, domain/type struct). Covers inputs, read-only nature, and pricing. Could mention error handling or format, but sufficient for an agent to understand usage.

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 both parameters. Description adds meaning beyond schema by explaining the purpose of each parameter (address for token, owner for nonce) and that owner is optional. Provides context for why these values are 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?

The description clearly defines the tool's purpose: reading ERC-2612 permit data (DOMAIN_SEPARATOR, nonce, EIP-712 struct) for gasless approvals. It uses specific verbs like 'reads' and 'signs nothing', and distinguishes it from other B20 tools by focusing on permit readiness.

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 context on when to use (building a valid permit) and states required input (address) and optional owner. Mentions read-only nature and pricing. However, it does not explicitly exclude use cases or mention alternatives among the many sibling tools.

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

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

No annotations provided, but the description thoroughly discloses behavior: it is a read operation from the registry, requires an address, has a cost of $0.04, and offers free calls per day. No contradictions.

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 verbose but well-structured, front-loading the purpose and then adding supplementary details (pricing, alternative access). It is information-dense without being rambling.

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 one parameter and no output schema, the description sufficiently covers the tool's purpose, input, and output concept. It also provides context about related tools and access methods.

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 'address' with 100% schema coverage. Description adds value by specifying it's a B20 token address, which clarifies the input beyond the schema's generic description.

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

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

The description clearly states the tool reads who administers each active transfer/mint policy (policyAdmin) and whether control is being handed over (pendingPolicyAdmin) or renounced. It specifies the resource (Policy Registry) and verb (reads), and distinguishes from sibling b20-control.

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

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

The description provides clear context on when to use: to know who can freeze/seize you via the Policy Registry. It mentions b20-control as the counterpart, but does not explicitly state when not to use or list alternatives.

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

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

With no annotations, the description adequately explains that the tool replays historical events to build membership, providing full details (addresses, timestamps, actors, current member set). It also mentions pricing and authentication requirements. However, it does not explicitly state whether the tool is read-only, though the description implies it is not state-changing.

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 fairly concise at 4 sentences, front-loading the main purpose and distinguishing from siblings. Some promotional phrasing ('Compliance-grade visibility no other tool provides') adds minor fluff, but overall it is well-structured and informative.

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

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

Given no output schema, the description adequately specifies the return data (every address, when, by whom, and current member set per scope). It also covers input options and access methods. While it does not mention pagination or truncation, the tool appears to return the complete list, so completeness is high.

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

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

The input schema has 100% coverage with descriptions for both parameters. The description adds context by clarifying that 'address' is a B20 token address and 'policy' is a registry policy ID, and that either can be passed. This adds modest value beyond the schema, earning the baseline score of 3.

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

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

The description clearly states the tool enumerates the entire blocklist/allowlist of a B20 token, including history. It uses specific verbs like 'enumerates' and 'replays' and distinguishes itself from the sibling tool b20-freeze-check by noting that freeze-check answers for one wallet while this tool provides the whole list.

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

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

The description provides clear context on when to use this tool: for full compliance-grade visibility of the blocklist/allowlist, and explicitly contrasts with b20-freeze-check for single wallet queries. It also states input methods (address or policy) and pricing/access details, but does not explicitly list scenarios where the tool should not be used.

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?

Without annotations, the description fully discloses behavioral traits: it reads onchain events via CDP index, analyzes the policy/pause timeline, and returns whether and when the token became seizable. It also details pricing, call method (x402), and authentication requirements. No contradictions or hidden behaviors are present.

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

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

The description is a single paragraph that efficiently conveys purpose, mechanism, required input, pricing, and authentication. It front-loads the core question ('Did this token BECOME seizable?') but could benefit from more structured formatting (e.g., bullet points) to separate different aspects. Still, it's concise without unnecessary fluff.

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 tool has a single required parameter and no output schema, the description covers input requirements, pricing, authentication, and the nature of the output (if and when seizable). It does not specify the exact return format or sample response, which would enhance completeness. Overall, it provides sufficient context for an agent to use the tool correctly.

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

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

The schema covers the single parameter (address) with a description 'B20 token address'. The tool description repeats this exact phrase and adds context about its role as required input. With 100% schema coverage, the description adds minimal extra meaning beyond restating the parameter's purpose, keeping the score at baseline 3.

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

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

The description clearly states the tool checks if a B20 token became seizable after launch due to a policy update. It uses specific verbs ('reads', 'tells you if'), specifies the resource (B20 token's policy event timeline), and distinguishes itself from sibling B20 tools by focusing on seizability detection via policy changes.

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

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

The description provides clear usage context: required input (address), pricing ($0.03 per call via x402), and authentication options (prepaid x-credit-token header, free daily call). It notes no wallet/API key needed. However, it does not explicitly state when to use this tool versus similar siblings like b20-seizure-history, though the unique focus on policy changes is implied.

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

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

With no annotations, the description effectively communicates that the tool performs a read-only scan of wallet holdings, checks for freeze/seize powers and blocking status, and provides a verdict. It also includes pricing and access details, adding transparency.

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 a compelling question and provides necessary details. While it is relatively long, every sentence serves a purpose—clarifying functionality, target users, and pricing. Minor redundancy could be trimmed but overall well-structured.

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

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

Despite having no output schema, the description sufficiently explains the return values: per-token flags and a wallet-level verdict. The single required parameter is documented. It addresses the tool's specific use case and limitations, making it fairly complete for the intended context.

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

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

The only parameter 'wallet' has a basic description in the schema. The description adds no extra semantic information beyond what the schema provides. Given 100% schema coverage, a score of 3 is appropriate.

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

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

The description clearly specifies the tool's function: scanning a wallet's B20 holdings for freeze/seize powers and blocking status. It distinguishes itself from generic portfolio tools by highlighting the unique risk detection.

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

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

The description explicitly states when to use the tool (for checking freeze/seize powers on B20 holdings) and the target audience (agents holding Base positions). It does not directly mention alternatives from sibling tools but implicitly differentiates by noting what other tools miss.

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

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

With no annotations provided, the description carries the full burden. It discloses read-only behavior, output (multiplier, flag, stablecoin special case), pricing ($0.02/call, free daily call), and access (no wallet/API key required). It does not detail rate limits or error cases, but covers key operational traits.

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

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

The description is somewhat long but front-loaded with the core purpose. Every sentence adds value: purpose, behavior, stablecoin note, required input, pricing. Minor verbosity from pricing details, but overall efficient.

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 tool's simplicity (one parameter, no output schema, no nested objects), the description adequately explains what it does and the expected output concept. It lacks explicit return format details but covers enough for an agent to infer usage.

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 has 100% coverage for the single parameter 'address'. The description adds context by explaining the tool's purpose and what it does with the address, going beyond the schema's 'B20 token 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 clearly states the tool reads a B20 Asset token's rebase multiplier and flags balance scaling. It specifies the resource ('rebase multiplier'), action ('reads'), and scope ('Asset-variant'), distinguishing it from sibling tools like b20-rebase-history.

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

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

The description mentions required input 'address' and implies use for checking rebase multiplier and dilution risk. However, it does not explicitly state when to use versus alternatives (e.g., b20-rebase-history for historical data) or provide exclusions.

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

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

With no annotations, the description carries full burden. It discloses that the tool performs a historical replay, flags downward moves, requires no wallet or API key, and includes pricing. It does not mention output format but covers key behavioral traits.

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

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

The description is front-loaded with the core purpose, followed by additional context. While it includes pricing and credit token info, those are relevant for API usage. It is not overly verbose but could be slightly more streamlined.

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 read tool with no output schema, the description explains return behavior (history, flagging), usage rationale, pricing, and authentication. It is fully adequate to understand what the tool does and how to use 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?

The only parameter 'address' is already described in the schema. The description adds 'Required input: address' and context about Asset B20, but does not significantly enhance semantics beyond what the schema provides. Schema coverage is 100%, 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 explicitly states it replays the full MultiplierUpdated history and flags downward moves, distinguishing it from b20-rebase which shows today's value. The verb 'replays' and resource 'MultiplierUpdated history' are specific and 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?

The description advises using it 'before you hold a rebasing RWA' and contrasts with b20-rebase for current value, providing clear context. It does not explicitly list when not to use, but the guidance is sufficient.

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

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

With no annotations, the description carries full burden. It transparently explains the powers checked (seizable, freezable, paused, rebase, uncapped-mint) and the output (verdict). It also mentions pricing and access details. However, it does not address error handling or behavior for invalid/non-B20 addresses, which slightly reduces completeness.

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 question and provides all necessary information without excessive verbosity. It includes marketing elements that add context, but the pricing details could be slightly trimmed. Overall well-structured and efficient.

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 one parameter and no output schema, the description sufficiently explains the tool's output (verdict) and the criteria considered. It also covers pricing and access. Missing details on error handling or invalid inputs are minor gaps, but overall the tool's purpose and usage are well covered.

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

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

Schema coverage is 100%, so baseline is 3. The description adds that the address is 'B20 token address' and that input is required, but does not provide additional semantics beyond what the schema already offers.

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

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

The description clearly states the tool's purpose: to assess if a B20 token can freeze or seize funds, and it provides a verdict (hold/caution/avoid). It distinguishes itself from sibling tools by being the 'first B20-aware safety check on Base', which consolidates multiple powers into one comprehensive check.

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

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

The description implicitly suggests using this tool for overall safety assessment of B20 tokens, but it does not explicitly state when to use this vs. the many specific sibling tools (e.g., b20-freeze-check, b20-seizure-history). The guidance is clear but lacking explicit when-not or alternatives.

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

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

With no annotations, the description carries full burden. It discloses that the tool checks BurnedBlocked events, outputs a verdict (enforced/armed/no_seize_power), and mentions pricing and free call options. It does not indicate any destructive behavior.

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

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

The description is three sentences with key information front-loaded. It differentiates the tool, explains its function, and provides usage. Including pricing details adds length but may be useful. Overall efficient.

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

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

The description explains the verdict output (enforced/armed/no_seize_power) and that it reports who was seized and how much. However, without an output schema, the exact response structure is not detailed. Adequate for a relatively simple 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 baseline is 3. The description adds context: 'wallet' is victim wallet, 'address' is B20 token (omit for feed). However, these details are largely mirrored in the schema descriptions, so minimal additional value.

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 explicitly states it scans actual burnBlocked seizures, contrasting with other B20 tools that check what the issuer CAN do. This clearly identifies the tool's unique function and distinguishes it from siblings.

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

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

The description provides clear usage options: pass wallet= for a single address or omit address= for network-wide feed. It also mentions pricing and free calls, but does not explicitly state when not to use this tool.

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

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

With no annotations, the description carries the full behavioral burden. It warns that the currency code is the issuer's claim, not attested backing, which is critical. It also mentions pricing ($0.03 per call, prepaid free call limit) and that no wallet/API key is required, providing useful 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?

The description is four sentences with each sentence serving a purpose: first states what it does, second clarifies an important caveat, third lists required input, fourth provides pricing info. It is front-loaded and efficient with no wasted words.

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

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

Given one parameter and no output schema, the description covers the tool's purpose, caveats, and usage terms. While it could specify the return format or data structure, it provides sufficient context for an agent to know what to expect (peg, supply, cap, control powers).

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 one parameter 'address' described as 'B20 Stablecoin address'. The description adds no additional meaning beyond 'Required input: address', so it does not improve upon 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?

The description clearly states the tool aggregates declared peg currency, issuance profile, and control powers into a single call. It distinguishes itself from sibling tools like b20-peg and b20-control by offering a holistic 'what is this stablecoin and who controls it' summary, specifically for agents settling in B20 stablecoins.

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

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

The description implies when to use this tool: when an agent needs a comprehensive view of a stablecoin's peg, supply, and control in one call. While it does not explicitly state when not to use alternatives, the context is clear enough that an agent would understand this is for holistic assessments.

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

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

With no annotations, the description fully discloses behavior: reads on-chain data, costs $0.04 per call via x402, requires prepaid credit token header or offers free calls, and no wallet/API key needed. It also signals read-only nature (no mention of writes).

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 moderately concise, front-loading the main purpose before diving into pricing and complementary tools. A few sentences could be trimmed, but it remains efficient.

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 single parameter and no output schema, the description provides complete context: it explains the tool's purpose, how it works, pricing, access method, and relationships to sibling tools. Nothing essential 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 only parameter, address, is explained as 'B20 token address'. Schema coverage is 100% and the description adds context about what the address is used for and what data is retrieved. This adds value beyond the bare schema.

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

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

The description clearly identifies the tool's function: mint headroom & dilution history of a B20. It distinguishes from sibling tools by specifying it covers the dilution half of rug risk and references complementary tools b20-safety and b20-control.

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

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

The description advises pairing with b20-control to see who holds the mint role, providing context for when to use this tool. Though it does not explicitly state when not to use it, the guidance is clear and actionable.

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

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

No annotations provided, but description details how policies are resolved (sender, receiver, executor) and mentions live transfer-pause. Does not explicitly state non-destructive nature, but 'check' and 'get one GO/HOLD/STOP' imply read-only. Pricing and authentication are 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?

Description is front-loaded with the key question, then explains mechanism, differentiator, inputs, and pricing. Each sentence adds value, though slightly verbose for a simple check 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?

Covers purpose, usage, inputs, pricing, and access. No output schema needed; the return (GO/HOLD/STOP) is implied. Lacks explicit error handling or response structure, but sufficient for the tool's simplicity.

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

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

Schema coverage is 100% with adequate descriptions. Description adds minor context: executor policy enforcement, required inputs. Does not significantly enhance beyond 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?

Description clearly states it checks if a B20 transfer clears right now, distinguishes from sibling B20 tools that do per-token due diligence, and explicitly says no ERC-20 tool can replicate this.

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 tells when to use: 'the check an agent runs on every payment' vs other B20 tools that are 'per-token due diligence bought once'. Specifies required inputs and pricing model.

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

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

No annotations are present, so the description carries full burden. It discloses unmined block behavior, 'Raw chain data, no interpretation,' and detailed pricing/auth requirements ($0.002/call, x-credit-token header, free tier). This is exemplary.

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

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

Three sentences each carry distinct value: output fields, input/edge-case behavior, and cost/auth. No filler.

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

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

For a single-parameter tool with no output schema, the description covers purpose, inputs, edge cases, and access requirements, leaving no significant gaps for selection or invocation.

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

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

Schema already covers the only parameter at 100%. The description adds depth by specifying tag examples and the 0x… hash format, plus the not-yet-mined response, adding meaning beyond the schema's brief line.

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 immediately identifies this as a block data tool: 'Any Base block, by number, hash or tag — One block on Base' and lists distinct output fields (height, hash, parent, timestamp, etc.), clearly distinguishing it from sibling tools like base-tx or base-receipt.

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 tool operates on Base blocks and explicitly enumerates valid input types ('latest / finalized / safe / earliest') and edge-case behavior ('found:false'). However, it doesn't explicitly name alternative tools for when to use something else, though the resource scope 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?

With no annotations, the description takes full responsibility. It clearly states the tool is read-only ('read from the Base L2 Resolver'), discloses pricing ($0.01 per call, free tier), and authentication methods (x-credit-token header). No contradictions.

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 relatively concise, front-loading the core purpose. However, it mixes multiple pieces of information (cost, auth, free tier) in a somewhat scattered manner, which slightly reduces clarity.

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 lookup tool with one parameter and no output schema, the description covers purpose, input, cost, and auth. It does not explain output format, but the expected return (address or name) is implicit from the bidirectional resolution description.

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 'query' is described in the schema as 'Basename or address'. The description adds 'Required input: query' which is redundant. No additional meaning beyond the schema is provided.

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

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

The description clearly states the tool resolves Basenames to addresses and vice versa, using specific examples and naming the source (Base L2 Resolver). It distinguishes itself from sibling tools by specifying bidirectional resolution on the Base chain.

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

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

The description implies when to use (for name resolution) but lacks explicit guidance on when not to use or alternatives among siblings. It mentions required input and cost model but does not provide decision criteria relative to similar tools.

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

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

No annotations provided, so description carries full burden. It discloses it reads from Base's L2 Resolver text records, pricing ($0.02/call, credit header, 1 free call/day), and that no wallet or API key is needed. Does not mention rate limits or error handling, but provides sufficient behavioral context for a read-only tool.

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

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

The description is concise for the amount of information conveyed (purpose, input, output fields, pricing, prerequisites). It is front-loaded with the main purpose. Could be slightly tighter, but each sentence adds value.

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

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

Given no output schema and no annotations, the description provides a fairly complete picture: what it does, input, output fields, pricing, and relationship to other tools. Missing details on error handling or invalid inputs, but adequate for a simple read-only 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% with a single 'name' parameter described as 'Basename or address'. The description adds context by explaining what the parameter represents (address or Basename) and what will be resolved from it, enhancing the schema's basic description.

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

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

The description clearly states it resolves the complete Base identity (address, avatar, description, website, social handles) behind a Basename or address. It distinguishes itself from siblings like 'basename' (which likely resolves name to address only) and 'address-trust' (verification vs human context).

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

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

The description implies when to use: to get a full identity profile beyond just the name. It mentions complementing address-trust. However, it does not explicitly state when not to use or list alternatives beyond address-trust, but the context 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?

With no annotations provided, the description carries the burden. It discloses the output semantics (nonce, balance, contract flag), the counting ambiguity, pricing ($0.002/call), auth requirements (no wallet/API key needed), and usage limits (1 free call/day). It doesn't explicitly state it's read-only, but the nature of the data implies it. This is solid behavioral disclosure for a simple query tool.

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

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

The description is front-loaded with the key question and answer, then adds necessary clarifications, use cases, and pricing. It is longer than strictly necessary, but every sentence provides useful information (semantics, use case, input, cost, auth). The structure follows a logical flow: what → why → how.

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 or annotations, the description covers purpose, use cases, required input, pricing, and data semantics. The only gap is that it doesn't explicitly list the exact response field names or error behavior, but the mentioned outputs (nonce, balance, contract status) give sufficient operational understanding.

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 schema covers 100% of parameters but the address description is just 'Address' — generic. The description adds crucial context: it specifies the address is a Base address and clarifies what meaning the nonce has. This goes beyond the schema's basic field definition, so it earns 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?

The description explicitly states what the tool does: returns the next nonce, ETH balance, and contract status for a Base address. It even clarifies the semantic difference for wallets vs contracts, which distinguishes it clearly from sibling tools like base-tx or address-intel. The verb is implicit but the resource and action are unmistakable.

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

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

The description provides clear usage context: it's needed before building a transaction or to tell a fresh address from a used one. It also states the required input (address). However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of full exclusionary guidance.

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

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

With no annotations, the description fully discloses behavior: what fields are returned, how contract deployments differ, the pending/dropped/never-here edge case (and that it reports which instead of failing), pricing, auth requirements (no wallet/API key, optional x-credit-token header). This goes well beyond the schema and provides actionable behavioral details.

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 longer than the minimal example but well-structured with a summarizing hook, a detailed output list, edge-case explanation, and pricing/auth info. Each sentence adds value, though the opening rhetorical phrase could be trimmed without loss of substance.

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?

As a simple tool with no output schema, the description must convey return values and error behavior. It does so thoroughly, covering all receipt fields, the deployment case, the no-receipt meaning, and required inputs. For a 1-parameter tool, this is complete and self-sufficient.

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

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

The single parameter 'hash' is fully covered by the schema (100% coverage) with description 'Transaction hash'. The tool description repeats 'Required input: hash' but adds no extra format or semantic detail 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 clearly states the tool provides the 'receipt for a Base transaction' and enumerates exactly what it returns: success/reverted status, block, gas used, effective gas price, fee in wei/ETH, log count and emitting contracts, plus the deployed address for contract deployments. This specific verb+resource combination distinguishes it from siblings like base-tx or base-block.

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

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

The description gives clear context on how to interpret results ('No receipt yet means pending, dropped, or never here') and states the required input (hash) and pricing structure. However, it does not explicitly mention when to prefer this over sibling tools like base-tx or tx-decode, so it lacks alternatives/exclusions.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure and does so exceptionally. It explains edge-case behavior (null to for contract creation, null block for pending transactions, found:false for unknown hashes), pricing, authentication via x-credit-token header, and that no wallet/API key is required. This goes far beyond the structured schema.

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

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

The description is a single dense paragraph but front-loaded with the core purpose and followed by essential edge cases and access requirements. Every sentence adds value, though the pricing and header details could arguably be separated. Overall it is concise for the amount of critical context it conveys.

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 lack of an output schema, the description thoroughly explains the return fields and special values (null to, null block) as well as error semantics. It also covers access requirements (pricing, header, no credentials). This is complete for a single-parameter lookup tool, leaving little ambiguity about what the agent will receive and what it must provide.

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% (hash is described as 'Transaction hash'), so the baseline is 3. The description only reiterates that hash is required, adding no additional format or syntax details beyond the schema. It does not introduce constraints like hash length or encoding.

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

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

The description clearly identifies the tool as retrieving a raw, unedited Base transaction by hash, listing the specific fields returned (from, to, value, nonce, gas, etc.). It distinguishes itself from sibling tools by emphasizing 'exactly as the chain has it' and 'unedited', which separates it from decoded or explained transaction 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?

Usage context is implied: use when you need the raw transaction data as on-chain. It specifies required input (hash) and notes that unknown hashes return found:false rather than an error. However, it does not explicitly mention when to prefer this over similar tools (e.g., tx-decode or base-receipt), nor does it provide exclusion criteria.

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

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

No annotations provided, but description explains the decoding logic, rule changes (Beryl cut), and pricing. Missing explicit statement about read-only nature, but 'No wallet or API key required' adds transparency.

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?

Description is dense and well-structured, but slightly long with pricing details that could be shorter.

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

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

Covers input, processing logic, output (withdrawalHash, target, value, windows), and pricing. Missing explicit error handling or output format, but adequate for the tool's simplicity.

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

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

Schema has 100% coverage for 'tx' param, but description adds rich context about what the tool does with the hash (decode event, estimate windows) and its practical meaning.

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

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

The description precisely states the tool decodes the L2ToL1MessagePasser event from a Base withdrawal tx and estimates finalization windows under post-Beryl rules, clearly distinguishing it from siblings.

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 says 'For agents managing cross-chain liquidity' and specifies required input (tx). Includes pricing and authentication options but lacks explicit when-not-to-use or comparison to alternatives.

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

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

Since no annotations are provided, the description fully carries the burden. It discloses pricing ($0.08 per call), auth requirements (x-credit-token header for unlimited, 1 free call/day, no wallet/API key required), and behavior (scores, sorting). It does not cover error handling but is otherwise transparent.

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

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

The description is front-loaded with the main action and outputs, then provides use-case context and pricing. It is dense but every sentence adds value, with no unnecessary words. Slightly long but efficient.

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

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

Despite no output schema, the description explains return values (score, risk level, top signals, sorting) and input format. It covers pricing and auth. For a simple batch tool with one parameter, this is adequately 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% with one parameter 'addresses' described as 'Token addresses (comma-separated, up to 10)'. The description reaffirms this but adds no new meaning beyond the schema. Baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Rug-score up to 10 tokens in one call' and explicitly defines what it does (screening Base tokens, returns rug-probability score, risk level, top signals, sorted). It distinguishes from single-token tools by emphasizing batch efficiency and cost savings, and from sibling 'rug-score' through its batch nature.

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

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

The description provides clear usage context: 'Built for agents triaging a watchlist or portfolio without paying per token.' It mentions required input ('addresses'), pricing, and free tier. It does not explicitly state when not to use or name alternatives, but the use case is well-defined.

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

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

With no annotations, the description carries the full burden. It discloses important behavioral nuances: country-specific weekends, handling of national vs provincial holidays, and that skipped days are named. It also covers pricing and authentication requirements, going well beyond a simple 'add business days' statement.

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 longer than the ideal two-sentence example, but every sentence contributes information—core function, feature highlights, use cases, pricing, and requirements. The main purpose is front-loaded in the opening sentence.

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

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

Despite having no output schema, the description explains what the tool returns ('names every day it skipped' and 'they are listed separately' for provincial holidays). It covers all essential aspects for a date-calculator tool, including country coverage, weekdays, holidays, and access requirements.

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 schema covers 100% of parameters, so the baseline is 3. The description adds meaning by explaining the two operational modes: adding to a date vs counting between two dates, which clarifies how 'add' and 'to' relate. It also reinforces the required 'country' 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 clearly states the tool's function: 'Add business days to a date, or count them between two dates, for ~110 countries.' It uses specific verbs and distinguishes itself from siblings by focusing on country-specific business-day calculations, which no other sibling tool addresses.

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

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

It provides clear usage context: 'Built for payment terms, SLAs and delivery dates.' However, it does not explicitly mention when not to use it or name alternative tools, 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?

With no annotations, the description fully discloses behavioral traits: token shown once, balance lasts 180 days, tier bonuses, no wallet/API key required. It explains the credit-debit mechanism and pricing structure comprehensively.

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 well-structured with the key benefit front-loaded and details following. It is somewhat verbose but each sentence adds value. Could be slightly more concise but still effective.

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 complexity of a prepaid purchasing tool with tiers, token usage, and expiration, the description covers all necessary aspects. No output schema exists, but the description explains what the user gets (token, balance) adequately.

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 'tier' is described in the schema as 'Pack: 0.25, 1, 5 or 20 (USD)'. The tool description adds context about bonuses for higher tiers, adding value beyond the schema. Coverage is 100%.

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

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

The description clearly states the tool's purpose: buying a prepaid balance for using paid services without per-request settlement. It distinguishes itself from sibling tools which are all informational/analysis tools, as this is the only payment-related 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?

The description explicitly tells when to use: for agents making many calls per minute to avoid per-request settlement. It also provides alternatives: 1 free call per day per tool or $5.00 per call over x402, giving clear context for choosing this tool.

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

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

No annotations provided, so description carries full burden. It discloses all key behaviors: live snapshot, data fields, pricing ($0.01/call), header for unlimited calls, free tier, and no wallet/API key required. Could mention if it's destructive (it's read-only, implied but not explicit). However, for a read-only info tool, this is transparent enough.

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?

Description is front-loaded with purpose and outputs. Pricing and access details are added succinctly. Slightly more verbose than necessary but each sentence adds value (what, when, how to access).

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, but description fully enumerates returned fields (block, base fee, priority fee, ETH price, transfer cost). Also covers pricing and authentication. For a 0-parameter tool, this is complete and self-contained.

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?

Input schema has 0 parameters with 100% coverage (none). Description doesn't need to add parameter meaning. Baseline 4 applies since no parameters exist; description correctly omits param info.

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?

Description clearly states it provides live Base chain snapshot: latest block, base fee, priority fee, ETH price, and estimated transfer cost. Verb "snapshot" and resource "Base chain" are specific. With 100+ sibling tools, it distinguishes itself by focusing on real-time chain state, unlike many others that are token- or wallet-specific.

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 says "For agents timing or budgeting transactions" (when to use). Does not mention when not to use or alternatives, but given the broad sibling set, this guidance is sufficient. Pricing and access info also help with usage decisions.

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

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

No annotations provided, so description carries full burden. It implies read-only operation ('read merchants and agents need'), discloses pricing ($0.04 per call, 1 free/day), authentication (x-credit-token header, no wallet/API key), and protocol behavior (states like payer-RECLAIMABLE). Lacks output format details but is strong on safety and access.

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 main purpose and protocol detail. Slightly lengthy due to pricing and usage notes, but each sentence adds value. Could be trimmed slightly, but overall efficient.

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?

Provides rich context about the protocol, use case, and filtering. However, with no output schema, it fails to describe the return format or data structure, which is a gap for a reconciliation 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 baseline is 3. Description adds value by explaining filters (payment infoHash, payer, receiver, operator) and noting 'omit everything for the network feed,' going beyond schema 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?

Description clearly states the tool reconciles auth/capture payments on Base for the Commerce Payments protocol, listing specific states (escrow, captured, etc.). It distinguishes from siblings by focusing on two-phase payment reconciliation, a unique niche.

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 says merchants and agents need it before trusting onchain commerce, and describes filtering options (by payment, payer, receiver, operator) with the option to omit for a network feed. Does not explicitly contrast with sibling tools but provides clear 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 transparently discloses all behavioral traits: it reads on-chain data (90-day volumes, fees, etc.), outputs a verdict, and is a read operation with no destructive side effects. It also mentions pricing and header requirements. No annotations are provided, so the description carries full burden and handles it well.

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 concise, using a question to engage and then efficiently listing the audit details, verdicts, and pricing. It is front-loaded and every sentence adds value, though it could be slightly more structured with bullet points 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?

Given that there is no output schema, the description adequately covers the output by listing possible verdicts. It also explains the input and the data sources. It does not mention error handling or edge cases, but for a read-only audit tool, the information provided is sufficient for most scenarios.

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 'operator' is described in the schema as 'Operator address'. The description adds meaning by explaining what an operator is in the Commerce Payments context and reinforcing that it is required. This provides context beyond the schema's minimal description.

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

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

The tool's purpose is clearly stated: it audits a Commerce Payments operator to determine trustworthiness. The description explains the specific metrics it evaluates (volumes, fees, capture-vs-reclaim) and the verdict categories, and explicitly distinguishes itself from siblings by noting that no other tool reads the Base commerce protocol.

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

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

The description provides clear context for when to use the tool (when deciding whether to trust a Commerce Payments operator) and states the required input ('operator'). It lacks explicit guidance on when not to use it or mention of alternative tools among siblings, but the context is sufficient for most use cases.

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

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

No annotations exist, so the description carries full burden. It discloses the exact-match filtering behavior, tolerance for legal-form-only differences, fallback to candidates, required input, pricing per call, auth header option, free tier, and lack of wallet/key requirements. This is unusually transparent.

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

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

The description is dense but each sentence serves a purpose: the core function, the output fields, the matching nuance, the input requirement, and pricing/access. It is front-loaded with the essential question and avoids 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 only one parameter and no output schema, the description fully covers what the agent needs to know: what data will be returned, how results are filtered, what input is needed, and operational constraints like cost and auth. It is complete for safe and correct invocation.

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

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

The single parameter 'name' is already described in the schema as 'Company legal name', so schema coverage is 100%. The description adds value by clarifying that 'name' is required and explains how the name is used for matching (exact or legal-form tolerant), improving the agent's ability to provide correct 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?

The description opens with a specific question ('Does this company legally exist, and where?') and states the tool looks up companies in GLEIF, the global LEI register. It lists distinct output fields (LEI code, legal name, status, jurisdiction, address), clearly distinguishing it from sibling tools like address-intel or sanctions-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?

The description provides clear context: it is for legal entity existence and registration lookups, requires a company name, and explains pricing/access. It does not explicitly name alternatives or state when NOT to use it, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden. It discloses the combined screening behavior, output as a recommendation (blocked/review/clear), pricing ($0.03 per call), and authentication method (prepaid header or free daily call). It does not cover error handling or edge cases, but sufficiently describes what the tool does and does not destroy.

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 very concise: a single main sentence capturing the core purpose, followed by short supporting statements about compliance use, required input, and pricing. Essential information is front-loaded, and no sentences are wasted.

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

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

Given the single parameter, no output schema, and absent annotations, the description is mostly complete: it explains what the tool does, what input is needed, what output to expect (three verdict types), pricing, and authentication. However, it lacks details on the exact return structure (e.g., JSON format) and error behavior, which would be helpful 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?

The schema already describes the 'address' parameter with 100% coverage. The description adds context by stating 'Required input: address' and explaining that it is used for combined counterparty screening. This adds value beyond the schema by clarifying the purpose of the parameter within the tool's workflow.

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

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

The description clearly states the tool combines OFAC sanctions, EOA/contract profile, and risk flags into a single verdict (blocked/review/clear). This distinguishes it from sibling tools like 'sanctions' or 'rug-score' which provide only one aspect. The verb 'screening' and resource 'address' are explicitly mentioned.

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

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

The description implies usage for compliance agents and requires an address input, but does not explicitly state when to use this tool vs alternatives like separate sanctions or risk checks. No when-not-to-use or alternative tool names are provided, leaving the agent to infer usage context.

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

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

With no annotations, the description takes on full behavioral disclosure. It reveals the source (Sourcify), output format (function/event names lists + item count), match type (full or partial), authentication (no API key, prepaid header options), and pricing. This is thorough for an unannotated tool.

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

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

The description is three sentences long and front-loaded with the core purpose. It efficiently conveys verification check, ABI return, pricing, and authentication. Slightly verbose but effective and well-structured.

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

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

For a simple tool with one parameter and no output schema, the description covers the key aspects: verification source, return format, match type, pricing, and auth. It could mention what happens for unverified or invalid addresses, but overall it is fairly 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% with a single parameter 'address' described as 'Contract address'. The description adds 'Required input: address' which is already in schema. No additional semantic value 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 clearly states the tool checks if a Base contract is verified and returns its ABI as function/event name lists with count. The verb 'Get its ABI' and resource 'contract-abi' are specific, and no sibling tool appears to duplicate this exact functionality.

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

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

The description implicitly indicates when to use this tool (when needing an ABI), but it does not explicitly state when not to use it or mention any alternative tools among the many siblings. No guidance on exclusion criteria.

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

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

No annotations exist, so the description bears full burden. It discloses that the tool reads ABI (read operation), flags abuse functions, and details pricing, credit requirements, and network (Base). No destructive actions are implied.

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

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

The description is a single dense paragraph with multiple sentences. It is informative but lacks clear structure or sectioning. Some information (e.g., free calls) could be separated or reordered for clarity.

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

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

Given no output schema, the description does not explain the format or structure of the returned flags. It omits details about the response. For a simple one-parameter tool, it covers pricing and usage well but lacks output specifics.

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 schema already defines 'address' with minimal description. The description adds meaning by specifying that the address must be a verified contract and explaining how it is used to detect abuse functions.

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

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

The description clearly states that the tool reads a verified contract's ABI and flags owner-callable abuse functions like mint, pause, blacklist, etc. It specifies the required input (address) and distinguishes itself as providing diligence a price feed cannot give.

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?

While the description mentions required input and pricing, it does not explicitly guide when to use this tool versus alternatives among many sibling tools. There is no direct mention of when-not-to-use or specific alternatives.

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

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

With no annotations, the description carries the full behavioral burden. It discloses a key nuance: interface support is read from the contract's own declaration first and only inferred when absent, and the ordering matters because NFTs also answer totalSupply(). It also mentions network (Base), pricing, and authentication requirements. However, it does not explicitly state that the tool is read-only or describe potential error cases.

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 a clear question and explanation, then includes important detection ordering and pricing info. It is somewhat verbose (includes pricing and free-tier details), but each part serves a purpose. The structure is organized, making it easy to scan.

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 tool's moderate complexity and lack of an output schema, the description adequately covers what the tool returns (contract/wallet status, standard detection, metadata, code size) and the detection logic. It also notes network (Base), pricing, and no auth requirement. Missing details like exact output structure or error handling, but the description is sufficient for initial selection and invocation.

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

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

The schema has 100% coverage for the single 'address' parameter, describing it as 'Contract address'. The description merely repeats 'Required input: address' without adding further semantic meaning (e.g., format, examples, or constraints). Since schema coverage is high, a baseline of 3 is appropriate; no additional value is added.

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

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

The description clearly states what the tool does: it determines whether a Base address is a contract or a plain wallet, and if it is a contract, which token standard it follows (ERC-721, ERC-1155, or ERC-20 shape), including name, symbol, decimals, and code size. This specific verb+resource+scope distinguishes it from siblings like contract-abi and contract-danger.

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

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

The description does not explicitly state when to use this tool vs. alternatives. It provides no exclusions or recommendations about when to prefer contract-info over other contract-related tools such as contract-abi or token-info. The use case is implied (initial contract identification), but not articulated.

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

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

With no annotations, the description carries the full burden, and it delivers: it discloses data sources, output format, pricing, auth requirements (prepaid x-credit-token header), and that no wallet/API key is needed. It also explains the underlying fraud pattern. This is above-average transparency for a tool with no 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 paragraph but packs many details (purpose, sources, output, use case, pricing, auth) efficiently. Every sentence adds value, though the opening question is somewhat rhetorical and could be seen as slightly verbose for pure functionality.

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

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

The description covers the essential context: what checks are performed, how the result is presented, when to use it, and practical invocation details (cost, header, no wallet). It lacks mention of edge cases (e.g., missing optional inputs) but for a tool with no output schema, it provides enough to set expectations.

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

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

Schema coverage is 100%, so the parameter descriptions already define the fields. The tool description adds meaningful behavior beyond the schema, such as email's domain being used if domain is omitted and name enabling OFAC+LEI checks, which helps the agent synthesize inputs correctly.

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

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

The description clearly states what the tool does—aggregates four public sources (RDAP, DNS, OFAC, LEI) into a single GO/HOLD/STOP decision for supplier trust. It is specific about the resource (counterparty risk) and distinguishes itself from sibling tools by offering a composite check rather than a single-source lookup.

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

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

The description explicitly defines the intended scenario ('when an agent has to trust an invoice, a new vendor or a payment-detail change'), which is clear usage guidance. It does not mention when not to use it or name alternative tools, so it stops short of a full 5.

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

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

With no annotations, the description fully discloses the external call to 4byte.directory, Base network dependency, pricing ($0.01/call), free tier, and authentication requirements (prepaid header or free call).

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

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

The description is moderately concise with each sentence adding information, but the pricing and authentication details could be slightly more compact. The main purpose is front-loaded.

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

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

The description covers usage well but lacks details on the output format (e.g., a list of candidate signatures). Since no output schema exists, this gap slightly reduces completeness.

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 description adds value beyond the schema by explaining that the 'selector' parameter can be a bare 4-byte hex or full calldata, and provides an example ('0x70a08231').

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

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

The description clearly states it resolves a 4-byte function selector to human-readable signatures via 4byte.directory, distinguishing it from the sibling tool encode-selector which does the reverse.

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

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

The description specifies when to use the tool and the input format (selector or calldata), but lacks explicit comparison to alternative tools or conditions to avoid. Pricing and access details are provided.

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

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

With no annotations provided, the description carries the full burden. It details what the tool checks (contract risk, holder concentration, liquidity, etc.) and outputs (safety score, verdict). However, it does not disclose potential side effects, execution time, error handling, or whether it is read-only. The information is moderately transparent but missing some behavioral traits.

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

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

The description is verbose and includes marketing language ('premium flagship', 'value is the orchestration + AI synthesis you can't get anywhere else'), which reduces conciseness. Although it front-loads the purpose and provides structure, it contains unnecessary fluff that 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?

Given the tool's complexity (comprehensive report) and lack of output schema, the description explains the output contents (safety score, assessments) reasonably well. However, it omits practical details like expected response time, error conditions, and format. With many siblings, more context on when to use this tool would improve completeness.

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 descriptions for both parameters. The description adds context for 'size' (used for exit check) and confirms 'address' is for the token contract, but this largely mirrors the schema descriptions. Therefore, it provides adequate but not additional valuable 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 clearly states the tool produces an 'Institutional-grade full report on a Base token' covering multiple aspects like contract risk, holder concentration, liquidity depth, EXIT liquidity, and OFAC sanctions, and synthesizes an institutional verdict. It distinguishes itself from siblings by emphasizing its comprehensive, one-call nature and AI synthesis, which other tools may not offer.

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

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

The description mentions required input (address) and pricing but lacks explicit guidance on when to use this tool versus the many sibling tools. It does not compare alternatives or provide context for choosing deep-dd over similar tools like ai-token-report or token-risk.

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

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

No annotations are provided, so the description carries the full burden. It transparently explains the tool computes a score based on defined factors (wallet history, supply held, renounce status), mentions pricing and authentication requirements (x-credit-token header, free call), and states no wallet or API key is needed. It does not detail return format or error handling, but for a simple scoring tool this is adequate.

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 packed with useful information—purpose, scoring criteria, pricing, authentication—without being overly verbose. It could be slightly more concise (e.g., combine pricing sentences), but it remains front-loaded and every sentence adds value.

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 one required parameter, no output schema, and no annotations, the description covers the intended purpose, input, output (score range), special signals, pricing, and access method. It may lack specifics on the exact output format (e.g., JSON structure), but it provides enough context for an agent to select and invoke the tool correctly.

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

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

The sole parameter 'address' is described in the schema as 'Token contract address'. The description adds value by explaining what the tool does with that address (profiling creator wallet), going beyond the schema's single-line description. With 100% schema coverage, this extra context justifies a score above baseline 3.

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

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

The description clearly states the tool profiles the token's creator wallet and produces a reputation score (0-100) based on wallet history, supply held, and renounce status. It distinguishes itself from siblings by calling itself 'the forensics layer other checks skip' and directly addresses a common scam pattern ('classic rug setup').

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?

While the description specifies the required input (address) and pricing/access details, it does not explicitly state when to use this tool over sibling tools like 'rug-score' or 'holder-forensics'. The contrast with 'other checks' implies a complementary use case, but explicit guidance on when not to use it or which tool to use instead is missing.

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?

Despite no annotations, the description comprehensively discloses behavior: it returns specific data fields, pricing per call, and refusal policy. It also notes the source protocol (RDAP) and provides a use case, fully informing the agent.

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

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

The description is front-loaded with a clear question and provides all necessary details in a logical order. While it is somewhat lengthy, every sentence adds value, and the structure is effective.

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 input schema and lack of output schema, the description fully explains expected outputs, pricing, and behavior. It is complete for the tool's complexity and provides all needed context.

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

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

Schema coverage is 100% with a single domain parameter, and the description adds no additional semantic detail beyond the schema's 'Domain name'. Baseline score of 3 is appropriate.

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

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

The description clearly states that the tool checks domain age, registration, expiry, and registry status. It uses a specific verb-resource pairing and distinguishes from sibling tools like url-extract by focusing on domain metadata retrieval via RDAP.

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

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

The description explains when to use the tool (for fraud detection signals) and what it refuses (when no RDAP data is available). However, it does not explicitly mention alternatives or when not to use it, but the context makes it clear.

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