anchor-x402

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

Annotations indicate readOnlyHint=false and openWorldHint=true, so the description's on-chain write behavior is consistent. It adds value beyond annotations by disclosing the $0.005 USDC cost, the parallel Base+Solana execution, and the return of transaction URLs.

Agents need to know what a tool does to the 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 exactly two sentences, front-loading the core action and then adding output verification and cost. No wasted words; every element serves a 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?

The description covers the tool's purpose, key behavior, output (tx URLs), and cost, which is sufficient given the absence of an output schema and the presence of full schema parameter documentation. It could be more explicit about response shape, but the essential context is present.

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

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

All three parameters are already fully described in the schema with 100% coverage, including constraints like mutual exclusivity, canonicalization, and maxLength. The description only adds '32-byte hash' context, which does not significantly extend 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 uses a specific verb ('Anchor') with a clear resource ('32-byte hash') and destinations ('Base + Solana mainnet'). It also states the output ('tx URLs as cryptographic proof'), which clearly distinguishes this from sibling tools like decode_tx or resolve_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 makes the use case clear: proving when a hash existed via on-chain anchor. It does not name alternative tools or provide explicit when-not-to-use guidance, but the context is enough for an agent to understand when this tool is appropriate.

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

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

Annotations only indicate non-readOnly and openWorld hint. The description adds valuable behavioral context: the operation costs $0.010 USDC, produces on-chain proof URLs, and includes a free re-verify URL. It also discloses the dual-chain anchoring, which implies permanent on-chain record creation.

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

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

The description is two sentences that efficiently pack the core action, two signing modes, return values, and price. Every phrase carries information, with no redundancy or 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?

With 6 parameters and no output schema, the description covers the essential workflow and outcomes: what is attested, how to sign, what is returned, and the cost. It omits some edge-case details like required signer_pubkey for ed25519, but the schema covers that. Overall, sufficient for an agent to 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?

The schema descriptions cover all parameters completely, so the baseline is 3. The description reinforces the three hashes and the signature omission behavior, but does not add significant meaning beyond what the schema already provides.

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

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

The description clearly states the tool's purpose: attesting a decision over (input_hash, output_hash, decision) with optional self-signing or treasury signing, followed by dual-chain anchoring. It distinguishes itself from the sibling 'anchor_hash' by focusing on decisions and explicit signing options.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 operational guidance: sign it yourself or omit the signature for treasury signing, and explains the return values and cost. However, it does not explicitly reference alternative tools or when-not-to-use scenarios, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds meaningful context by disclosing the $0.01 USDC cost and specifying the output structure. This goes beyond what annotations alone reveal, though it does not cover rate limits or edge-case 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 a single sentence that front-loads the primary action and output fields, followed by a cost note. Every word adds value with no redundancy or 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 low-complexity tool with one parameter and no output schema, the description conveys the tool's purpose, expected output fields, and cost. It is sufficiently complete for an agent to understand 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?

Schema description coverage is 100% for the single 'target' parameter, which already states 'Anything to read the aura of.' The description echoes the same idea without adding new parameter-level nuance, so it receives the baseline score.

Input schemas describe structure but not intent. Descriptions should explain 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: read the aura of any target, and explicitly lists the output dimensions (color, tier, score, description). This specific verb+resource combination distinguishes it from siblings like grade_target or roast_target.

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

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

The description gives a clear general use case ('Read the aura of anything') but does not explicitly discuss when to choose this tool over alternatives, nor does it mention any exclusions or preconditions. It implies broad applicability but lacks explicit guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable context beyond annotations: the use of external services (openchain.xyz, eth_abi), a cost of $0.001 USDC, and EVM-only limitation. It doesn't mention error handling or rate limits, but the added context is meaningful 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 one concise sentence followed by two short fragments. It is front-loaded with the primary action, then includes scope and cost. Every word adds value; there is 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?

For a simple read-only tool with rich annotations and schema, the description covers the key points: what it does, external dependencies, cost, and output shape ('function name + typed parameters'). It doesn't describe failure modes, but the schema already captures the main error (solana 400). The description is sufficiently complete 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%, with each parameter clearly documented (chain enum with solana returning 400, calldata_hex with prefix details, contract_address as optional/unused). The description adds no extra parameter-level information; baseline 3 is appropriate given the high 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?

