x402-tools

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

With no annotations provided, the description carries the behavioral transparency burden. It explicitly discloses pricing ($0.001 per call), payment method (x402/USDC), and states 'no rate limits, no API key'. It does not explicitly state the call is read-only, but that is inherently obvious from a balance lookup; the disclosed information is sufficient.

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, front-loaded with the main purpose, and includes essential extra information (pricing, payment) in a second sentence. No redundant or filler content.

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

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

The description covers functionality, supported chains, default behavior, pricing, and payment method. It does not describe the output or return format, but since no output schema is provided and the result is a simple balance, this omission is not a major gap. Overall, the context is nearly complete.

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

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

Both parameters (address and chain) are clearly described in the schema. The chain parameter enumerates valid values and states the default ('base'), while address specifies the expected 0x-prefixed format. The schema covers 100% of parameters, and descriptions add necessary clarity.

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: retrieving the native coin balance (ETH, MATIC) for any address on five named chains. It distinguishes from sibling tools like evm_erc20_balance by specifying 'native coin balance' and lists supported networks, so an agent can immediately understand what the tool 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?

The description provides practical usage context by listing supported chains, the default chain, and pricing/payment details. It does not explicitly mention when to use this tool versus an alternative (e.g., 'use evm_erc20_balance for token balances'), but the scope is clear enough to guide selection.

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

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

With no annotations provided, the description carries the full burden. It explicitly states the call is read-only (eth_call) and mentions the flat $0.001 per call paid via x402, providing transparency about cost and side-effect safety.

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, efficient sentence with no redundant wording. It packs essential information (read-only, raw, no API key/rate limit, pricing) without any 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?

Despite lacking an output schema, the description states the return type is the raw result, which is sufficient. It explains pricing, usage context, and the tool's role among siblings, making it complete for an agent to select and call correctly.

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

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

The schema descriptions cover all parameters (to, data, from, block, chain) with clear explanations. The description adds the context of 'raw result' but does not materially enhance parameter semantics beyond what the schema already provides, warranting the baseline of 3.

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

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

The description clearly states the tool 'runs any read-only contract call (eth_call) with your own calldata and returns the raw result.' This is a specific verb and resource, and it distinguishes itself from the many typed EVM sibling tools by being the generic raw call option.

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 'The escape hatch for anything the typed endpoints do not cover' gives explicit guidance on when to use this tool: when no more specific sibling tool applies. It also notes there is no API key or rate limit, which is useful operational context.

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

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

No annotations exist, so the description carries the full burden. It discloses pricing (flat $0.001 per call) and payment method (x402/USDC), which adds transparency. It does not explicitly state the operation is read-only, but the nature of a health check makes that implicit.

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 no unnecessary words. It efficiently communicates purpose, output, and usage in two sentences.

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

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

Given there is no output schema, the description sufficiently describes what the tool returns (chain id, block height, staleness) and includes pricing info. It is complete enough for a user to understand the tool's function.

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 no parameters, so the baseline applies. The description does not need to explain parameter behavior since none exist.

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 live health data for all supported chains, listing specific outputs (chain id, block height, staleness). It is distinct from sibling tools like evm_balance or evm_block.

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

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

It explicitly suggests the primary use case: 'Use it to pick a chain that is actually responding,' giving actionable guidance on when to invoke this tool.

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

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

No annotations are provided, so the description carries the full burden. It discloses the core behavior (returns allowance amount and whether unlimited) and even includes pricing. However, it does not explicitly state that the call is read-only and does not modify state, nor does it describe error behavior (e.g., reverts on invalid addresses) or the exact return format. For a simple query tool this is acceptable but leaves some gaps.

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

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

The description is two concise sentences with zero waste. The first sentence states the core functionality, and the second provides use cases and pricing. It is front-loaded with the most important information (what it does) and efficiently conveys all necessary context.

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

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

For a read-only allowance query with four parameters and no output schema, the description covers the essential aspects: what it returns (amount and unlimited status), when to use it (before approve, finding infinite approvals), and cost. It does not specify the exact JSON return structure or units (e.g., wei vs token decimal), but given the simplicity and the presence of schema documentation for parameters, this is a minor gap. Overall, it provides enough context for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters (chain, owner, token, spender) with descriptions. The tool description adds no additional parameter-specific details, such as chain-specific behavior or how to format addresses. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's function: it returns how much a spender can still move on an owner's behalf and whether that approval is unlimited. It distinguishes itself from siblings like evm_erc20_balance (balance vs allowance) and evm_token_info (token metadata vs allowance) through the specific focus on spending permissions. The phrasing 'check to run before an approve' gives a concrete use case that further clarifies the purpose.

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

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

