MACH Base

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

Annotations already cover read-only and non-destructive behavior, so the description adds value by disclosing the $0.005 USDC cost and x402 payment mechanism—information not present in structured fields. It also names the network (Base), which the annotations do not specify.

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?

A single sentence that front-loads the core action ('Check an ERC-20 token allowance on Base') and appends the cost detail. Zero filler words; every phrase 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?

For a read-only allowance check with fully described parameters and no output schema, the description covers the essential network and transaction cost. It could theoretically mention the return format, but that is not required given the tool's simplicity and the annotations' safety coverage.

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

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

Schema description coverage is 100% and all three parameters already have clear descriptions. The tool description adds no additional parameter-specific meaning beyond restating 'owner' and 'spender', so the baseline 3 applies.

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

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

The description uses a specific verb ('Check') and resource ('ERC-20 token allowance') with the network ('on Base'), clearly distinguishing it from sibling tools like base_erc20_balance (balance vs allowance). No ambiguity about 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 intended use case is implied by the purpose (checking an allowance), but there is no explicit guidance on when to prefer it over, say, base_erc20_balance or base_eth_call. No exclusions or conditional routing are provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'Get' wording is consistent with those. It adds non-obvious behavioral context by disclosing the $0.005 USDC x402 payment and specifying that the result includes header and transaction hashes, not full transaction bodies. This is useful for an agent deciding whether to invoke the 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 consists of two tight sentences with the core operation front-loaded. The cost sentence is necessary information and not filler. Nothing could be removed without losing meaningful guidance.

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 provides the essential facts: what to fetch, what it returns, and the payment cost. The mention of 'header and transaction hashes' serves as a return-value statement. It does not explain behavior when `block` is omitted, which is a minor gap given the schema lists no required fields, but the description is otherwise largely complete.

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

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

Schema coverage for the sole parameter `block` is 100%, so the schema already explains that it accepts a block number or a tag such as latest, safe, finalized, pending, or earliest. The description only repeats the notion of 'number or tag' and adds no new parameter-level detail. The baseline of 3 applies because the schema carries the full semantic weight.

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 starts with a specific verb, 'Get', and names the resource, 'Base block', with scope qualifiers 'by number or tag' and result details 'header and transaction hashes'. This clearly distinguishes the tool from siblings like base_transaction or base_block_number, even though those alternatives are not named explicitly.

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

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

The description gives no guidance about when to choose this tool over base_transaction, base_block_number, or base_receipt, and it states no exclusions or prerequisites. The only additional context is the cost notice, which is payment information rather than a usage rule. The intended use case must be inferred from the tool's name and purpose 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds concrete behavioral context beyond the annotations by disclosing the cost ($0.005 USDC via x402), which is non-obvious and important for an autonomous agent deciding whether to call the 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?

A single, well-structured sentence conveys the purpose, the network, the meaning of the returned value, and the cost. Every clause earns its place and 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 parameterless, read-only, non-destructive tool with no output schema, the description is complete. It tells the agent what it will get (latest Base mainnet block number), the cost, and that it is a read-only operation.

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 the description has no parameter semantics to clarify. This matches the baseline of 4 for parameterless tools; no additional explanation is needed.

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

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

The description states a specific verb ('Get'), a precise resource ('current Base mainnet block number'), and clarifies it means 'latest chain height'. It clearly differentiates this from sibling tools like base_transaction or base_receipt by focusing on the live chain tip.

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 'current Base mainnet block number (latest chain height)' clearly implies the appropriate use case: an agent needing the current block height on Base mainnet. It does not explicitly name alternatives or exclusions, but for such a simple, well-scoped operation, the context is evident.

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 this as a read-only, non-destructive, open-world operation, and the description reinforces that by stating it reads deployed bytecode. It adds valuable behavior beyond annotations by disclosing the $0.005 USDC cost via x402, which is important for invocation decisions.

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 clauses that deliver the purpose, mechanism, network, and cost without wasted words. Every sentence earns its place, and the core purpose is front-loaded.

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

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

For a single-parameter, read-only tool with rich annotations, the description covers the essential facts needed to invoke it correctly: input, network, mechanism, and cost. It does not specify the exact return format, but the 'check whether' phrasing communicates the boolean classification intent sufficiently.

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

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