The description states a specific verb ('Decode'), resource ('raw EVM calldata'), and output ('function name + typed parameters'). It clearly distinguishes from sibling tools like decode_tx by focusing on calldata rather than full transactions, and explicitly notes EVM-only scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 (when you have raw calldata) and gives a constraint (EVM-only), but it does not explicitly mention when to avoid this tool or name alternatives such as decode_tx. No clear when-to-use vs when-not-to-use guidance is 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?

Annotations provide readOnlyHint and openWorldHint, but description adds useful behavioral context: mined transactions are cached, and there is a cost of $0.001 USDC. This goes beyond annotations by disclosing performance expectation and cost, which is critical for an agent. No contradictions with 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?

Three short, information-dense sentences. Front-loaded with the core function, followed by supported chains, caching, and cost. No redundant language or 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?

For a simple two-parameter tool with annotations and no output schema, the description provides adequate context: mainnet scope, chain options, caching behavior, and cost. It doesn't describe return structure, but 'structured decode' implies a schema, and the simplicity reduces the need for more. Slight gap in explaining 'mined txs' meaning confirmed transactions, but not critical.

Complex tools with many parameters or behaviors need more documentation. 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 0%, but description compensates by explicitly mentioning 'by hash' for tx_hash and 'Supports Base, Ethereum, Solana' for chain, mapping directly to the enum values. It also adds that the hash is for a mainnet transaction. While it doesn't detail hash format, the basic semantics are clear and align with 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?

Clearly states it performs a 'structured decode of any mainnet transaction by hash', with explicit supported chains (Base, Ethereum, Solana). This distinguishes it from siblings like decode_calldata, which likely focuses on calldata only. The verb 'decode' and resource 'transaction' are specific and unambiguous.

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

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

Implies usage: any mainnet transaction by hash, and lists supported chains. However, it does not explicitly state when to prefer this over decode_calldata or other alternatives, nor does it mention exclusions (e.g., testnets). The mention of 'mainnet' and supported chains provides context, but lacks explicit 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 readOnlyHint and openWorldHint already provided, the description adds valuable behavioral details: cost ($0.01 USDC) and output style (red-pen marginalia). It does not detail the exact return structure, but for a read-only tool this is acceptable.

Agents need to know what a tool does to the 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 concise sentence that packs purpose, output format, and cost without fluff. It is well-front-loaded and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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, read-only annotations), the description is largely complete. It explains what it does and the cost, though it could mention the return type explicitly.

Complex tools with many parameters or behaviors need more documentation. 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 fully describes the target parameter as 'Anything to grade.' The description adds no new parameter semantics beyond this, so it earns the baseline score.

Input schemas describe structure but not intent. Descriptions should explain 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 an academic letter grade with red-pen marginalia for any input. It specifies the output format and scope, distinguishing it from sibling tools like roast_target (which likely provides humorous roasts) and tldr_text (which summarizes).

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

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

No explicit guidance is given on when to use this tool versus alternatives. The description implies it can grade anything but does not mention any exclusions or contexts where another tool should be preferred.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description correctly aligns with those. It adds useful behavioral context beyond annotations by disclosing the cost ($0.005 USDC) and the fact that it aggregates 8-10 parallel sources, which helps an agent anticipate side effects and performance. It does not detail error handling or response schema, but the listed output contents provide a reasonable picture.

Agents need to know what a tool does to the 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 exceptionally concise, consisting of two terse sentences. The first sentence establishes the tool's purpose, and the second enumerates the data points and cost. Every phrase earns its place, with no filler or redundancy, making it easy for an agent to parse quickly.

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

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

With one parameter, no output schema, and supportive annotations, the description covers the essential aspects: what the tool does, what data it returns, the cost, and the number of sources. It is sufficiently complete for a read-only bundle tool, though it omits potential error conditions or response format details, which are not critical given the simple profile.

Complex tools with many parameters or behaviors need more documentation. 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 fully documents the 'wallet' parameter with a clear description ('EVM 0x… address (40 hex) or Solana base58 pubkey'), giving 100% schema description coverage. The tool description itself adds no additional parameter-level meaning, so the 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 function as a 'Unified wallet intelligence bundle' and enumerates the exact data it returns: balances across Base, Ethereum, and Solana, USDC, tx counts, ENS/SNS reverse lookups, and a sanctions verdict. This specific verb-like framing ('ONE call' + list of outputs) distinguishes it from sibling tools like investigate_wallet or screen_wallet by positioning it as an aggregated one-shot intelligence bundle.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 'ONE call' phrase implies the tool is meant for a comprehensive wallet intelligence lookup in a single request, which provides clear context. However, it does not explicitly state when to use this over alternatives (e.g., investigate_wallet) or when not to use it, so guidance is implied rather than explicit.

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

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