The description provides explicit when-to-use guidance: 'before an approve' and 'finds forgotten infinite approvals'. This tells an agent exactly the situations where this tool is appropriate. It does not mention alternatives or exclusions, but there is no direct sibling for allowance checks among the listed tools, so the guidance is sufficient for routing.

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

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

With no annotations, the description carries the burden of revealing behavior. It states the call reads balanceOf, returns raw amount plus decimals, and includes pricing/payment details. It does not mention failure modes or chain handling, but the core read-only behavior and cost are disclosed.

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

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

The description is compact and directly informative, with no redundant wording. It conveys purpose, return content, and pricing in two short sentences.

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

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

Given there is no output schema, the description usefully explains that the response contains the raw amount and decimals for formatting. It also includes cost/payment context. It does not give an exact response shape or error behavior, but the essential call 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 documented in the schema with clear semantics: chain lists supported values, token is the ERC20 contract address, and address is the wallet. Since schema coverage is 100%, the description adds little beyond the schema, though it does not clarify the optional nature of the chain parameter.

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

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

The description clearly states the tool returns an ERC20 token balance for a wallet, naming specific tokens and the balanceOf mechanism. It is easily distinguished from sibling tools like evm_balance (native balance) and evm_erc20_allowance.

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 describes when to use the tool: to get an ERC20 token balance for any wallet/token. It does not explicitly contrast with native balance or other ERC20-related tools, but the purpose is specific enough that an agent can infer appropriate usage.

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

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

No annotations are provided, so the description must carry all transparency. It mentions the fee (flat $0.001 per call, paid via x402 USDC) and that it detects reverts. However, it does not explicitly state that the operation is read-only or describe any other side effects beyond costing money.

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

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

The description is brief and to the point, covering the core function, a key use case, and the cost in two sentences. No unnecessary 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?

Given there is no output schema, the description provides enough context for an agent to decide when to call this tool: it estimates gas, prices it, and can detect reverts. It also includes pricing details. The lack of output format information is acceptable since there is no output schema and the tool's purpose is straightforward.

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 for all parameters are clear and sufficient: 'to' is a destination address, 'data' is optional calldata, 'from' is a sender address, 'chain' lists valid values, and 'value' is in wei as a decimal string. The tool description does not add extra context, but the schema covers it well.

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

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

The description clearly states that it estimates gas and prices it at the current gas price, and also mentions it is the cheapest way to detect reverts. It does not explicitly differentiate from sibling tools like evm_call or evm_gas, but the 'before you sign anything' and 'cheapest way to find out that a call would revert' phrasing provides useful distinguishing context.

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

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

The description implies a use case (detecting reverts cheaply) but does not explicitly state when to prefer this tool over alternatives such as evm_call or evm_gas. It offers a hint but lacks a clear comparative guide.

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 data source (last 20 blocks), the output granularity (percentiles), and a flat cost of $0.001 per call paid via x402 (USDC). This is transparent about the operation being read-only and its cost, though it does not cover rate limits or authentication 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 description is concise—two sentences that front-load the core functionality and then add a benefit and cost. No redundant information; every sentence contributes value.

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

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

For a simple tool with one optional parameter and no output schema, the description covers purpose, data source, cost, and use case. It does not specify the response structure, but that is not required given the absence of an output schema and the straightforward nature of the 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 fully documents the only parameter, chain, with an explicit list of accepted values. The description adds no additional parameter details, so it meets the baseline for high schema coverage without adding extra semantic value.

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

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

The description explicitly states it suggests maxFeePerGas and maxPriorityFeePerGas based on the last 20 blocks of real fee history at percentiles. It clearly identifies the resource (fee history) and the action (suggesting fees), distinguishing it from other EVM tools like evm_gas and evm_estimate_gas by its specific data source and purpose.

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

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

It provides context for when to use it ('Beats guessing a gas price and getting stuck in the mempool'), implying its utility for setting transaction fees. However, it does not explicitly mention alternative tools like evm_gas or evm_estimate_gas or state when not to use them, leaving some inference required.

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

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

