base-web3-m2m-hub

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 new behavioral context the annotations do not carry: the data is read live on-chain and each call costs 0.0040 USDC, always paid. It stops short of covering freshness, failure modes, or rate limits, so 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?

Two sentences, zero filler, with the core capability front-loaded and the cost/payment condition appended last. 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?

There is no output schema, so the description carries the return-value burden and does name the two returned values (supply APY, variable borrow APY). It omits units, response shape, and the meaning of "listed asset" for a non-default address, which is a modest but real 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% for the single 'asset' parameter, so the schema already documents the ERC-20 address format and WETH default. The description merely restates "any listed asset (default WETH)" without adding format or constraint 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 and resource: reads live Aave v3 reserve rates on-chain on Base, returning supply APY and variable borrow APY. Scope (which chain, which protocol version) and the returned quantities are explicit, making it easy to distinguish from siblings like liquidity-health or market-snapshot.

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?

"For yield and borrow-cost bots" implies the usage context but never states when to prefer this over alternatives such as liquidity-health or market-snapshot, and offers no exclusions or prerequisites. Usage is implied rather than guided.

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 only declare readOnlyHint and openWorldHint, but the description adds substantial operational context: reads via eth_getLogs, a bounded recent window constrained by the RPC log-range quota, a cap of 50 returned logs, and a per-call price (0.0050 USDC, always paid). The cost and quota limits are decision-relevant facts an agent cannot get from 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?

Six short sentences, each carrying distinct information (purpose, filter, return shape, window limit, sibling routing, pricing), with the core purpose front-loaded. 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 compensates by describing the return payload (up to 50 logs with block, tx hash, topics and data), the query window, the filtering option, and the cost. An agent has everything needed to decide and call correctly.

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

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

Schema description coverage is 100%, so the schema already documents address, topic0 (32-byte event signature hash) and windowBlocks (10-120, default 100). The description restates the topic0 filter and the bounded window but adds no new syntax, format, or constraint 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 and resource ('Recent event logs for any contract on Base'), names the underlying mechanism (eth_getLogs), and explicitly differentiates from sibling tools whale-wallet-tracker and token-deploy-radar. An agent can identify this as the generic event-log reader without inspecting any 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: 'Use this for generic event queries not covered by whale-wallet-tracker or token-deploy-radar.' Two alternatives are named, giving clear context. It stops short of stating what those siblings actually cover, so the when-not condition requires the agent to already know them.

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 new behavioral facts: the operation is restricted to the Base chain, it is metered at 0.0030 USDC per call with the first call free, and it deliberately omits risk analysis. That cost and chain-scoping detail goes beyond the structured fields.

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 tightly packed sentences, zero filler, scope constraint and exclusion front-loaded before the alternatives and pricing. Every clause carries either capability, routing, or cost 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?

No output schema exists, yet the description enumerates the returned fields, states the chain, discloses pricing, and routes to alternatives. For a one-parameter read tool that is everything an agent needs 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% and there is a single required address parameter, so the schema carries the load. The description only adds chain context ('any address on Base'), which is marginal over what the schema provides. 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 resource (contract structure) and enumerates the exact outputs: bytecode size, EIP-1167/EIP-1967 proxy detection with implementation and admin, and owner(). It scopes itself with 'ONLY' and names the two sibling tools it is not, so an agent can separate it from token-due-diligence and contract-read 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?

Gives explicit negative guidance ('NOT a security audit') plus two named alternatives with the condition that selects each: token-due-diligence for risk flags and pool liquidity, contract-read for arbitrary view functions. The agent knows both when to use this tool and when to route elsewhere.

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 (readOnlyHint, openWorldHint), so the bar is lower. The description still adds real value beyond them: it restates that no transaction is ever sent, discloses best-effort return-value decoding, and reveals cost (0.0030 USDC per call, first call free) — a behavioral trait no annotation captures.

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?

Front-loaded with the core purpose and input/output in the first sentence, with routing, safety and pricing following. Information-dense with almost no waste, though the parenthetical calldata example and stacked clauses make the first sentence fairly heavy.

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 ('raw return data plus best-effort uint/address/bool/string decoding'). It covers inputs, cost, safety and return shape, leaving only failure behavior on a reverted call unaddressed — a minor gap for arbitrary contract reads.

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 covers both parameters at 100%, so the baseline is 3. The description nonetheless enriches the semantics: it explains the calldata structure (4-byte selector optionally followed by ABI-encoded args) and gives a concrete worked example ('0x18160ddd = totalSupply'), which helps an agent construct a valid call.

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

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