The description goes beyond the minimal annotations (readOnlyHint=false, openWorldHint=true) by disclosing async behavior (returns job_id, poll endpoint), ETA, cost, and deliverable format. This adds valuable operational context, though it does not detail the investigation steps or potential side effects.

Agents need to know what a tool does to the 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 and front-loaded, conveying purpose, deliverable, async flow, and cost in two sentences. Every sentence earns its place with essential information and no 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?

It provides the key operational context (async, polling, cost, deliverable) but given the tool's complexity and no output schema, it could explain more about the report contents or error handling. The current level is adequate but not 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% for the single address parameter, which already explains the EVM or Solana formats. The description aligns with this but adds no new parameter semantics, so the 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 'Agent-driven wallet due diligence' and describes a 'multi-step investigation' producing a 'signed markdown report + JSON sidecar'. It distinguishes itself from sibling tools like screen_wallet or intel_wallet by highlighting its async, report-generating nature and dual-chain support.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 usage is implied as a due-diligence tool, but there is no explicit guidance on when to use it over alternatives like intel_wallet or screen_wallet, nor any when-not-to-use conditions. It provides context but lacks clear exclusions.

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

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

Annotations provide readOnlyHint=false and openWorldHint=true. The description clarifies cost ($0.35) and behavior (async, markdown+CSV), but does not disclose return format, auth/rate-limit, side effects, or mutation. No contradiction with annotations.

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

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

One dense opening sentence conveys purpose, format, cost, and execution model, then schema follows. Not excessively long but could add grouping.

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

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

10 parameters and async job inherent, but no output schema and no narrative for what the retuned file/markdown contains; sibling tools provide some 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?

Input-schema coverage is 90% and description adds semantics (EVM address for wallet, default date semantics, group_by enum, min_amount, optional) over raw schema. A few params (prepared_for) only lightly described but overall strong.

Input schemas describe structure but not intent. Descriptions should explain 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 states a specific verb+resource: 'Signed + dual-chain-anchored x402 expense report (markdown + CSV, async). $0.35 USDC.' It clearly reports an expense report with format and cost. However, it doesn't explicitly distinguish from sibling 'ledger_summary' beyond saying expense report.

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

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

Title implies x402 expense report; includes cost and async context. But no explicit when-to-use or when-not-to-use guidance, nor named 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?

Annotations already mark it read-only and open-world. The description adds useful behavioral context by noting data is 'reconstructed from chain data' and that a $0.01 USDC cost applies, which is not present in annotations. No contradictions with the annotations.

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

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

The description is a single, front-loaded sentence that conveys the core purpose and a key cost detail with no extraneous words. It is concise and well-structured, earning full marks.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 7 parameters and no output schema, the description is under-specified for a tool of this complexity. It doesn't mention date range handling, grouping options, direction filtering, or the return structure beyond 'totals + per-service breakdown.' More context is needed for correct invocation in varied 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?

Schema description coverage is high at 86%, so the schema already explains most parameters. The description only loosely implies grouping via 'per-service breakdown' and doesn't add meaning to specific parameters like wallet, date range, or direction. 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 provides x402 spend accounting with totals and per-service breakdown for any Base wallet, clearly identifying the resource and function. However, it doesn't explicitly differentiate from the sibling ledger_report, so it stops short of a 5.

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

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

The description gives no guidance on when to use this tool versus alternatives like ledger_report or investigate_wallet. There are no explicit use cases, exclusions, or references to sibling tools, leaving the agent to infer usage from the purpose alone.

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

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

With annotations indicating readOnlyHint=false and openWorldHint=true, the description adds value by explaining the dual-chain anchoring and cost, which have practical implications. It does not, however, clarify the exact output format or whether the anchoring is a permanent on-chain write, leaving some behavioral ambiguity.

Agents need to know what a tool does to the 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 at two short sentences, with the primary purpose front-loaded. Every phrase—'yes/no', 'dual-chain anchored', 'Base + Solana', and '$0.05 USDC'—adds useful information without 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 tool's low complexity and complete parameter schema, the description covers the essential purpose and cost. However, the absence of an output schema means the description should ideally clarify the verdict format and how results are returned, which it does only implicitly. The dual-chain anchoring could also warrant a note about latency or determinism, but is not enough for a higher score.

Complex tools with many parameters or behaviors need more documentation. 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 fully documents the single 'question' parameter with a clear description, so the baseline is 3. The tool description adds no additional semantics about parameter formatting, constraints, or edge cases beyond the schema's min/max length.

