BaseLens

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

Annotations already declare readOnlyHint and openWorldHint, so the description's real contribution is the payment model: a $0.002 USDC charge on Base via x402, plus the fact that results reflect the latest block rather than a historical one. That is meaningful context an agent can't get from the annotations, though failure/payment-failure behavior is unstated.

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 substantive capability is front-loaded and the cost/payment detail follows. No filler or repeated 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?

With no output schema, the description rightly enumerates the returned fields, and it discloses the paid x402 model and block freshness. For a single-parameter read tool this is nearly complete; only error or insufficient-payment behavior is left implicit.

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 exists and schema coverage is 100%, with the schema itself documenting '0x-prefixed Base address'. The description adds only that the address belongs to Base chain 8453, so it neither needs to nor does add much 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 names a specific resource (Base chain 8453 address snapshot) and enumerates exactly what is returned: account type (EOA/contract/EIP-7702), ETH balance, nonce, code size, native USDC balance. This implicitly separates it from sibling tools like base_contract and base_erc20_balance, though no sibling is 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?

It states the data is 'at the latest block' and that the call costs $0.002 USDC, which informs a cost/benefit decision, but it never says when to choose this over base_contract or base_erc20_balance, nor any prerequisites. Usage must be inferred from the enumerated fields.

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?

readOnlyHint=true already tells the agent this is a safe read. The description adds useful substance by disclosing that entries carry price, inputs, and an equivalent x402 HTTP URL — behavior beyond the bare annotation. It says nothing about pagination, size of the catalog, or formatting of the returned entries, so it stays at an adequate rather than rich level.

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, zero filler, with the what and the returned fields front-loaded. Nothing could be cut without losing 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 zero-argument catalog tool with no output schema, the description tells the agent what each entry contains, which is the key missing structured detail. Only mild gaps remain (ordering, catalog breadth), so it is complete enough to call correctly.

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

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

The tool takes no parameters at all, so there is nothing for the description to disambiguate. The baseline of 4 applies, and the description does not confuse matters by mentioning inputs the tool does not accept.

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 ('Lists every BaseLens tool') plus the fields returned (price, inputs, x402 HTTP URL). This clearly separates it from the sibling lookup tools, which each target a single chain resource.

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 catalog/discovery use case is strongly implied by 'lists every BaseLens tool with price', but there is no explicit when-to-use statement, no mention of when not to use it, and no named alternative (e.g., base_price for a single price). Guidance is inferred rather than stated.

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 and openWorldHint, and the description adds genuinely useful context beyond them: the $0.003 USDC charge via x402 (a real auth/paid-call requirement) and an explicit 'Not an audit' scope limitation. It stops short of saying what happens on an unverified or non-contract address, which would complete the behavioral picture.

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

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

Two tight sentences: the check contents come first, then the audit disclaimer and payment cost. No filler and nothing buried.

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 usefully enumerates the returned fields (is-contract, code size, owner, proxy implementation, verification status, notes), which covers most of what an agent needs. Missing only failure-mode behavior (non-contract addresses, unverified sources) and any indication of response shape.

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

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

Schema description coverage is 100% for the single 'address' parameter ('0x-prefixed Base address'), so the schema carries the semantics. The description adds no format, validation, or edge-case guidance about the address itself, 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 ('Contract check on Base') and enumerates exactly what the check covers: contract existence, code size, owner(), proxy implementation, Sourcify verification of source and implementation, plus notes. This scope is clearly distinct from siblings like base_address or base_token, so an agent can route 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 'Not an audit' disclaimer gives a partial when-not signal, and the cost line sets a payment precondition. However, it never states when to prefer this over sibling tools (e.g., base_address for a plain address lookup) or when the paid call is worth it, leaving selection 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 and openWorldHint, so the safety profile is covered. The description goes beyond them by disclosing the return shape (raw plus human-readable, symbol/decimals resolved) and, importantly, that each call costs $0.002 USDC via x402 — a real operational constraint. It stops short of explaining payment mechanics or failure behavior when payment or the token lookup fails.

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 the core capability front-loaded and the cost constraint appended. 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?

No output schema exists, but the description compensates by describing what is returned (raw and human-readable balance with symbol/decimals). For a 2-parameter read tool this is nearly complete; only payment flow and edge-case behavior (non-ERC-20 contract, unverified token) are unaddressed.

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 both parameters are already documented as a Base ERC-20 contract and a 0x-prefixed Base address. The phrase 'any address for any token on Base' reinforces the domain but adds no format or validation detail beyond the schema. 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: returns the ERC-20 balance of any address for any token on Base, with symbol and decimals applied. That is unambiguous and distinct from siblings like base_token or base_transfers, though it never explicitly contrasts itself with 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?

