MACH Base

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds two traits not in the annotations: the 'does not grant approval' boundary and the $0.005 USDC x402 cost. Return shape is only alluded to ('the ERC-20 allowance'), which keeps it from a 5 given there is no output 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?

Two sentences, front-loaded with the purpose, then the negative scope, then the cost. No filler and nothing repeated from the schema.

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 3-required-param read tool with 100% schema coverage and full annotation coverage, the description supplies the purpose, the boundary, and the cost. The only missing piece is what the returned allowance value looks like, which a single clause could have closed without an output schema 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?

Schema description coverage is 100% — all three parameters (token, owner, spender) carry address format and role notes in the schema. The description echoes the same three roles ('one token, owner and spender') without adding syntax, defaults, or constraint detail 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 gives a specific verb and resource: 'return the ERC-20 allowance for one token, owner and spender.' The noun 'allowance' naturally separates it from siblings like base_erc20_balance or base_total_supply, though no sibling is named explicitly. Clear enough that an agent can pick it without consulting the schema.

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

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

It states the operational context clearly ('before an agent acts') and rules out the adjacent write operation ('Does not grant approval'), which steers the agent away from the approve path. No alternative tool is named and no hard exclusions are given, so it falls short of a 5.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds a genuinely non-structured behavioral fact: the call costs $0.005 USDC via x402, which an agent needs before invoking. It does not describe pagination or response size for the transaction-hash list.

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 waste: purpose and return content first, then the cost note. Every clause earns its place and the most important information is front-loaded.

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

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

For a single optional-parameter read tool with no output schema, naming the returned fields (header, transaction hashes) and the payment requirement covers what an agent needs. The only shortfall is the absence of routing guidance against the many sibling Base query tools.

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 enumerates the accepted tags (latest, safe, finalized, pending, earliest). The description's 'by number or tag' adds no syntax or constraint detail beyond that, so baseline 3 applies.

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

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

States a specific verb (Inspect) and resource (Base block), plus what is returned (header and transaction hashes). An agent can distinguish this from base_block_number (which yields only a height) and base_receipt / base_transaction without opening the schema.

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 stated goal 'to investigate chain activity' implies when the tool is relevant, but there is no explicit when-to-use vs alternatives or exclusion guidance (e.g. when to prefer base_block_number, base_logs, or base_transaction). Usage must be inferred.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower; the description adds genuinely useful context beyond them, namely the $0.005 USDC x402 cost, which affects agent invocation decisions. It omits latency/rate-limit behavior but the cost disclosure is real added value.

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, zero filler, with the core return value front-loaded and the caveat and cost following in order of importance.

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 zero-parameter tool with no output schema, the description states the return value ('latest mainnet block number'), the use case, the misconception to avoid, and the cost. Nothing an agent needs to call it correctly is missing.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing the description could add beyond what the empty schema already conveys.

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?

Names a specific verb and resource ('return the latest mainnet block number') and explicitly excludes a related-but-different interpretation ('This is not transaction confirmation'). It does not, however, differentiate itself from the sibling 'base_block', which an agent could easily confuse with it.

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?

Gives clear intended contexts ('freshness checks and polling') and an explicit when-not ('not transaction confirmation'), which is meaningful routing guidance. It stops short of naming a specific alternative tool (e.g. base_receipt) for the confirmation use case.

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 cover read-only, open-world and non-destructive behavior, so the bar is lower; the description still adds real value by disclosing the x402 payment requirement and the $0.005 USDC cost, plus what is returned. It does not, however, describe failure modes (e.g. behavior on a plain EOA or invalid address).

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, each earning its place: purpose, scope exclusion, and cost. The primary action is front-loaded and there is 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?

There is no output schema, so the description carries the return-value burden and does so ('whether code is deployed and its bytecode size'), while also flagging the payment model. An agent has everything needed to decide and invoke correctly.

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

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