With no annotations, the description carries the full burden. It discloses that the call is paid (flat $0.001 via x402) and that outputs are pre-formatted with symbol and decimals. It does not mention error handling or default chain behavior, but the core behavioral traits are covered adequately.

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 with no redundancy. The core functionality is front-loaded, followed by the batch benefit and pricing. Every sentence earns its place.

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

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

The description explains the purpose and pricing, but does not clarify that the 'chain' parameter is required (schema marks it optional) or what happens if omitted. It also lacks details on failure modes or maximum token count (schema has that). For a paid call, this ambiguity could mislead an agent into omitting the chain.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that the native balance is always included in addition to the listed tokens, and that symbols/decimals are applied in output. This goes beyond the schema's simple parameter descriptions.

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

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

The description clearly states the tool's function: it retrieves the native balance plus balances of listed tokens in one call, with symbols and decimals applied. It distinguishes itself from sibling tools like evm_balance or evm_erc20_balance by emphasizing the batch capability ('one request instead of one per 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 description implies when to use it: when you need multiple token balances on one chain, instead of making separate calls. However, it does not explicitly name alternative tools or state when NOT to use it (e.g., for a single token balance). The context is clear but lacks 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 behavior (success/revert, gas used, fee, logs) and mentions the cost. It is implied to be a read-only operation, which is typical for a receipt lookup. Without annotations, the description carries the burden, and it covers the essential behavioral aspects.

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, using two sentences to convey the purpose, key output fields, and a use case, followed by pricing. There is no redundancy or unnecessary 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?

The description adequately explains the tool's output (success, gas, fee, logs) and its purpose. Since there is no output schema, the description provides enough information for an agent to understand what will be returned and how to use the 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 already provides full descriptions for both parameters (hash and chain). The tool description adds no further clarification beyond what the schema states, so the baseline of 3 applies.

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

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

The description clearly states the tool's function: retrieving a transaction receipt and summarizing success, gas used, fee paid, and logs. It also explicitly identifies the primary use case ('The call that answers did my transaction work.'), which distinguishes it from sibling tools like evm_tx.

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 a direct usage scenario ('The call that answers did my transaction work.'), which tells the agent when to invoke this tool. However, it does not explicitly compare against alternative tools or explain when not to use it, so it falls short of a perfect score.

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 carry behavioral disclosure. It reveals the output format (decoded as hex, integer, address) and the cost (flat $0.001 per call, paid via x402/USDC), which are useful. However, it does not mention potential errors, limits, or that it is a read-only operation beyond the verb 'reads', which is implicit.

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: three sentences, each with a clear role. The first sentence states the action and output, the second gives use cases, and the third states pricing. It is front-loaded with the core purpose and contains no filler.

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

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

The description explains the return values (hex, integer, address) and the cost, which is important since there is no output schema. However, it does not clarify default behavior when optional parameters (slot, chain) are omitted, or how the result is structured. This is a minor gap, but overall the tool is adequately described for an agent to call it correctly.

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

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

Schema coverage is 100%, so parameters are already documented. The description does not add extra meaning to the parameters themselves; it only mentions output decoding, which is not parameter-specific. According to the baseline for high coverage, a score of 3 is appropriate.

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

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

The description clearly states the tool reads a raw storage slot from any contract, and it distinguishes itself from sibling EVM tools by specifying the exact resource (raw storage) and the purpose (inspecting proxy implementation slots, owners, paused flags without getters). It uses a specific verb and resource, and the use cases differentiate it from balance, call, and transaction tools.

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

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

The description implies when to use it: when there is no public getter, such as for proxy implementation slots or paused flags. It gives concrete examples but does not explicitly name alternatives like evm_call for public getters. The guidance is clear but not exhaustive, missing an explicit 'when not to use'.

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

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

With no annotations, the description carries the full burden. It discloses the cost ($0.001 per call, paid via x402/USDC) and the output fields (name, symbol, decimals, total supply), which is valuable. However, it does not explicitly state that it is a read-only operation, nor mention potential failure modes (e.g., invalid token address). It is adequate but leaves some behavioral details implicit.

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 with no filler. The first sentence states the purpose and output, the second adds the use case and cost. Information is front-loaded and every sentence earns its place.

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

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