States a specific verb and resource ('read-only call to any contract on Base'), names the required inputs (address + hex calldata) and the result (raw return data plus best-effort decoding). It also explicitly distinguishes itself from the many dedicated siblings by scoping to 'arbitrary view functions not covered by a dedicated tool.'

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

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

Gives an explicit routing rule: use this for arbitrary view functions that have no dedicated tool. Among 17 siblings that mostly wrap specific protocols (aave-yield, pool-slippage, etc.), this tells the agent exactly when this generic fallback is the right pick versus a specialized 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 cover the safety profile (readOnlyHint, openWorldHint), and the description adds real context beyond them: fees, gas and slippage are excluded from the spread; pricing is 0.0050 USDC per call and always paid. It does not describe caching, freshness/latency of the on-chain quote, or staleness behavior, which would matter for an arbitrage signal.

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?

Front-loads scope, then usage routing, then cost. Every sentence earns its place, though the first sentence is densely packed with parenthetical caveats and the pricing clause could be trimmed.

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, yet the description states what comes back (spot price, gross spread in bps, cheaper side) and what is excluded. Combined with the routing and cost disclosure, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100% and the single 'pair' parameter already documents that only WETH/USDC is supported, so the description adds no parameter meaning beyond the schema. Baseline 3 applies when the schema carries the full load.

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 specific verb+resource (WETH/USDC spot price on Uniswap v3 and Aerodrome v2) plus the exact output shape (gross spread in bps, cheaper side). It explicitly narrows scope to 'DEX pricing/spread ONLY', making it plainly distinguishable from token-spot-price and multi-token-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?

Names two alternatives and the conditions that select them: pool-slippage for expected slippage of a given trade size, market-snapshot if gas is also needed. That is explicit when-to-use routing with clear 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 cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuinely useful behavioral context beyond them: the read is on-chain, the per-call price is 0.0050 USDC, and the premium is always paid. It does not mention rate limits or latency, but the pricing disclosure is meaningful 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?

Two compact sentences, front-loaded with the tool's purpose and chain/scope. The pricing sentence is relevant and brief; little waste, though it is somewhat dense with clauses.

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, single-optional-param tool with annotations covering safety and no output schema, the description conveys what is returned (liquidity and fee) and the default asset. Slightly more on the return shape would round it out, but nothing essential 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 schema documents the single optional asset param with its WETH default. The description's 'default WETH' and 'any listed asset' restate the schema rather than adding new meaning, 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+resource: reads Aave v3 flash-loan liquidity and fee for any listed asset on Base. This is a distinct resource (flash-loan availability/cost) that is clearly separable from siblings like aave-yield or liquidity-health.

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 rather than stated – an agent can infer you call this to check flash-loan capacity or fees, but there is no explicit when-to-use, when-not, or routing to alternatives such as aave-yield or liquidity-health.

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 real context beyond them: the upstream data source (eth_feeHistory), the network (Base Mainnet), and the cost model (0.0020 USDC per call, first call free), which matters for an agent deciding whether to spend a call. It stops short of rate limits or failure behavior, so a 4 rather than 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 tight sentences, front-loaded with the scope constraint ('Gas ONLY') before the routing advice and price. Every clause carries distinct information: data source, outputs, alternative, cost.

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 compensates by naming every returned field (base fee latest/average, percentile bands, congestion label) along with the price. An agent has enough to decide and invoke without further documentation.

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, which is the baseline-4 case. The description correctly implies no configuration is needed and spends its words on outputs instead of inventing parameter guidance.

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

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

States a specific verb and resource ('live Base Mainnet gas from eth_feeHistory') and enumerates the exact outputs: latest and 10-block average base fee in gwei, p25/p50/p75 priority-fee percentiles, and a congestion label. It explicitly marks itself as gas-only, which separates it cleanly from market-snapshot and the pricing siblings.

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 an explicit when-to-use ('when you need gas and nothing else') and names the alternative with the condition that selects it ('if you also want WETH/USDC pricing, use market-snapshot instead'), even quantifying the tradeoff as one cheaper call. No inference required.

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

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