Schema coverage is 100%: the single `address` parameter is fully described with format, pattern, and network context. The description adds no parameter-level details beyond what the schema already provides, 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 states a specific verb ('Check'), a clear resource ('address on Base mainnet'), and the exact outcome ('whether it is a smart contract or EOA'). It also names the mechanism ('reading deployed bytecode'), making the tool's purpose unambiguous and distinct from broader sibling tools.

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

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

The description gives clear context for when the tool should be used: whenever an agent needs to distinguish a smart contract from an EOA on Base mainnet. It does not explicitly name alternatives or exclusions, but the classification purpose is concrete enough that an agent can select it appropriately.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by stating the exact cost ($0.005 USDC via x402) and listing the returned data categories, which goes beyond the structured 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 well-structured sentence that front-loads the core purpose and output categories, then appends the cost detail. Every clause earns its place, with 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 tool is simple (one parameter, no output schema), and the description gives a high-level but adequate summary of return values and pricing. It does not detail the exact shape of token metadata or what 'common interface detection' returns, but for a lightweight inspection tool this is likely sufficient 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%, and the only parameter, 'address', is fully documented in the schema as 'Smart-contract address on Base mainnet.' The tool description adds no additional parameter-level meaning beyond what the schema already provides, 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 uses a specific verb ('Inspect') with a clear resource ('Base smart contract') and enumerates concrete outputs: token metadata, bytecode size, and common interface detection. This distinguishes it from siblings like base_contract_code (bytecode only) and base_erc20_balance (token balance only).

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 'in one call' implies this tool is for bundling multiple contract inspection needs, which is a usage signal. However, it does not explicitly state when to use this tool over alternatives such as base_contract_code or base_erc20_balance, nor does it mention exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the cost detail ($0.005 USDC via x402), which is useful behavioral context beyond annotations. However, it does not disclose what happens on invalid token/address, whether the token parameter must be a known USDC address, or any rate limits. With annotations covering safety, a 3 is appropriate.

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 sentence with no waste. It front-loads the action and resource, then adds the cost detail. 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?

For a simple read-only balance check with two parameters and no output schema, the description is mostly complete. It covers the network, the token type, and the cost. However, it doesn't mention the return format (e.g., raw integer vs. decimal-adjusted) or whether the token address must be a specific known USDC address. Given the simplicity and annotations, this is adequate but not exhaustive.

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 50%: the 'token' parameter has a description, but 'address' is a $ref to token, which is confusing and lacks its own semantic description. The description clarifies that 'token' is the ERC-20 contract address and 'address' is the wallet address, adding meaning beyond the schema. However, it doesn't fully compensate for the $ref ambiguity or explain that both are on Base mainnet beyond the description's first sentence.

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

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

The description states a specific verb ('Check'), a specific resource ('USDC or other ERC-20 token balance'), and a specific network ('Base mainnet'). It also names the cost mechanism, which distinguishes it from generic balance tools. Among siblings like base_wallet_balance and base_total_supply, this clearly identifies the ERC-20 token balance use case.

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 an ERC-20 token balance on Base mainnet. It does not explicitly state when not to use it or name alternatives like base_wallet_balance for native ETH balance or base_erc20_transfers for transfer history. The context is clear but exclusions are absent.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds the cost ($0.005 USDC via x402), which is useful operational context. However, it does not disclose limits, pagination, ordering, or which block range defaults to 'recent', leaving important 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?

Two concise sentences with the primary action first, filtering option second, and cost last. Zero filler; every clause 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?

For a read-only query with 5 parameters and no output schema, the description is adequate but leaves gaps: no mention of return format, pagination, block-range defaults, or how multiple filters combine. The 'recent' qualifier is vague and could mislead an agent about the query window.

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 all parameters are already documented with descriptions. The description adds only the concept of filtering by 'from or to a specific wallet', which maps to to_address/from_address, but adds no new semantic detail 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 finds ERC-20 transfers on Base and optionally filters by sender or recipient wallet. It distinguishes the resource (ERC-20 transfer events) from siblings like base_erc20_balance or base_logs, though it does not name them.

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 on when to use this tool versus alternatives like base_logs or base_transaction. The implied use case is clear (need transfer events), but there are no conditions, exclusions, or alternative recommendations.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces the read-only, non-transactional nature. It adds valuable behavioral context beyond the annotations by disclosing the exact cost ('$0.005 USDC via x402'), which is important 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?

