base-onchain-tools

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 costs ($0.002 per call), payment method (USDC over x402), and the fact that it returns payment requirements. It also explains failed calls are never billed762. This is strong behavioral disclosure beyond what structured fields would 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 concise, with the purpose front-loaded in the first clause. It uses a few sentences and includes essential details without 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 single-parameter tool, the description covers purpose, cost, billing, and output (payment requirements). It's complete enough for an agent to understand when and how to invoke it, and what to expect. No output schema, but it mentions the key output.

Complex tools with many parameters or behaviors need more documentation. 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 one parameter 'address' with 100% description coverage (0x-prefixed address). The tool description also mentions 'Base mainnet address', but adds little beyond the schema. Baseline 3 is appropriate; schema already covers parameter meaning.

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

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

The description clearly states the tool's purpose: 'Pre-flight check on a Base mainnet address before you pay it' and enumerates specific checks (contract vs EOA, balances, tx count, warnings). This is a specific verb+resource with concrete scope, distinguishing it from siblings like base_contract_type or base_balance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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: 'before you pay it' – a clear usage context. It also mentions costs and payment requirements. However, it does not explicitly contrast with sibling tools like base_tx_check or base_portfolio, so it's missing explicit 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?

The description discloses cost ($0.001 per call), payment method (USDC over x402), and that failed calls are not billed. It also indicates the information returned (allowance, unlimited status, balance). It does not explicitly state read-only behavior, but the nature of the tool implies no 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 but informative, covering purpose, defaults, cost, and return behavior in three sentences. It avoids redundancy and is well-structured, making it 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 that no output schema is provided, the description adequately explains what the tool returns (allowance details, owner balance, spendable amount, and payment requirements). It is complete enough for typical usage, though it does not specify the exact return format or structure.

Complex tools with many parameters or behaviors need more documentation. 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 (owner, spender, token) with clear definitions. The tool description adds context like default to USDC and cost, but does not significantly enhance parameter meaning beyond the schema, which already has 100% 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 the tool's function: checking ERC-20 allowance on Base, including details on spender limits, unlimited approvals, owner balance, and spendable amount. It is specific and distinct from sibling tools like base_balance or base_transfer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 what the tool does but does not explicitly compare it to alternatives or state when to use it versus other tools. However, given the specific functionality, usage is implicitly clear, but explicit guidance is lacking.

Agents often have multiple tools that could apply. Explicit usage 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 the disassembly approach (PUSH-aware walk), metadata stripping, signature database, proxy following, and the $0.04 cost with no billing for failed calls. It also notes that failed calls are never billed, which is important behavioral context. It does not mention rate limits or auth, but the cost and failure behavior are well covered.

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

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

The description is a single dense paragraph that is information-rich but somewhat long. It front-loads the core purpose and then details capabilities and costs. Every sentence adds value, but the length could be slightly trimmed without losing meaning. Still, it is 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 the tool's complexity (bytecode analysis, proxy following, cost model) and the lack of annotations and output schema, the description is quite complete. It covers what the tool does, how it works, what it reports, and the payment requirement. It could mention the return format or any limitations, but the description is sufficient for an agent to decide 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 description coverage is 100%, so the schema already documents both parameters. The description adds context for 'follow_proxy' by explaining the default true behavior and why proxy following matters, which is useful. However, it does not add syntax or format details beyond the schema, so a 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: auditing an unverified Base contract by disassembling bytecode, recovering function selectors, and reporting admin powers, dangerous opcodes, token standards, and EIP-3009 support. It distinguishes itself from sibling tools like base_contract_type and base_tx_check by focusing on unverified contracts and deep bytecode 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 implies when to use this tool: when a contract is unverified and block explorers show nothing. It also explains the proxy-following behavior and the cost/payment model. However, it does not explicitly state when NOT to use it (e.g., for verified contracts) or mention alternatives among siblings, though the context is clear enough.

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

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

With no annotations provided, the description carries the full behavioral burden and does well by disclosing the call cost in USDC, the x402 payment mechanism, that the call returns payment requirements, and that failed calls are never billed. It is a clearly read-identify operation, though it could more literally state that 'no mutations are performed.'