Annotations already cover readOnlyHint and openWorldHint, and the description adds genuinely new behavioral facts: the exact cost (0.0050 USDC per call), that it is a premium call always charged regardless of result, and the enumerated risk-band outputs. It stops short of describing latency, rate limits, or error behavior on invalid/unpositioned wallets.

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 filler; the scope and returned fields are front-loaded and the pricing/terms clause follows. Slightly dense with the parenthetical enum list, but every element 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 carries the burden of explaining return values, and it does so by naming the four metrics and the five risk bands. Combined with the pricing disclosure, an agent has what it needs to decide and call correctly, though error/empty-position behavior remains 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% for the single userAddress parameter, so the baseline is 3. The description adds no format, chain-scoping, or validity guidance beyond what the schema already states ('Wallet address (0x...) to inspect').

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 concrete verb-implied resource set (total collateral, debt, health factor, risk band) for a specific protocol and chain (Aave v3 on Base) and a scoped target (any wallet). It is clearly distinct from generic siblings like wallet-portfolio or market-snapshot, though it never explicitly contrasts with the closer liquidity-health sibling.

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: call this when you need a wallet's liquidation risk posture on Aave v3 Base. There is no statement of when NOT to use it, no prerequisite/eligibility notes (e.g., must be an Aave v3 position), and no routing to the similar-sounding liquidity-health sibling.

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 only declare readOnlyHint and openWorldHint; the description adds data provenance (GoPlus plus on-chain facts), concrete returned flag types, explicit limitations (no safety verdict, no flags is not a guarantee), and cost (0.0050 USDC per call, always paid). This is rich behavioral context well beyond 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?

The scope constraint ('risk flags ONLY') is front-loaded, followed by concrete examples, the sibling routing, and pricing. Every sentence carries information and no sentence is wasted.

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, so the description must convey return content. It enumerates flag categories and on-chain facts, states what it does not provide, and points to the alternative for broader checks. This is complete enough for an agent to 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?

The tool has one required parameter whose schema description coverage is 100%. The description repeats the chain and token type already in the schema but adds no further syntax, format, or validation detail. Baseline 3 is appropriate when the schema fully documents the only parameter.

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

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

The description states a specific action (return token risk flags and on-chain facts) and resource (ERC-20 on Base), lists concrete flag categories, and explicitly distinguishes itself from token-due-diligence. An agent can tell what it does 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?

It names the sibling alternative (token-due-diligence) and the exact condition that selects it (full check with contract/proxy facts and pool liquidity). It also sets the expectation that no flags is not a guarantee, which is an important usage caveat.

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 useful non-schema context: the exact cost (0.0060 USDC per call) and the fact that payment is always taken ('premium: always paid'). It stops short of describing freshness, caching, or failure behavior, so a 4 rather than 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?

Front-loaded with the bundle contents, then the routing guidance, then pricing; each sentence earns its place. Slightly dense with parenthetical enumerations, but 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?

With no input parameters, no output schema, and annotations carrying the read-only/open-world profile, the description supplies everything needed to call it correctly: what it returns, when to choose it, and its cost. Nothing material 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 there is nothing for the description to clarify; the baseline for a parameterless tool is 4. The description correctly consumes the call with no argument guidance 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?

States a specific resource (a bundled Base market snapshot of gas and WETH/USDC DEX pricing), enumerating the exact components returned (base fee, priority-fee percentiles, congestion, spot price, gross spread) and the venues queried. It is clearly distinguishable from the individual gas-optimizer and dex-arbitrage siblings it aggregates.

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 states when to use it (want both gas and DEX pricing in a single cheaper call), when not to (do not also call gas-optimizer or dex-arbitrage), and the alternative condition (prefer individual tools if you need only one). This is a complete routing instruction.

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?

Beyond the readOnlyHint/openWorldHint annotations, it discloses error behavior ('Tokens with no pool return an error entry'), the pricing model and that the premium is always paid, and the resolution source for each price. These are behavioral traits an agent could not derive from the 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?