Schema description coverage is 100% and the single parameter is fully documented in the schema (20-byte 0x-prefixed EVM address on Base mainnet). The description adds no format or constraint detail beyond that, 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?

States a specific verb and resource: it distinguishes a Base contract address from an EOA and returns code presence plus bytecode size. The 'Not a security audit' clause further scopes intent, but the sibling base_contract_info (which presumably returns richer metadata) is never named or contrasted.

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

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

Usage is implied by the framing 'tell a contract address from an EOA' and one explicit exclusion ('Not a security audit'), but there is no stated when-to-use versus alternatives such as base_contract_info or base_eth_call, and no prerequisites or preconditions for the address.

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 read-only, non-destructive, open-world behavior. The description adds genuinely non-structured facts: the call costs $0.005 USDC via x402 (a payment pre-requisite the agent must know) and a scope disclaimer that it is not a security audit. Return shape is not described, but this is still well above annotation-only 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?

Two tight sentences: the action and inspected artifacts come first, then the two critical caveats (not an audit, paid call). No filler or 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 single-parameter read tool with no output schema, the description covers purpose, inspected artifacts, cost, and scope limits. It could say more about the shape of the returned signals, but nothing essential for correct invocation is missing.

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

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

Only one parameter (address), and schema description coverage is 100% with a pattern constraint already documented in the schema. The description adds no address format, network, or resolution guidance beyond what the schema 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?

States a specific verb+resource (identify/inspect a Base contract) and enumerates what is examined: bytecode size, token metadata, interface signals. That scope is meaningfully distinct from raw-code siblings like base_contract_code or base_eth_call, though no sibling is named explicitly to sharpen the boundary.

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?

"Identify a Base contract before interacting" gives a clear situational trigger (pre-interaction recon), and "Not a security audit" sets an explicit boundary on what it should not be trusted for. It stops short of naming an alternative tool for deeper inspection or calling.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds real value beyond them: it discloses a paid x402 cost of $0.005 USDC and that the return is raw token units (not decimal-adjusted), which an agent must know before interpreting results.

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 front-loaded sentence states the action, the scope, and two behavioral facts (raw units, cost) with 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 two-parameter read with no output schema, the description covers what to pass, what comes back (raw units), safety behavior via annotations, and the payment requirement. Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is only 50% (token is documented, address just $refs it), so the description's mapping of 'token contract' and 'wallet address' to the two required params materially disambiguates their roles. It does not add format detail beyond the 0x-address description the schema already supplies.

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 verb (check), resource (USDC or ERC-20 balance), and venue (Base), and the token-contract/wallet-address framing separates it from the native-asset sibling base_wallet_balance without needing to open either schema.

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

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

It states what it does but never says when to prefer it over siblings like base_wallet_balance, base_allowance, or base_total_supply, nor any prerequisites. There is no when-to-use, when-not-to-use, or alternative 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 declare readOnlyHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds genuinely useful behavioral context beyond them: a $0.005 USDC x402 payment requirement and the fact that results are bounded to the queried block window. It stops short of describing pagination or result-size limits.

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

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

Two tight sentences, front-loaded with purpose, then scope and cost. Every sentence earns its place with no filler.

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

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

For a read-only query tool with full annotation coverage, the description covers purpose, filtering, block-window scope, and cost. With no output schema, it could say more about the shape of returned transfers or result limits, but nothing critical for correct invocation is missing.

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

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

Schema description coverage is 100%, so token, from_block, to_block, from_address, and to_address are all documented in the schema. The description only restates the sender/recipient filtering, adding no format or default details beyond the structured data. 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?

States a specific verb (Find), resource (ERC-20 Transfer events), and scope (on Base, optionally filtered by sender/recipient). This is distinguishable from generic siblings like base_logs or base_receipt without opening their schemas.

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?

Gives implied context via the block-window and filter framing, but never states when to prefer this over base_logs (generic log query) or other sibling tools, and offers no exclusions. Usage must be inferred.

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

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