Input schemas describe structure but not intent. Descriptions should explain 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 a yes/no oracle and adds distinguishing detail with 'dual-chain anchored verdict (Base + Solana)' and pricing. While it lacks an explicit verb like 'returns' or 'answers', the noun phrase effectively communicates the tool's function. This distinguishes it from sibling tools such as attest_decision or roll_random.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 yes/no questions and discloses the $0.05 USDC cost, giving some context for when to invoke it. However, it provides no explicit comparison to sibling tools or any guidance on when not to use it, such as for non-binary or attested 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds value by disclosing the output envelope (ISO 8601, components, relative time, confidence) and the cost ($0.001 USDC), which are not captured elsewhere.

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

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

The description is a single, information-dense sentence followed by a price note. Every word contributes meaning, and the key action is front-loaded. No unnecessary repetition or filler.

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

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

For a simple parsing tool with 3 parameters, 100% schema coverage, and strong annotations, the description provides sufficient context. It even compensates for the absence of an output schema by listing the output components and includes the cost, making it complete for an agent to 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 description coverage is 100%, with each parameter (input, timezone, base_time) already documented in the schema. The description does not add parameter-specific details beyond the general 'freeform datetime strings,' so it meets the baseline without 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?

The description clearly states the tool's function with a specific verb ('Parse') and resource ('freeform datetime strings'), and lists concrete outputs (ISO 8601, components, relative time, confidence). This distinguishes it from all sibling tools, which are crypto/blockchain related.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 the tool (for parsing freeform datetime strings). It does not explicitly mention alternatives or exclusions, but given the sibling list contains no similar date-related tools, the intended usage is unambiguous.

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

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

Annotations indicate readOnlyHint and openWorldHint, already communicating safety. The description adds useful behavioral context: a 1-hour cache and a cost of $0.001 USDC, which are not in the schema. This helps the agent understand performance and pricing implications without contradicting 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 two short sentences, front-loaded with the core purpose. It includes cache and cost without being verbose. Every clause adds value, making it an exemplary compact description.

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

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

For a simple one-parameter, read-only tool with no output schema, the description is complete: it states what it resolves, the supported protocols, return type, cache behavior, and cost. Combined with annotations, an agent has full context to invoke it correctly. No critical information 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 input schema covers the lone 'name' parameter with an example and supported domains (100% coverage). The description's mention of ENS and SNS reinforces this but does not add new parameter-level details beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description states 'Cross-chain name resolution' with explicit support for ENS (.eth) and Bonfida SNS (.sol), and clarifies it 'Returns resolved address(es)'. This clearly identifies the tool's function as resolving human-readable names to addresses, distinguishing it from sibling tools that decode calldata or transactions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 offers clear context: use for resolving .eth and .sol names. It does not explicitly name alternatives or exclusions, but the scope (ENS/SNS) implicitly defines when to use the tool. This is clear enough for an agent to select it for name resolution tasks.

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

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

While annotations declare readOnlyHint and openWorldHint, the description adds important behavioral context: the tool charges $0.05 USDC, which is a significant side effect not covered by annotations. It also sets expectations for a 'witty' tone. This goes beyond what annotations already provide.

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

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

The description is a single, highly concise sentence that captures scope, tone, and cost with no wasted words. It front-loads the core action ('Witty roast') followed by examples and pricing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 one parameter and no output schema, the description sufficiently covers what the tool does and its cost. It does not explain response format, but for a simple roast generator this is less critical. The examples provide enough context for an agent to decide when to invoke it.

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

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

Schema coverage is 100% with the target parameter described as 'Anything to roast: wallet, tweet, idea, code, etc.' The description reinforces this by listing examples, but it does not add new semantic detail beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description explicitly states the tool performs a 'witty roast of any target' and lists concrete examples (wallet, tweet, idea, code). This clearly distinguishes it from siblings like grade_target or screen_wallet by emphasizing humor/roasting rather than evaluation or screening.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 by saying 'any target' and gives examples, but it does not explicitly state when not to use this tool or mention alternatives. Context from sibling names (e.g., grade_target) suggests alternatives, but no direct comparison is 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?

Annotations already indicate non-read-only behavior (readOnlyHint: false) and open-world effects. The description adds context about the signed payload and the cost per call, which goes beyond the annotations. However, it does not fully explain the payment flow or side effects in detail.

Agents need to know what a tool does to the 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: two sentences that front-load the core purpose, then add use case and cost. Every word earns its place with no waste.

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

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