The tool is simple (2 parameters, no output schema). The description explains what the tool returns (name, symbol, decimals, total supply), covers the use case, and notes the cost. It does not mention error handling or rate limits, but for a straightforward read-only info call, this is sufficient. The lack of an output schema is compensated by listing the fields.

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 (chain and token). The description adds a slight clarification that the token is an ERC20 contract address and that the call works for 'any' such contract, but this adds little beyond the schema. 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 verb and resource: retrieving name, symbol, decimals, and total supply of an ERC20 contract. It is specific and not a tautology. It does not explicitly distinguish from sibling ERC20 tools like evm_erc20_balance or evm_erc20_allowance, but the scope is obvious enough that an agent can infer the difference.

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 a concrete use case: 'Useful to label a token address before showing it to a user.' This gives clear context for when to call it. It does not explicitly state when not to use it or name alternative tools, but the use case is sufficiently instructive.

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

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

With no annotations provided, the description carries full burden. It discloses the cost per call and payment method (USDC via x402), which is important behavioral information. It also implicitly indicates read-only behavior by describing what is returned. It does not mention potential side effects or error conditions, but the pricing and return scope provide reasonable 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 concise and well-structured: a clear purpose statement followed by an inline list of included fields, then a brief note on combining calls and cost. Every sentence adds value 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?

For a straightforward read-only transaction lookup, the description covers purpose, included data, and pricing. It does not detail output formatting or edge cases, but these are not essential for the tool to be used correctly in most scenarios.

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

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

The schema descriptions for both parameters (hash and chain) are clear, with the chain parameter listing valid options. The tool description adds no further explanation of these parameters beyond what the schema already provides, so this scores at the baseline.

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

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

Clearly states it fetches full transaction details by hash and merges with receipt, listing specific fields (from, to, value, gas used, status, block). This distinguishes it from sibling tools like evm_receipt by explicitly combining both pieces of data.

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

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

Provides practical guidance by saying 'One call instead of two', implying this tool should be used when both transaction and receipt data are needed, rather than calling separate tools. It also mentions flat pricing and payment method, giving cost-related usage context. However, it does not explicitly name the alternative tool or address when not to use it.

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

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