Usage is only implied: an agent infers it should call this when it needs a token balance. There is no explicit when-to-use/when-not guidance and no routing to alternatives such as base_token for token metadata. The cost line does add practical context for deciding whether to call it.

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

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

readOnlyHint=true already establishes the safe read profile, so the description's marginal value is the "free sample" framing and the stated return fields (block number + base fee). It says nothing about rate limits, freshness guarantees, or whether the sample is truncated relative to base_gas, which are the behaviors that actually distinguish a sample 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: the payload first, the use case second. No filler and nothing that could be cut without losing meaning.

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 params, no output schema and a simple read annotation, the description covers what an agent needs to make the call. The remaining gap is not telling the agent what it gives up by using the sample instead of base_gas.

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?

Zero parameters, so the baseline is 4. The description correctly frames this as a no-argument call and clarifies that the returned fee is in gwei, which is genuinely useful unit information.

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/scenario (free sample) and the exact payload: latest Base block number and base fee in gwei. This tells an agent precisely what it gets, though it never mentions the sibling base_gas, which is presumably the full-featured version.

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?

"Use it to test the connection" gives one implied use case but no explicit when-not or alternative. There is no guidance saying to call base_gas for production gas data, so the boundary with the sibling base_gas 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 cover safety (readOnlyHint=true, openWorldHint=true), and the description adds the material detail that isn't in them: this call costs $0.001 USDC on Base via x402. That payment requirement is exactly the kind of operational trait an agent needs before invoking. It doesn't say whether payment is settled per-call or via a pre-authorized channel, keeping it out of 5 territory.

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, front-loaded with the resource and the returned fields, with the cost disclosure appended. No filler, no repetition of the title's price tag beyond the needed x402 context.

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

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

With no output schema, the description carries the return-value burden and does so by listing each field, including the gwei unit. A zero-parameter read tool is simple enough that little else is needed. Minor gap: no indication of freshness/caching or why one would pick this over the free sibling.

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 for the description to disambiguate. The schema is an empty object, consistent with a parameterless read.

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 (current Base gas) and enumerates exactly what is returned: base fee, gas price, EIP-1559 max/priority fee, block fullness, and ETH transfer cost. That is far more than a restatement of the name. It stops short of 5 because it never distinguishes itself from the sibling base_free_gas_sample, which an agent will almost certainly want to compare against.

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 word 'Current' — an agent can infer this is for real-time gas lookups. There is no explicit when-to-use statement, no exclusions, and no routing to the obviously related base_free_gas_sample sibling. The paid-cost note is a prerequisite, not usage 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 and openWorldHint, so safety is covered; the description adds genuinely non-structured facts: the exact price ($0.001 USDC on Base via x402) and that the response includes avatar records. It omits what a failed resolution returns (null vs error), which keeps it below 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 dense sentence that front-loads both forward and reverse behavior, then appends the return-detail and pricing facts. No filler and no repetition of the title.

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-only lookup with no output schema, the description covers both directions, the return payload includes avatars, and the payment model is disclosed. The remaining gap is behavior when both or neither optional parameters are supplied, which the description leaves undefined.

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 baseline is 3. The description adds only a little beyond the schema — the example names and the word 'primary' for reverse results — without explaining precedence when both name and address are provided.

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

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

States a specific pair of verbs (resolve / reverse-resolve) on a specific resource (Basename or ENS name ↔ Base/Ethereum address), which is enough to know exactly what the tool returns. It does not differentiate itself from the sibling base_address, which plausibly overlaps in scope, 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?

The description makes the two usage modes clear (pass a name for forward lookup, an address for reverse lookup), and the schema labels address as an 'Alternative'. However, it never says when to pick this over the sibling base_address, nor what happens if neither parameter is supplied despite zero required parameters.

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 read-only and open-world profile, yet the description adds real value: a hard cost ($0.003 USDC via x402), the payment rail, the pricing methodology (direct USDC pool or via WETH, best fee tier), and the quote unit. Missing only what the returned quote looks like beyond the number.

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, dense with distinct facts (what, methodology, cost), with the core purpose front-loaded and 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 tool with annotations but no output schema, the description covers cost, routing, and quote basis well. It stops short of describing the response shape (fields, decimals, failure on illiquid tokens), which is the one remaining 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?