Given that there is no output schema, the description partially explains the return value ('cryptographically-random integer(s) signed by the treasury key'). It also mentions the cost, which is critical for a paid tool. However, it lacks a detailed explanation of the response format or the commitment/label semantics, though the schema covers those.

Complex tools with many parameters or behaviors need more documentation. 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 provides 100% coverage for all five parameters with descriptions. The tool description adds no additional parameter semantics beyond mentioning 'integer(s)', which is already covered by the count parameter. This meets the baseline for high 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?

The description clearly states this tool generates cryptographically-random integers signed by the treasury key, using the phrase 'Verifiable RNG'. It distinguishes itself from sibling tools by explicitly targeting game studios and providing a VRF-like function, which no other sibling does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 tells you when to use it ('Drop-in VRF for game studios') and implies a paid service ($0.001 USDC), but it does not explicitly mention when not to use it or compare with alternative tools. This is a minor gap.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, providing baseline safety. The description adds useful behavioral details: the $0.02 USDC cost, the resolution to allow/review/block, and the per-signal detail in output. This goes beyond what annotations convey, though it doesn't describe all possible 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?

Two concise sentences deliver all key information: purpose, specific signals, output format, and cost. No filler or redundancy. Front-loaded with the main verb and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 sufficiently explains inputs, processing, outputs, and cost. It provides a complete picture for an agent to decide when to invoke this tool.

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

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

The schema covers 100% of the parameter with a clear description (EVM address or Solana pubkey). The tool description does not add extra syntax or format details beyond the schema. Baseline 3 is appropriate since schema does the heavy lifting.

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

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

The description clearly states the tool's function: a risk pre-flight for agent payments combining OFAC SDN sanctions and address reputation, yielding an allow/review/block recommendation. This specific verb+resource+output distinguishes it from sibling tools like intel_wallet and investigate_wallet, which likely provide broader or deeper 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 phrase 'pre-flight for agent payments' clearly indicates when to use the tool (before making payments). It does not explicitly mention alternatives or when not to use it, but the context is clear enough. A 4 is appropriate because it gives a clear use case without exclusions.

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

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

The description discloses the output format (3-5 bullets) and the cost, adding value beyond the readOnlyHint annotation. It does not mention failure modes or edge cases (e.g., if both url and text are provided), but given the read-only nature, the transparency 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 concise, consisting of two short sentences. It conveys all necessary information without fluff or unnecessary detail.

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

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

The description is complete for its purpose: it explains the input (URL or text), the action (summarize), and the output (3-5 bullets). It could mention potential errors or the requirement of at least one input, but these are implied by the parameter descriptions.

Complex tools with many parameters or behaviors need more documentation. 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% since both parameters have descriptions ('URL to fetch and summarize...' and 'Pasted text to summarize...'). The tool-level description adds no extra parameter semantics, so the 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 function: summarizing a URL or pasted text into 3-5 concise bullets. It distinguishes itself from sibling tools like token_price or screen_wallet by indicating a summarization action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 specifies when to use the tool (when summarizing a URL or text) and mentions a cost consideration ($0.01 USDC), which helps with decision-making. However, it does not explicitly state when not to use it or alternative tools that might be more appropriate.

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

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

The description adds significant behavioral context beyond the readOnlyHint annotation: data source (CoinGecko), caching behavior (60s cache), cost ($0.001 USDC), and the coverage limitation (major tokens). This helps the agent understand performance, reliability, and cost implications without needing structured fields.

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

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

The description is four short, imperative sentences with the main purpose front-loaded. Every sentence adds value: scope, input modes, data source, and cost. There is zero waste.

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

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

For a simple read-only price lookup, the description covers the essential aspects: inputs, scope, cost, and data source. It does not explicitly describe the return format, but 'USD spot price' implies a numeric price. Given the lack of an output schema, a bit more detail on the response shape would make it complete, but it is adequate.

Complex tools with many parameters or behaviors need more documentation. 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 provides descriptions for all three parameters (100% coverage), and the symbol description already states mutual exclusivity with chain+contract. The description repeats this by saying 'By symbol or chain+contract' without adding new semantic details beyond the schema.

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

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

The description clearly states the tool provides USD spot price for major tokens, specifying input methods (symbol or chain+contract). It is distinct from sibling tools, none of which are price-related. The purpose is immediately evident from the first sentence.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 context: for fetching current spot prices, limited to major tokens. It does not explicitly name alternatives, but no sibling tools offer similar functionality, so the absence is acceptable. The 'major token' scope and two input modes provide clear usage guidance.

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