With no annotations, the description carries the full burden. It discloses automatic failover, typical response time under 1s, and the flat pricing mechanism. However, it omits details like error handling, rate limits, or side effects (though it's a non-destructive POST). It adds some behavioral context but not comprehensive coverage.

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

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

The description is somewhat repetitive, mentioning 'flat $0.001 per call' twice and the pricing theme multiple times. It is not tightly front-loaded, leading with pricing rather than the core function. It could be trimmed without losing information, making it only adequately concise.

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

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

The tool is simple with three parameters, but since there is no output schema, the description should clarify the return format. It only says 'get the completion' without specifying structure. It does mention payment via x402 (USDC), which is useful context. Overall, it is moderately complete but leaves the response format ambiguous.

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

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

Schema coverage is 100%, so the parameters are fully documented. The description mentions that maxTokens doesn't change the price, but this is already stated in the schema's description for that parameter. No additional semantic value is added beyond what the schema provides, so the baseline 3 is appropriate.

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

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

The description clearly states the tool is an LLM inference endpoint that takes a prompt and returns a completion, with a flat pricing model. It is distinct from all sibling tools, which are EVM/utility functions, so an agent can unambiguously identify this as the LLM completion tool.

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

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

While the description does not explicitly name an alternative, the sibling set is entirely EVM/utility, making this the obvious choice for LLM needs. It does mention a differentiator ('flat $0.001 per call' vs. 'metered gateways'), which gives context for when this is preferable, though it stops short of an explicit when/when-not statement.

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 cost behavior ($0.001 per call) and payment mechanism (x402/USDC), which are critical behavioral traits. It does not mention error handling (e.g., invalid base64 input) or output format, but these are standard for such utilities. Given no annotations exist, the description carries the burden and covers cost/payment well, with minor omissions on edge cases.

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

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

The description is concise and well-structured: two sentences covering functionality, use cases, and pricing. It front-loads the core action ('Base64 in both directions') and avoids redundancy. Every sentence adds value; no filler or unnecessary details.

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 a simple utility tool. It covers the core function, use cases (headers, JSON, x402), and cost. It does not explicitly state the return format (e.g., returns a base64 string), but this is implied and standard. Given no output schema, the description sufficiently equips an agent to call the tool correctly.

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

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

The schema has 100% description coverage for all three parameters (mode, input, urlSafe). The description adds extra context: 'with UTF-8 handled properly' clarifies input encoding, and the description of urlSafe ('URL-safe alphabet (-_ instead of +/)') reinforces the schema. This goes beyond the schema by explaining encoding behavior, but the baseline is already high due to full schema coverage.

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

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

The description clearly states the tool's function: 'Base64 in both directions, including the URL-safe alphabet, with UTF-8 handled properly.' It specifies the resource (base64 data) and the actions (encode/decode). It also differentiates from sibling tools by focusing on base64, while siblings handle hex, units, etc. The mention of payloads and x402 adds context without obscuring the core purpose.

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

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

The description explicitly mentions usage context: 'Encoding is what carries payloads through headers and JSON, and x402 itself rides on it.' It also discloses pricing and payment method: 'Flat $0.001 per call, paid over x402 (USDC).' This gives clear guidance on when and how to use the tool, even though it doesn't explicitly name alternatives—there are no direct siblings for base64 functionality.

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

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

With no annotations, the description carries the full burden. It discloses the operation (conversion), the output specifics (4-byte and 32-byte), and the cost ($0.001 per call, paid via x402). It does not cover error cases or edge conditions, but for a single-parameter utility this is adequate.

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

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

Two sentences: the first states the core function with an example, the second states the use case and cost. No fluff, well-front-loaded, every word earns its place.

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

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

The description explains the output format (selector and topic0) and the use cases, which is sufficient for a tool with one simple parameter. It doesn't mention return value encoding (hex vs raw) but that is implied and not critical. The cost is also disclosed. Minor gaps like error handling are acceptable.

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

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

Schema coverage is 100% and the schema already describes the signature format. The description adds an example (transfer(address,uint256)) which reinforces the format but does not introduce new semantics beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: it converts a Solidity signature into a 4-byte function selector and 32-byte event topic0, with a concrete example. This distinguishes it from generic hash utilities like util_keccak256 by specifying the exact output and purpose (building calldata or filtering logs).

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

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

It explicitly states when to use it: 'What you need to build calldata by hand or to filter logs.' While it doesn't name alternatives or when not to use it, the use cases are clear and the context is sufficient for an agent to decide 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?

With no annotations, the description discloses important behavior: randomness comes from the platform CSPRNG and the call has a flat cost paid via x402. It does not state side-effect-free behavior explicitly, but generation is implied.

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

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

Three short sentences cover output, use cases, and cost with no redundant or promotional wording. The description is easy to scan and each sentence earns its place.

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

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

The tool is simple and the description covers purpose, usage, output nature, and cost. It does not specify exact response shape when count > 1, but 'UUID v4s' with a count parameter makes the return format reasonably inferable.

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 only parameter, count, including range and default. The description adds no meaningful parameter-level information beyond restating 'up to 100 per call.'

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 producing cryptographically random UUID v4s, up to 100 per call. It distinguishes this from all sibling utilities by specifying uniqueness-focused use cases.

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

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

It explicitly names target use cases: idempotency keys, request ids, and correlation ids that must not collide. It does not explicitly say when not to use it or name an alternative, but the guidance is specific 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?

No annotations are provided, so the description carries the transparency burden. It mentions the cost and the core behavior, but does not describe exact return values or error conditions. Still, it gives enough context for typical use.

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, front-loaded with the main purpose, and includes the cost information without unnecessary fluff.

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

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

There is no output schema, but the description indicates the tool returns whether the recovered address matches the expected one. It is sufficient for a simple utility, though exact response formatting is left unspecified.

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

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

The schema already describes all three parameters adequately. The description adds domain context about EIP-191 and the expected-address comparison, but does not significantly extend the schema-provided 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?

Clearly states the tool recovers the signer address from a personal_sign (EIP-191) message and compares it to an expected address. This distinguishes it from the other EVM and utility tools in the sibling list.

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

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

Provides a clear use case: proving a wallet is controlled by the person talking. It does not explicitly contrast with sibling tools like util_address or util_keccak256, but the intended scenario is sufficiently clear.

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