Annotations already declare readOnly, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: the x402 payment cost ($0.005 USDC) and that the raw response is returned unpreprocessed. It does not mention rate limits or failure modes.

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 tight sentence covering action, mechanism, safety, and return shape, followed by a short cost note. Front-loaded and zero waste.

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

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

No output schema, but the description signals the return is the raw eth_call response, and annotations plus the stated cost cover the operational concerns. Only minor gaps remain (e.g., error/decoding behavior on revert).

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 `to`, `data`, and `block` are already fully documented in the schema. The description only restates that calldata is supplied; it adds no semantics beyond the structured fields. 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?

States a specific verb+resource ('read Base contract state') and pins the mechanism ('run eth_call with supplied calldata'), which cleanly separates it from write/broadcast tools. It does not name a sibling explicitly (e.g., base_transaction vs. base_contract_info), so it stops short of a 5.

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

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

Gives clear context: use this to read state without broadcasting a transaction, with calldata supplied by the caller. No explicit when-not or alternative tool is named, so the guidance is contextual rather than 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?

Annotations already declare readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context beyond the annotations: the tool is paid ('Costs $0.005 USDC via x402') and the quote is not the full transaction cost. These are useful, non-obvious traits.

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

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

Three short sentences, zero waste, with the core purpose front-loaded before the caveat and the cost note.

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 tool with no output schema, the description covers purpose, timing, a caveat, and the payment cost. It could say more about the response shape (a single wei value), but nothing essential to correct invocation is missing.

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

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

The tool takes zero parameters, so the schema-baseline is 4. There is nothing for the description to add on the parameter side.

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 specific verb+resource+unit: 'Check the current Base gas price in wei.' This is unambiguous and clearly distinct from the other base_* read tools, though it doesn't explicitly differentiate itself from any sibling by name.

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

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

'before estimating transaction fees' gives concrete timing context for when to call it, and the caveat that the quote is not the total cost sets expectations. It does not name alternatives or state when not to use it, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint, so the safety profile is covered. The description adds genuinely new behavioral context the annotations do not carry: the call costs $0.005 USDC via x402, meaning a payment/auth step is required. It does not mention result limits or pagination, keeping it short of a 5.

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 action and scope, followed by the cost clause. Every clause earns its place with 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?

There is no output schema, but the description states what is returned ('onchain logs') and discloses the payment requirement and range constraint. For a 4-parameter read-only query whose schema is fully documented, this is nearly complete; it could note block-range limits or result caps but is adequate as-is.

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 address, topics, from_block and to_block with their formats and the wildcard-null semantics. The description only restates that filtering is by contract address and optional topics, adding no syntax or default information beyond the schema. Baseline 3.

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

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

The description uses a specific verb+resource ('Find Base smart-contract events... return onchain logs') and scopes it to a bounded block range with contract-address and topic filtering. It is clearly the generic eth_getLogs query, but it never names or distinguishes itself from the overlapping sibling base_erc20_transfers, so an agent must infer the boundary.

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 a bounded block range' implies a usage constraint, and the cost statement hints at a pay-per-call context, but there is no explicit when-to-use guidance or routing to alternatives such as base_erc20_transfers or base_receipt. Usage is only implied.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely new behavior beyond the annotations: no signing or broadcasting occurs, and the call is metered at $0.005 USDC via x402, which an agent must know before invoking.

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, front-loaded with the action and immediately followed by the two facts an agent most needs (no signing/broadcasting, cost). No filler.

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

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

For a one-parameter read tool with annotations covering the safety profile and a fully documented schema, the description supplies the missing operational facts (no broadcast, paid via x402). Only the return shape (nonce as a numeric value) is left unstated, which is a minor gap given no output schema.

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

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

There is a single parameter with 100% schema description coverage, so the schema already documents the 0x-prefixed 20-byte Base mainnet address and its pattern. The description adds no format, network, or constraint detail beyond that, which is the expected baseline 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?