Schema coverage is 100% and the single 'token' parameter is well documented as 'ERC-20 token contract on Base', matching the description's framing. The '1 whole token' detail clarifies quote normalization rather than adding meaning to the parameter itself, so baseline 3 fits.

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 ('executable Uniswap v3 quote for 1 whole token') plus scope ('any Base ERC-20'), which is clearly distinct from sibling metadata tools like base_token or base_contract. An agent can tell exactly what this returns 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 scope ('any Base ERC-20') implies when the tool applies, and 'No third-party price API' rules out an alternative approach, but there's no explicit routing versus siblings such as base_token or base_contract, and no stated preconditions beyond having a token 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 and openWorldHint, so the safety profile is covered; the description adds genuinely non-structured context: the $0.003 USDC x402 cost and a 'facts, not advice' disclaimer. It does not say what happens when the address is not a token contract, which is the main remaining behavioral gap.

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

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

One dense, front-loaded sentence lists the returned fields, followed by two short clauses on read-only status and pricing. Nothing is buried and nothing is redundant, though the 'not advice' clause is marginal 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?

With no output schema, the description carries the burden of describing returns and does so thoroughly by naming each field, including derived plain-language notes. Only error/edge-case behavior for non-contract addresses 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?

There is one required parameter at 100% schema coverage, so the schema already carries the definition. The description adds nothing about input format (address only? symbol accepted?) or validation, leaving it at the baseline for fully-covered schemas.

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 (Base token contract facts) and enumerates exactly what is returned: name, symbol, decimals, supply, code size, owner(), and EIP-1967 implementation. That enumeration distinguishes it from siblings like base_erc20_balance and base_price, though it never explicitly contrasts with the closer base_contract.

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 enumerated facts (e.g. checking upgradeability or renounced ownership), but there is no explicit when-to-use statement, no exclusions, and no pointer to base_contract or base_name for overlapping questions. The agent must infer that this is the token-metadata tool.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds genuinely useful context beyond that: ordering (newest first), the lookback window, token defaults, and the x402 payment requirement of $0.004 USDC. The payment/auth model is a behavioral trait the schema and annotations do not express, which is exactly what this dimension rewards.

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 with no filler: scope first, use case second, cost last. The first sentence is quite dense (five chained qualifiers), but each sentence earns its place and the most decision-relevant 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 read-only tool with no output schema, the description never hints at the shape of the returned records (fields per transfer, whether amounts are raw or decimal-adjusted). Ordering and cost are covered, but an agent cannot anticipate the response structure at all, leaving a meaningful 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?

Schema description coverage is 100%, so the schema already documents every parameter with defaults and ranges. The description restates a few of these (default USDC, ~10k blocks, max 30k, 5-token cap) but adds no new syntax or constraint information beyond what the schema provides — baseline 3 is appropriate.

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

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

States a specific verb and resource ('Recent ERC-20 transfers in and out of an address on Base'), plus scope qualifiers (up to 5 tokens, default USDC, newest first, ~10k block lookback, max 30k). This is clearly distinguishable from siblings like base_tx (single tx detail) and base_erc20_balance (balances rather than transfer history).

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?

'Check incoming payments or wallet activity' gives a clear intended use case, which is more than most descriptions offer. However, it never names an alternative or exclusion — an agent must infer on its own whether base_tx is the better choice for a specific transaction lookup.

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 and open-world behavior, but the description adds the critical operational trait that each call costs $0.003 USDC on Base via x402 — a fact an agent must know before invoking. It also discloses the fee breakdown (incl. L1 fee), though error/not-found behavior is unstated.

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 filler: the first front-loads the full output payload, the second delivers the two decision-relevant facts (use case and price). Nothing is repeated from the schema 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?

With no output schema, the description correctly enumerates return fields and pairs that with the paid-call notice, making it callable without guesswork. Gaps are minor: no mention of behavior for unknown/unconfirmed hashes or chain mismatch beyond the schema's 'on Base' note.

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 ('0x-prefixed transaction hash on Base'), so the schema carries the semantics. The description adds nothing about the hash format or whether pending hashes are accepted, which is the correct baseline of 3.

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

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

States a specific verb and resource ('Human-readable summary of a Base transaction') and enumerates the exact fields returned: status, block time, from/to, value, total fee incl. L1 fee, and decoded ERC-20 Transfer events. This clearly separates it from siblings like base_transfers, base_erc20_balance, and base_address.

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

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

Provides a concrete use case — 'Handy to verify a payment landed' — which tells the agent when this tool is the right pick. It stops short of naming alternatives or exclusions (e.g. when to prefer base_transfers for a full history instead of a single tx lookup).

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