A single dense paragraph that front-loads the core capability, then the alternative-routing rule, then cost. Every clause carries distinct information (scope, source, error case, price, limit) with no padding.

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 no-output-schema tool, the description covers what the agent needs: batch size ceiling, data source, failure mode for pool-less tokens, and cost implications. Nothing required to invoke or interpret 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 100% and there is only one parameter, so the schema already documents tokenAddresses and its max-15 constraint. The description repeats the batch limit rather than adding format or edge-case detail beyond the schema, 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+resource ('on-chain USD spot price') with explicit batch scope ('up to 15 ERC-20s in one call') and the data source (deepest Uniswap v3 pool vs USDC/WETH). It distinguishes itself from the sibling token-spot-price by naming it directly.

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 an explicit selection rule: 'Use this for 2+ tokens; for a single token use token-spot-price (cheaper).' The alternative and the condition that selects it are both stated, leaving nothing 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 cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuinely non-obvious context: the result is deliberately approximate because v3 uses concentrated liquidity, the data comes from on-chain pool depth, and the call costs 0.0050 USDC and is always billed even on failure. Missing only rate limits or latency expectations.

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

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

Three sentences, front-loaded with what is computed and for which pair/venue, followed by accuracy caveat and pricing. No filler or 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?

With no output schema, the description still conveys the return nature (a price-impact/slippage estimate, approximate by design) and the cost to invoke. It could be slightly more explicit about the return unit (percentage vs. bps), 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% and the single parameter is fully documented there (range 100-5,000,000, default 10000). The description's phrase 'given USD size' restates the schema without adding syntax or format detail, 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: an estimated price impact/slippage for a WETH/USDC trade of a given USD size on Uniswap v3, sourced from on-chain pool depth. This is clearly distinguishable from siblings like token-spot-price, liquidity-health, or dex-arbitrage 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?

Provides implied usage context ('useful for MEV/execution bots before trading') and a caveat about which signals are appropriate (order-of-magnitude only). However, it never names an alternative tool or states when NOT to use it, leaving the agent to infer routing against the many sibling price/liquidity 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 only declare readOnlyHint and openWorldHint, so the description adds real value: it discloses the data source (PoolCreated events), the fixed price of 0.0050 USDC per call, that it is 'premium: always paid' (cost incurred even on empty results), and the trust caveat about new pools. It stops short of describing latency or result-volume behavior.

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

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

Three short sentences, all front-loaded: what it returns, the critical trust warning, then cost. Every sentence earns its place with 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?

There is no output schema, and the description does name the return fields (token symbols, fee tier, block), the data source, and the cost model, which is sufficient to call it correctly. It leaves pagination/window behavior details to the schema, which documents them adequately.

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 both parameters (limit 1-30, windowBlocks 50-3000) fully documented in the schema. The description adds no extra meaning about these parameters, 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?

It states a specific verb and resource — newest Uniswap v3 pools created on Base via PoolCreated events — plus the returned fields (token symbols, fee tier, block). This clearly distinguishes it from siblings like token-due-diligence or liquidity-health.

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 caveat 'A new pool does not imply a legitimate token' implies when this tool is appropriate and warns against naive use, but no alternative tool is named and no explicit when-to-use/when-not guidance is given. Usage is implied 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 only cover readOnlyHint and openWorldHint; the description adds two behavioral facts they don't: the payment model ('0.0100 USDC per call (premium: always paid)') and an interpretive caveat ('Objective signals, not a verdict'). The pricing disclosure is material for an agent deciding whether to invoke, which raises it above the annotation baseline.

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?

Front-loads the bundled nature first, then routing guidance, then cost. Three dense clauses with no filler. Slightly compressed syntax ('(= liquidity-health)') but every element 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 single-param read-only tool with no output schema, the description still previews the return content (risk flags, contract facts, pool liquidity in USD) and flags the premium cost, which is everything an agent needs 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 single tokenAddress param is already fully documented in the schema (ERC-20 address on Base). The description adds no param-level syntax, format, or constraint beyond what the schema provides, 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 states a specific verb+resource ('FULL token check (BUNDLE)') and enumerates exactly what it aggregates: GoPlus risk flags, contract/proxy/owner facts, and Uniswap v3 pool liquidity in USD. It explicitly names the sibling tools it subsumes (liquidity-health, contract-profile), so an agent can distinguish it without opening any 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 gives an explicit selection rule: 'Use this instead of calling liquidity-health and contract-profile separately; use the individual tools only if you need just one aspect.' Both the when-to-use and the when-to-use-the-alternative conditions are stated, leaving nothing 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 cover only readOnly/openWorld, but the description adds the price source (slot0, deepest pool), what it returns (pool/fee tier, USD depth), the absence of an off-chain feed, a manipulation caution, and per-call cost with a free first call. This is substantial context beyond 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?