Two sentences, no filler. The first sentence defines the core behavior and scope, and the second adds the cost. 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?

For a three-parameter read-only tool with rich schema descriptions and safety annotations, this description is complete. It states the network, the method, the non-transactional nature, and the cost, giving an agent everything needed 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?

Schema description coverage is 100%, so each parameter (to, data, block) is already well-documented in the schema. The description adds no additional parameter-level meaning, which matches the baseline of 3 since the schema carries the documentation burden.

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

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

The description names a specific operation ('read-only smart-contract call'), the exact RPC method ('eth_call'), the network ('Base'), and explicitly states it does not send a transaction. This clearly separates it from the transaction-oriented sibling tools like base_receipt and base_transaction.

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 read-only characterization and 'without sending a transaction' provide clear context for when this tool is appropriate: any contract state read on Base. It does not explicitly name alternative sibling tools or exclusions, but the usage context is strong enough for an agent to distinguish it from write or transaction-related tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds valuable context beyond annotations by specifying the network ('Base mainnet'), unit ('wei'), and the monetary cost of invocation ('$0.005 USDC via x402'), which is not inferable from annotations or schema.

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

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

The description is a single sentence that front-loads the action and resource, then adds the essential cost detail. There is no filler or redundant information.

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

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

For a simple zero-parameter, read-only tool, the description is complete: it states what is fetched, from which network, in what unit, and what it costs. No return schema is required to understand the expected output at this level of complexity.

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 no parameters, so the schema already exhaustively defines the input surface. The description adds meaning by clarifying the returned unit and use case, which is all that is needed when there are zero 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 states the action ('Get'), the resource ('gas price on Base mainnet'), and the unit ('wei'), along with its intended use for transaction fee estimation. This distinguishes it from the other Base read tools in the sibling list, none of which target gas price.

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

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

The description gives clear context for when to use the tool ('for transaction fee estimation') and mentions the associated cost. It does not explicitly name alternatives or exclusions, but no sibling tool performs the same function, so the guidance is sufficient.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds an important non-schema behavior: a concrete $0.005 USDC cost via x402. It doesn't mention return ordering or result limits, but for a safe read operation the description adds meaningful value beyond 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?

Two tight sentences with no filler; the core action and scope come first, with the cost disclosure at the end. Every sentence contributes.

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 100% schema coverage, the required address parameter, read-only annotations, and a clear statement of scope and cost, an agent has enough to select and invoke the tool. Return shape is not described, but no output schema exists and the expected result (event logs) is inferable from the tool's purpose.

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 already documents address, topics, from_block, and to_block. The description restates those as 'by contract address, topics and bounded block range' but adds no syntax details beyond the schema, matching 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?

The description opens with the specific verb 'Query' and names the resource: smart-contract event logs on Base, scoped by contract address, topics, and block range. This clearly distinguishes it from siblings like base_receipt or base_transaction.

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

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

It clearly signals when to use the tool: whenever event logs for a Base contract are needed over bounded block ranges. It does not explicitly name alternatives or exclusions, but the stated scope leaves little ambiguity about its niche among sibling tools.

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

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

Annotations already mark this as read-only, non-destructive, and open-world; the description adds a meaningful cost detail: $0.005 USDC via x402. This cost is not inferable from the schema or annotations and helps the agent account for a real external side effect.

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 short sentences carry the core purpose, timing context, and cost with no filler. The main verb and object are front-loaded, making the tool's behavior immediately scannable.

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, the description, schema, and annotations together cover purpose, timing, address format, safety, and cost. It does not explicitly state the return format, but "get nonce" makes the expected response self-evident and the omission is minor.

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%: the address parameter is already fully documented with its format and network. The description's "Base wallet" phrasing loosely maps to that parameter but adds no new semantic detail beyond the schema, 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 uses a specific verb and resource ("Get the current transaction nonce for a Base wallet"), which uniquely identifies the operation and distinguishes it from sibling tools such as base_transaction and base_wallet_balance. The phrase "before broadcasting a transaction" reinforces why the nonce is needed.

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

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