Agents need to know what a tool does to the 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 compact and front-loaded: it leads with the core purpose and the proxy detection details, then quickly covers cost and payment. The phrase 'Calling this tool returns the payment requirements' is slightly redundant and arguably ambiguous, but the description remains concise 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 one-parameter tool with no output schema, the description shows enough context: detection method, exact proxy standards, cost and payment details, and no-billing-on-failure guarantee. An explicit mention of the final output shape would make it fully complete, but it is not strictly required here.

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

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

The schema has one address parameter with 100% coverage ('Contract address on Base mainnet'), so parameter semantics are already supplied by the schema. The description adds no substantive formatting details or constraints beyond what the schema defines, so the default 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 begins with a specific action—'Identify what a Base contract actually is'—and enumerates concrete detection targets: ERC-20, ERC-721, ERC-1155 via ERC-165, plus proxy detection across EIP-1967, EIP-1822, and the legacy ZeppelinOS slot. This fully distinguishes it from sibling tools like base_contract_audit or base_token.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 tool's intended use case is implied through its purpose—classifying a Base contract and detecting proxies—but it does not explicitly state when to use this tool versus alternatives. No exclusions or 'use X instead' guidance is present, so context is only inferred.

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

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

With no annotations, the description must disclose behavioral traits. It notes the tool is 'Free' and returns a live audit, but does not explicitly state side effects (e.g., read-only), authentication needs, or rate limits. The 'Free' hint is useful but incomplete for full behavioral 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 a compact two sentences: it leads with 'Free,' states the action, and gives a direct call-to-action. Every word earns its place; no fluff or repetition.

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

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

For a tool with no parameters and no output schema, the description fully covers what it does, how it compares to the paid tool, and when to use it. The context is complete for an agent to decide 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?

The tool has zero parameters, so schema coverage is 100% by default. Per rubric, zero-parameter tools get a baseline of 4. The description reinforces that no address is needed since it's fixed, which adds a semantic clarification.

Input schemas describe structure but not intent. Descriptions should explain 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 returns a complete, live contract audit of Base USDC, with a fixed address. It explicitly distinguishes from the paid audit tool by noting the same output shape but with a fixed address, making it unambiguous which task it handles.

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

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