States a specific verb and resource: 'get a wallet's current nonce' on Base, with the clarifying scope 'without signing or broadcasting a transaction'. The resource is unambiguous against siblings like base_wallet_balance or base_transaction, though it never names or contrasts an alternative sibling 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?

'Prepare a Base transaction' implies the workflow context (fetching a nonce before constructing/sending a tx), which is useful implied usage. However there is no explicit when-to-use versus when-not, and no alternatives among the many base_* siblings are referenced.

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 cover the safety profile (readOnlyHint, destructiveHint false, openWorldHint), so the bar is lower. The description still adds two things annotations cannot convey: the $0.005 USDC x402 payment cost and the epistemic limit of the result (mined/succeeded does not imply correct payee or delivery).

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, both front-loaded with the highest-value information (what is verified, then the cost). No filler, no repetition of the name 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?

There is no output schema, but the description states the return contents (status and confirmations), discloses the payment requirement, and bounds what the result proves. For a single-parameter read tool, nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100% — tx_hash is fully documented with its 32-byte 0x-prefixed format in the schema. The description adds no additional syntax, sourcing or constraint information about the parameter, so baseline 3 applies.

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

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

Specific verb ('check') plus resource ('Base transaction receipt') and an explicit statement of what is returned: receipt status and confirmations. It is clearly distinguishable from the transaction-fetching siblings, but it never names an alternative tool, so sibling differentiation is inferred rather than stated.

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?

Gives clear usage context and an explicit negative boundary ('does not prove the correct payee, token amount or service delivery'), which tells the agent when this result is insufficient. It stops short of naming which sibling to use instead when those guarantees are needed, so it is not a full when/when-not/alternative map.

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 cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint). The description adds genuinely non-obvious context: that the value is contract-reported and not audited circulation, and that the call costs $0.005 USDC via x402. The payment requirement is a meaningful behavioral trait not present in the annotations.

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

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

Three short sentences, front-loaded with what the tool returns, followed by the data-quality caveat and the cost. Every sentence carries distinct information and nothing is repeated from the schema.

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 no output schema, the description supplies purpose, a data-trust caveat, and a payment requirement — enough for correct invocation. It does not describe the returned representation or error behavior, but those gaps are minor here.

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

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

Schema description coverage is 100% for the single 'token' parameter, including its address pattern, so the schema carries the semantic burden and baseline 3 applies. The description only loosely echoes the resource ('ERC-20 or ERC-721 contract'), adding no format or interpretation 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 states a specific verb and resource — checking a Base ERC-20/ERC-721 contract's total supply — which is clearly narrower than siblings like base_contract_info or base_erc20_balance. However, it does not explicitly name an alternative tool, so the differentiation from siblings is implied rather than stated.

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

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

Usage is only implied by the verb 'Check' — the agent can infer this is the read path for supply. There is no guidance on when to prefer this over base_contract_info (which may also expose supply) or any exclusion conditions, leaving the selection decision to inference.

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/openWorldHint/destructiveHint, so safety is covered. The description adds genuinely new behavioral context the annotations cannot express: the tool costs $0.008 USDC via x402, a monetization/payment requirement an agent must know before calling.

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

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

Two sentences, front-loaded with the core action and returned fields, then the sibling routing and cost. No filler; every clause carries information an agent needs.

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 no output schema, the description compensates by enumerating the returned fields, and it discloses the x402 payment cost. For a single-param read tool with full annotation coverage, nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100% and the single tx_hash param is documented with a 0x 64-hex pattern, so the schema carries the load. The description's 'by hash' adds no format or syntax detail beyond what the schema already states — baseline 3.

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

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