Purpose is front-loaded, followed by caveats, alternative routing, and cost. Every sentence carries signal, though the middle clause is dense enough that it reads slightly packed rather than cleanly 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?

No output schema exists, but the description names the returned fields (pool/fee tier used and USD depth), the data source, and the cost model, which is everything an agent needs to invoke it correctly and interpret the result.

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, and schema description coverage is 100%, so the schema already fully documents tokenAddress. The description reinforces 'single ERC-20 on Base' but adds no syntax or format 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+resource ('on-chain USD spot price for a single ERC-20 on Base') and pins the data source (deepest Uniswap v3 pool vs USDC/WETH, slot0). It explicitly distinguishes itself from the sibling multi-token-price, 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?

Names the alternative tool and the exact condition that selects it ('To price MANY tokens at once, use multi-token-price instead'). Adds the thin-pool manipulation caveat as a usage warning, leaving little 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 only declare readOnlyHint and openWorldHint; the description adds real behavioral context beyond them: the pay-per-call cost (0.0040 USDC, always paid) and the fact that only a curated token list is covered, so exotic holdings are omitted. It also states the valuation method (on-chain Uniswap v3). It does not address behavior for empty wallets or unsupported tokens, 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?

Two sentences, front-loaded with scope and coverage before cost and return shape. Dense but every clause carries information; the parenthetical token list is long but necessary to define the coverage limit.

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 naming the return shape (per-token amounts, USD values, total). Chain scope, token coverage, valuation source, and price are all present, leaving only edge-case behavior (empty wallet, unpriced tokens) unspecified.

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

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

Schema description coverage is 100% for the single userAddress parameter, so the baseline is 3. The description's only added nuance is that the address is expected to be a Base wallet, which is marginal beyond the schema's own format hint.

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 resource (a wallet's portfolio on Base) with an explicit component list (native ETH plus USDC, WETH, cbETH, cbBTC, DAI, USDbC) and the valuation source. This cleanly separates it from the price-oriented siblings (token-spot-price, multi-token-price) and from whale-wallet-tracker, which implies monitoring rather than a one-shot snapshot.

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 chain scope (Base), the curated token set, and the explicit cost make the intended use case inferable, but the description never states when to pick this over token-spot-price or multi-token-price, nor any exclusions (e.g. non-Base addresses). Usage is implied rather than directed.

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 (readOnlyHint=true, openWorldHint=true), and the description adds genuinely useful context the annotations do not: the data source (confirmed Transfer logs only, so no pending txs) and the cost model (0.0050 USDC per call, premium always paid). It does not describe latency or pagination, so it stops 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 dense sentence that front-loads the core purpose (large USDC transfers on Base) before the data source, returned fields, and price. It is efficient, though the packed clause list makes it slightly harder to scan than it could be.

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, and it discloses the paid-call cost, which is critical for an agent to avoid surprise spend. Minor gaps remain around latency expectations and whether results are a one-shot snapshot or streamed.

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 both parameters are fully documented in the schema, including ranges and defaults. The description only echoes the default window (~300 blocks) without adding format or semantics beyond what the schema already states, so the baseline of 3 applies.

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

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

The description names a specific verb+resource: scanning confirmed Transfer logs for large USDC transfers on Base, and it enumerates the returned fields (amount, sender, receiver, tx hash, block). It is clearly distinguishable from portfolio-style siblings, but it never explicitly contrasts itself with any sibling tool 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?

There is no guidance on when to reach for this tool versus alternatives such as wallet-portfolio or market-snapshot. The description implies a monitoring use case through the word 'Tracker', but an agent gets no explicit conditions, exclusions, or routing advice.

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