It clearly states the tool is used "before broadcasting a transaction," giving the agent a concrete context for when to invoke it. It does not explicitly name alternatives or exclusions, but no sibling tool directly overlaps with fetching a nonce.

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 this as read-only and non-destructive, so no mutation warning is needed. The description adds beyond-annotation context by disclosing the exact cost ($0.005 USDC via x402) and clarifying that confirmations are current, which is a meaningful behavioral detail for an agent deciding whether to call this 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 short sentences cover purpose, success semantics, receipt retrieval, confirmations, and cost. Every clause earns its place, and the most important behavioral facts are front-loaded.

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

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

For a single-parameter, read-only receipt lookup, the description gives enough high-level return semantics: success status, receipt, and confirmation count. It does not detail exact response fields, but the lack of an output schema is partially mitigated by the clear purpose statement. It would benefit from a note on not-found behavior, but that is not a critical 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 input schema already fully documents the single tx_hash parameter, including its 0x-prefixed 64-character pattern. The description adds no new parameter semantics beyond the schema, so the baseline of 3 applies.

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

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

The description names a specific resource (receipt) and three concrete checks: success, receipt retrieval, and confirmations. It does not explicitly distinguish itself from base_transaction or base_transaction_context, but the receipt-specific wording makes the function reasonably distinct.

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 appropriate when you need a Base transaction receipt and confirmation count, but it does not state when to prefer it over sibling tools or mention exclusions. The cost note is useful operational context but not usage routing 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 indicate readOnlyHint=true and destructiveHint=falsearke. The description adds meaningful behavioral context beyond those: it explicitly discloses a $0.005 USDC cost via x402 and clarifies support for both ERC-20 and ERC-721 standards. 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?

The description is two short sentences with no filler. The core action is front-loaded, the network and token standards are specified, and the cost caveat is included without bloating the text.

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

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

For a single-parameter, read-only tool with strong annotations, the description covers purpose, network, supported standards, and cost. It could mention whether the returned supply is raw or decimal-adjusted, but this is not critical for correct invocation.

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

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

Schema description coverage is 100%, with the single 'token' parameter already described as an address on Base mainnet. The description adds the ERC-721 NFT clarification, but this is a minor refinement rather than substantial new meaning beyond the schema.

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

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

The description states a specific verb and resource: 'Get total supply' for an ERC-20 token or ERC-721 NFT contract on Base. It clearly identifies what the tool does and distinguishes it from sibling tools like balance, allowance, or transaction queries.

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

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

The description clearly implies when to use this tool: when an agent needs the total supply of a standardized token on Base. It does not explicitly name alternatives or state when not to use it, but no sibling tool covers total supply, so the context is sufficient.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the cost ($0.008 USDC via x402) and noting that it returns 'live transaction details', which are behavioral traits not present in annotations. No contradictions exist.

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

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

The description is a single, compact sentence that front-loads the purpose and includes the critical cost information. Every word earns its place 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 simple read-only tool with one parameter and no output schema, the description covers the essential details: what is retrieved, the fields, and the cost. It does not describe the return structure, but that is not required given the lack of an output schema and the simplicity of the operation.

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 only parameter, tx_hash, is already well-described in the schema with its pattern and meaning. The description does not add any further semantic detail about the parameter, so the baseline of 3 is appropriate.

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

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

The description clearly states the verb 'Get' and the resource 'Base transaction by hash', listing the included fields (sender, recipient, value, calldata, live details). It is specific enough to understand the core function. However, it does not explicitly differentiate from siblings like base_receipt or base_transaction_context, so it falls 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?

No guidance is provided on when to use this tool versus the many base_* siblings. There is no mention of alternatives or exclusions, such as 'for only the receipt, use base_receipt'. An agent must infer usage from the name and description 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the cost ($0.008 USDC via x402), which is a useful additional behavioral detail not captured by annotations. It doesn't describe return structure or other nuances, but the added cost context justifies a 3.

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, concise and front-loaded with the purpose. The cost information is a valuable addition and takes no extra space. No wasted words.

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

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

Given the tool takes a single parameter and the schema fully documents it, the description covers the usage context well. The cost is mentioned. No missing information for an agent to call it correctly; output schema not needed.

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

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