States a specific verb (Inspect/retrieve) and resource (Base transaction by hash) and enumerates the returned fields (sender, recipient, value, calldata, transaction fields), which lets an agent distinguish it from hash/balance siblings without opening a schema.

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 routes the agent to a named alternative — 'Use Transaction Context for receipt and confirmation status' — supplying the condition that selects it. It stops short of stating when-not-to-use cases broadly, but the key alternative is named.

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 cover the safety profile (readOnly, non-destructive, open-world), so the bar is lower. The description then adds two things annotations cannot express: an explicit paywall ('Costs $0.008 USDC via x402') and a caveat that onchain success does not establish the USDC obligation, which shapes how the agent interprets results. It does not describe pagination or rate limits, hence not a 5.

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 compact sentences, front-loaded with purpose and cost last. The middle sentence is domain interpretation rather than tool mechanics, but it still informs result handling and does not bloat the text. No filler 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?

With no output schema, the description carries the burden of saying what comes back, and it does so by naming the four context categories. Combined with the paywall disclosure, an agent has enough to decide and invoke. It stops short of a 5 only because the interpretive caveat substitutes for any concrete return-shape detail.

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 single tx_hash parameter is fully documented with pattern and format in the schema. The description adds no format or constraint detail beyond it, so the baseline of 3 for schema-carried parameters 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?

States a specific verb ('Investigate') plus resource and enumerates the composite payload it returns: transaction, receipt, gas and fee context. This implicitly differentiates it from the narrower siblings base_transaction and base_receipt, which each return one slice. It does not name those siblings outright, so it stays short of a 5.

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

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

The opening phrase 'Investigate a Base payment timeout or failed transaction' gives a concrete triggering scenario, which is genuine usage context. However it never states when to prefer this over base_transaction/base_receipt or base_wallet_snapshot, and gives no exclusions, so the routing decision is left to inference.

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, destructiveHint=false and openWorldHint, but the description adds a materially useful detail the annotations cannot express: a pay-per-call cost of $0.005 USDC via x402. It reinforces that no signing/wallet access occurs, which is redundant with but clearer than a bare readOnlyHint.

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 clauses, front-loaded with the purpose and immediately followed by unit of return, safety profile, and cost. No filler or restatement of the tool name.

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, and the description compensates by specifying the return value and unit ('balance in wei'). Combined with the disclosed payment requirement and read-only guarantee, an agent has everything needed to call this 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 the single address parameter and its 0x-prefixed 20-byte pattern are fully documented in the schema. The description only implies the address via 'a Base wallet' and adds nothing about chain targeting or address format, so baseline 3 applies.

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

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

States a specific verb (check/return), resource (native ETH balance of a Base wallet), and unit (wei). The qualifier 'native ETH' implicitly separates it from the sibling base_erc20_balance, so an agent can route without opening either schema.

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 'available for gas' hints at the intended use case (pre-flight gas sufficiency check), but the description never states when to prefer this over base_wallet_snapshot, base_eth_call, or base_erc20_balance, nor any precondition beyond a valid address.

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, destructiveHint=false and openWorldHint, so the safety profile is largely covered; the description goes beyond them by disclosing the cost ($0.005 USDC via x402 pay-per-call) and confirming 'no signing or custody'. It does not explain what happens on payment failure or rate limits, keeping it short of a 5.

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, front-loaded sentences with zero filler: capability, safety/payment note, then cost. 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?

With no output schema, the description correctly states what is returned (native ETH plus per-contract ERC-20 balances) and discloses the x402 payment model, which is essential for calling it. Minor gaps remain around payment/error flow, but nothing blocking an agent from invoking 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% for both parameters, so the schema already documents address and the token list including the 10-item cap and address pattern. The description only restates 'up to ten specified ERC-20 contracts' with no added format or behavioral detail, 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?

States a specific verb (return/check) and resource (native ETH + up to ten ERC-20 balances) on Base, and its scope ('in one read') implicitly distinguishes it from base_wallet_balance (native only) and base_erc20_balance (single token). An agent can pick it over its siblings without opening a schema.

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 read' implies when this batched snapshot is preferable to single-asset calls, but no alternative is named and no when-not condition is given. Usage is inferable rather than explicit.

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

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

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.