It provides explicit usage guidance: 'Call this first to see what the paid tools return before spending anything.' This tells the agent exactly when to use this tool (as a free preliminary check) and implies an alternative (the paid audit 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 burden. It discloses cost ($0.001 per call), payment method (USDC over x402), that failed calls are never billed, and that calling returns payment requirements. This is thorough and sets accurate expectations for a paid oracle 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?

Two sentences, front-loaded with the tool's purpose, then specific data points, then cost and billing details. Every sentence adds value without redundancy. Perfectly sized for a stateless oracle 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?

The description covers return content, cost, billing, and failure behavior. With no output schema and no annotations, this is complete for an agent to understand what to expect and how to handle the tool. No missing critical 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?

There are zero parameters, so schema coverage is vacuously 100%. The description goes beyond the schema by explaining what the tool returns (gas components and cost estimate), which is valuable for an agent deciding whether to call it and how to interpret the response.

Input schemas describe structure but not intent. Descriptions should explain 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 verb and resource: 'Live Base mainnet gas oracle', then enumerates the exact data returned (current gas price, base fee, trend, priority fee percentiles, transfer cost). This clearly distinguishes it from sibling tools like base_price or base_token_price, which deal with asset prices, not gas metrics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 it doesn't explicitly state 'use this when you need gas data', the description implies its purpose and differentiates it from siblings by content. It also mentions payment requirements and failed-call billing, giving implicit context for when to call (when gas info needed) and what to expect. Could be improved by explicitly stating 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 provided, the description carries the full burden. It discloses the cost per call, the payment method (USDC over x402), and that failed calls are never billed. It also notes that calling the tool returns payment requirements, which is a behavioral detail. While it doesn't describe side effects beyond billing, these are the most relevant risks for a read-only portfolio query, so it is adequately 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 concise and front-loaded: the main purpose is stated in the first sentence, followed by efficiency and billing details. Every sentence adds value—purpose, benefit, cost, and payment behavior—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?

Given the tool's simplicity (one parameter, no output schema, no nested objects), the description is complete. It covers the purpose, input constraints, output indication (balances and funded flags), cost, payment method, and failure behavior. There are no obvious gaps that an agent would need to guess.

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

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

The input schema already fully documents the single parameter (addresses) with a description of comma-separated Base addresses and a max of 20. The tool description reiterates the limit but adds no new semantic meaning about the parameter format or usage beyond what the schema provides. Since schema coverage is 100%, the baseline of 3 is appropriate.

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

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

The description clearly states the function: retrieving ETH and USDC balances for multiple Base addresses in one call, including per-address funded flags and totals. It specifies the resource (Base addresses), the action (fetch balances), and the scope (up to 20 addresses), distinguishing it from sibling tools like single-address checks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 it—when you need balances for multiple addresses efficiently—by highlighting 'one request instead of forty RPC round trips.' However, it does not explicitly mention when not to use it or suggest alternatives, such as using base_address_check for a single address. It does provide cost and payment context, which aids in deciding, but not a direct comparison.

Agents often have multiple tools that could apply. Explicit usage 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 carries the full burden of behavioral transparency. It discloses the cost per call, that payment is required, that the tool returns payment requirements, and that failed calls are never billed. It also lists the data returned, giving clear insight into the tool's 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 two sentences, front-loaded with the core purpose, and adds essential behavioral details without redundancy. Every sentence earns its place, covering functionality, data fields, cost, and billing in a compact format.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 no parameters and no output schema, the description is fully complete. It explains what the tool returns, how it is accessed (Chainlink feeds), the cost and payment mechanism, and the success/failure billing nuance. All critical 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?

The tool has zero parameters, so there is nothing for the description to add beyond what the schema shows. According to the rubric, a baseline of 4 is appropriate for no parameters, and the description does not need to compensate for missing parameter details.

Input schemas describe structure but not intent. Descriptions should explain 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 live ETH/USD and BTC/USD price feeds from Chainlink on Base, with specific data fields. It distinguishes itself from sibling tools like base_token_price by explicitly naming the asset pairs and the on-chain source, making the purpose 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?

The description provides context for when to use the tool (for these specific price pairs) and notes cost and payment requirements, but it does not explicitly mention alternatives or when not to use it. It implies usage for these pairs, but lacks explicit comparisons to sibling tools like base_token_price.

Agents often have multiple tools that could apply. Explicit usage 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 of behavioral disclosure. It thoroughly explains that the simulation spends no gas, decodes revert reasons (including Error(string), Panic codes, and custom selectors), reports balance and allowance blockers, and clarifies that failed calls are never billed. It also reveals the cost ($0.008 per call in USDC) and the payment mechanism (x402 on Base), which are crucial for an agent deciding whether to invoke it.

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

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

The description is a single, well-structured paragraph that front-loads the core purpose and then adds essential details (revert decoding, cost, edge cases) without redundancy. Every sentence contributes meaningful information, and there is no fluff or unnecessary repetition.

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

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

Given the tool's complexity and the absence of an output schema and annotations, the description covers most necessary ground: it explains the simulation behavior, the specific output types (payment requirements, blockers), cost, and exceptions. However, it does not explicitly describe the structure of the returned data or list possible output fields, leaving some ambiguity about what exactly the agent will receive. A slightly more explicit description of the output would make it fully complete.

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

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

The input schema already provides descriptions for all 5 parameters, achieving 100% coverage. The tool description does not add additional parameter semantics beyond what the schema offers, so the baseline of 3 is appropriate. No extra context on parameter formats or relationships 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 opens with a specific, action-oriented question ('Will this token payment actually go through, and if not exactly why') that clearly defines the tool's purpose: simulating a token transfer to predict success or failure. It explicitly mentions the simulation, gas-free execution, and revert reason decoding, distinguishing it from sibling tools like base_allowance or base_tx_check which have different scopes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 (to test if a token payment will succeed) and notes a specific edge case (caller with no ETH for gasless EIP-3009 or sponsored relayer). However, it does not explicitly state when not to use it or mention alternative tools, so it falls short of the 'explicit when/when-not/alternatives' criterion.

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

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

With no annotations provided, the description carries the full behavioral burden and does a good job: it discloses the $0.001 cost, USDC/x402 payment method, that calling returns payment requirements, and that failed calls are never billed. It also implies a read-only operation. It could add auth or rate-limit details, but the cost and failure semantics are valuable.

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

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

Three sentences, each earning its place: purpose and fields, cost and payment, and billing-on-failure behavior. Information is front-loaded and there is no redundant or filler text.

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

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

For a one-parameter read-only tool with no output schema, the description is largely complete: it names the returned fields, states the network, and covers the payment/billing model. A minor gap is the lack of detail on the payment requirements response format, but this does not significantly hinder 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?

The input schema already describes the single parameter as an 'ERC-20 contract address on Base mainnet' with 100% coverage. The description does not add extra meaning about address format, checksum requirements, or example values, so it stays at the baseline for fully schema-documented parameters.

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

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

The description clearly identifies the resource (ERC-20 token metadata on Base mainnet), the specific fields returned (name, symbol, decimals, total supply), and the operation ('read straight from the contract'). This distinguishes it from siblings like base_token_price, which focuses on price rather than metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 what the tool does but provides no guidance on when to choose it over alternatives such as base_token_price or base_contract_type. There is no 'use this when' or 'for X use Y instead' language, leaving the agent to infer usage solely from the purpose.

Agents often have multiple tools that could apply. Explicit usage 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 pricing methodology (reads sqrtPriceX96, does Q96 math), the cost per call ($0.006), that failed calls are not billed, and the cross-checking for liquidity manipulation. This fully informs the agent about side effects and costs, especially since no annotations are provided.

Agents need to know what a tool does to the 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 sentence that packs a lot of information without fluff. It is readable and logically structured, but could be split into clearer sentences for improved scannability. Still, it is efficient 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?

It covers the core purpose, method, cost, failure handling, and edge cases (unlisted tokens, manipulation). However, it does not explicitly state the return format (e.g., a float in USD) or whether the price is in decimal or fixed-point, which a user might need. Given no output schema, this is a minor gap.

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

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

The schema already describes the parameter as an 'ERC-20 token address on Base mainnet' with 100% coverage. The description adds useful nuance by emphasizing 'any token' and the discovery of pools, which clarifies that the address can be for lesser-known or unlisted tokens. This slightly goes 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 explicitly states the tool provides the USD price for ANY token on Base, not just Chainlink-covered ones, and explains the Uniswap V3 pool discovery and pricing mechanism. This clearly differentiates it from sibling tools like base_token or base_contract_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?

It specifies when to use: for any token, including those outside Chainlink coverage, and notes that it ignores never-traded pools and cross-checks for thin or manipulated liquidity. This gives clear guidance on applicable scenarios and safety considerations.

Agents often have multiple tools that could apply. Explicit usage 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 fully discloses behavioral traits: it details output content, cost ($0.002 per call), payment method (USDC over x402), and billing behavior (failed calls not billed). This goes beyond minimal requirements and clearly explains what happens when called, including the return of payment requirements.

Agents need to know what a tool does to the 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 three sentences are efficiently written, with the main purpose first, followed by cost and billing details. Every sentence adds unique value, and there is no fluff or repetition. The description is well-structured and front-loaded with the most important information.

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

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

Given a single-parameter tool with no output schema or annotations, the description is complete: it explains the tool's purpose, lists the return data, and covers cost and error-billing nuances. It provides all necessary context for an agent to invoke it correctly.

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

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

The schema already describes the sole parameter 'hash' with 100% coverage ('Base mainnet transaction hash (0x-prefixed, 32 bytes)'). The description does not add parameter-specific details, so with high schema coverage the baseline of 3 applies as per calibration guidance.

Input schemas describe structure but not intent. Descriptions should explain 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 a specific verb ('Confirm') and resource ('Base mainnet transaction') and enumerates the exact outputs (success/reverted, block, confirmations, finality, gas used, ERC-20 transfers with USDC amounts), which distinguishes it from siblings like base_gas or base_token_price. It is highly specific and action-oriented.

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

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

The description implies the tool is for confirming transaction details but does not explicitly state when to use it versus alternatives like base_address_check or base_simulate_transfer. The use case is inferred from the verb 'Confirm' and the output list, which is implied usage rather than explicit guidance.

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