The input schema has 100% coverage, with a clear description of tx_hash. The description adds no new parameter semantics beyond what's already in the schema, so the baseline of 3 applies.

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

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

The description clearly states the tool provides Base transaction context for verifying payments, debugging failed transactions, or confirming settlement. It distinguishes from siblings like base_receipt by emphasizing the 'one-call' comprehensive context, though it doesn't explicitly name alternatives.

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

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

Explicitly mentions when to use: when an agent needs one-call Base transaction context to verify a payment, debug a failed transaction, or confirm settlement. Does not exclude specific alternatives, but the use cases are well-defined.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the cost detail ($0.005 USDC via x402), which is valuable behavioral context beyond the annotations. It doesn't describe return format, but for a simple balance check 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?

Two sentences with zero waste. The core purpose is front-loaded, and the cost detail is a single additional sentence. 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?

For a simple read-only balance check with one fully-documented parameter and annotations covering safety, the description is nearly complete. The cost disclosure is a nice addition. The only minor gap is not describing the return format, but for a balance tool this is easily inferred.

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 fully documents the address parameter. The description doesn't add parameter-level detail beyond what the schema provides, but the baseline of 3 is appropriate since 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 verb 'Check' and the specific resource: native ETH balance of a wallet or address on Base mainnet. It also distinguishes itself from sibling tools like base_erc20_balance by specifying 'native ETH 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 clearly states the context for use: checking native ETH balance on Base mainnet. It doesn't explicitly mention when not to use it or name alternatives, but the context is clear enough given the sibling list includes base_erc20_balance for token balances.

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 this readOnly, openWorld, and non-destructive, so the description only needs to add extra behavioral context. It meaningfully adds the x402 cost ($0.005 USDC) and the 10-token cap, which are not available from 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 with no filler: it front-loads the operation and outputs, then states a key constraint/cost. It does not restate schema details or annotations.

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

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

Given two documented parameters and no nested objects, the description is nearly complete: it covers the input intent, result scope, token cap, and cost. It could note the exact return shape or whether the snapshot is always at the latest block, but those are minor omissions for a lightweight read tool.

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

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

Schema descriptions already cover 100% of the parameters with address/token patterns and constraints, so the baseline is 3. The description reinforces that native ETH is always included and the token list is optional, but adds no new syntax or format detail beyond the schema.

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

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

States a concrete operation—take a Base wallet snapshot—and explicitly scopes it to native ETH plus up to 10 ERC-20 balances. This differentiates it from sibling single-focus tools like base_wallet_balance and base_erc20_balance by describing a combined, batched read.

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 'in one call' implies a batching use case, but the description never names alternatives or says when not to use it. There is no explicit routing guidance versus the sibling balance tools, though the benefit of a combined call 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds useful context that it 'Returns no live chain data and has no side effects,' which clarifies the output is not actual chain data but a recommendation. This goes beyond the annotations and aligns with them; no contradiction.

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 zero redundancy. It front-loads the core purpose ('Free decision layer') and immediately answers the 'what does it do' question, then adds crucial behavioral notes. 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?

For a routing tool with one parameter and no output schema, the description clearly communicates what outputs to expect (price, result fields, next request) and explicitly states it returns no live chain data. It lacks details on how to handle edge cases (e.g., unsupported goals) but given the sibling context and annotations, this is nearly complete.

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

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

Schema description coverage is 100% for the single 'goal' parameter, and its description is adequately detailed. The tool description does not add extra meaning beyond the schema, such as example goals or expected format. With full schema coverage, baseline 3 is appropriate; no additional compensation needed.

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

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

The description states a specific verb ('map'), a clear resource ('agent goal to narrowest paid MACH Base capability'), and the exact outputs (price, result fields, next request). It clearly distinguishes itself from sibling tools that fetch blockchain data, so an agent can immediately tell this is a router/decision tool, not a data fetcher.

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 an agent has a goal and needs to determine the narrowest paid MACH Base capability. It does not explicitly exclude situations where the agent already knows the specific sibling tool, but the context of 'Free decision layer' and 'exact next request' strongly suggests using it before calling a paid capability. A more explicit 'use this when you are unsure which base_* tool fits' would make it a 5.

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