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

The description goes well beyond the read-only/idempotent annotations by disclosing the exact comparison algorithm: same split per NFT, subtracting existing votes, rounding per NFT, preserving per-token partial subtotals, and fixing own votes and deposits for sensitivity. It also clarifies that the hypothetical sensitivity is not a forecast, which is important for correct interpretation.

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 main capability is front-loaded and the caveats are grouped into short, purposeful sentences. Some phrasing, especially 'Evidence includes independent full-allocation estimates: use scenarios for split results,' is dense and less clear, but overall there is little wasted text.

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

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

For a comparison tool with an output schema and safety annotations, the description covers the algorithm, scope, and limitations well. It is incomplete mainly because maxRewardTokens is left unexplained and the pool-count mismatch with the schema creates ambiguity.

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?

With 0% schema description coverage, the description carries most of the semantic burden and does so well for the key parameters: scenarios are basis-point splits, pools are explicit and limited, and tokenIds are normal veNFTs. However, maxRewardTokens is not mentioned, and the stated '1–5 explicit pools' appears inconsistent with the schema's pools maxItems of 8.

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

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

The description opens with a specific verb and resource, then quantifies the scope: 1–4 basis-point splits, 1–5 pools, 1–4 veNFTs, one block. It clearly differentiates this from sibling tools by stating it is not an optimizer and does not provide USD ranking or eligibility.

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

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

The description gives explicit when-not guidance: it is not a forecast, it uses fixed hypothetical sensitivity scenarios, and it lacks optimizer, USD ranking, eligibility, and guaranteed earnings. It does not explicitly name an alternative sibling tool for those needs, so it stops short of fully explicit alternative 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/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral value beyond that: deterministic output ordering ('Preserves input order'), explicit null semantics for missing data ('Unknown data stays null'), single-block snapshot semantics, and a disclaimer that no ranking is produced.

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, each carrying distinct information (what is compared, ordering/null behavior, what is excluded). Front-loaded with the core operation and free of 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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. The description supplies the remaining essentials: input cardinality, uniqueness, ordering guarantees, null handling, and scope exclusions.

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?

With only one parameter at 0% schema description coverage, the description carries the semantic load and does so: it states the count bounds (2–16, matching minItems/maxItems), the 'distinct' uniqueness requirement the schema does not enforce, and that input order is preserved in output. Address format is left to the schema's regex.

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 (Compare), a bounded resource (2–16 distinct Aerodrome pool addresses), and enumerates exactly what is compared (Voter weights, protocol weight shares, gauge registration/liveness, reward contracts). This clearly separates it from the wallet- and protocol-oriented siblings, which none of them do.

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 sets explicit boundaries on what this tool is for ('no yield, liquidity or profitability ranking') and constrains the input shape ('2–16 distinct pool addresses ... at one Base block'), giving clear context for when it applies. It does not, however, point to an alternative tool for the excluded analyses, so it stops short of explicit when-not/alternative 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?

The description adds substantial behavioral context beyond the readOnlyHint, openWorldHint, and idempotentHint annotations. It discloses default state ('Default DRAFT'), caller assertion semantics ('USER_SELECTED is a caller assertion, never a transaction or recommendation'), and persistence behavior ('No disk writes; save privately with the local save-card command. Never publish cards.'). There is no contradiction with 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 description is four tightly written sentences with no filler. It front-loads the core purpose, then states the essential usage caveats and persistence rules. Every sentence carries meaningful, non-redundant information.

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

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

The description covers status defaults, caller assertion semantics, disk-write behavior, and the save-card alternative, which is strong contextual coverage especially given the annotations and output schema. The main gap is the undocumented meaning of the required allocation object, which relies on the schema's structural names. Overall, an agent can likely select and invoke the tool correctly in most cases.

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?

With 0% schema description coverage, the description must compensate, but it only addresses selectedScenario and reason. The required allocation parameter, including its nested pools, tokenIds, scenarios, and weightsBps, receives no semantic explanation in the description. The schema provides structure but not the meaning needed to construct a valid allocation.

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: 'Return an exportable decision card with allocation evidence, sensitivity and content checksum.' It clearly identifies the tool's output and purpose. It does not explicitly contrast with sibling tools, but the decision-card deliverable is distinct enough to be recognizable.

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

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

The description gives explicit conditions on when to set fields: 'Set selectedScenario and reason only when explicitly chosen by the user.' It also provides guidance on what not to do and an alternative action: 'No disk writes; save privately with the local save-card command. Never publish cards.' It does not name sibling tools as alternatives, but it offers clear context and 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 indicate read-only, idempotent, and non-destructive behavior. The description adds a useful caveat that registration order is not token listing or pool creation time, and instructs to preserve partial rows and pagination coverage—valuable beyond annotations.

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

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

The description is a single sentence that front-loads the primary purpose and adds necessary caveats without excess wording. It could be more structured but is concise and clear.

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 tool with three parameters and no schema descriptions, the description must explain pagination mechanics. It fails to clarify how sinceIndex/beforeIndex work or that limit sets page size. An agent cannot reliably use the tool without guessing, despite the 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?

Schema description coverage is 0% and the description does not explain the meaning of sinceIndex or beforeIndex. It mentions 'bounded pages' and 'pagination coverage' but does not define cursor parameters or explicitly tie limit to page size, leaving the agent to infer from names alone.

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

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

The description clearly states the verb 'browse' and the resource 'official Voter pool registrations', with specifics on ordering (newest index first) and data included (token pair metadata and gauge state). It distinguishes from siblings by focusing on the pool directory rather than positions, rewards, or wallet data.

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

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

Provides clear context: this tool is for browsing bounded pages of official registrations, not general token listings. However, it does not explicitly name alternatives or state when not to use it, only implies that ordering differs from other sources.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuine context by noting the read happens 'at one block,' implying a consistent point-in-time snapshot, but says nothing about freshness, caching, 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 front-loaded sentence that enumerates the returned data without filler or redundancy. Every clause carries 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 parameters and no output schema, the description must convey what the call yields, and it does so by listing the five data points. It is complete enough to invoke correctly, though it stops short of explaining return structure or error conditions.

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 has nothing to document and the baseline of 4 applies. The description appropriately adds no parameter information because none is needed.

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

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

The description uses a specific verb ('Verify') plus an enumerated resource set (contracts, block, vote totals, pool count, epoch window), so the agent knows exactly what this tool surfaces. It doesn't explicitly name which sibling it differs from, but the protocol-wide scope clearly contrasts with the wallet/voting siblings' narrower focus.

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 the six sibling tools, nor any stated prerequisites or exclusions. Usage is only implied by the content it reports.

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?

Even though annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, the description adds meaningful operational limits: market data is fetched from Dexscreener only for token addresses, includeMarket=false disables it, research claims are never verified, and no execution guarantees are made. This is far more than the annotations convey.

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 dense but well-structured, front-loading the core comparison purpose before layering in retention mode specifics, external data behavior, and limitations. Every sentence adds information without repeating 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?

For a complex 9-parameter tool, the description covers the most important execution-relevant semantics, external data dependencies, research-note handling, and explicit non-guarantees, while an output schema covers result expectations. A small gap remains around preferredTokens and maxRewardTokens behavior, but the description is largely complete and actionable.

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?

With only 22% schema coverage, the description compensates well by explaining key parameter meaning: keepBps applies to each selected token's units, includeMarket=false skips Dexscreener, researchNotes are unverified client claims, and selected token addresses are retained in HOLD_SELECTED/MIXED modes. It does not clarify slippageBps, maxRewardTokens, or preferredTokens, so it is not a full substitute for schema descriptions.

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

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

The description opens with a specific action and resource: comparing 1–3 independent full-veNFT reward allocations across USDC, HOLD_SELECTED, and MIXED modes. The title and details about retention scenarios clearly separate this from sibling tools like wallet rewards or voting incentives.

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 clear context for when to call this tool and what it is for, including mode-specific behavior, external Dexscreener fetching, and explicit non-goals such as 'no net-after-gas, guaranteed sellability, growth score or execution.' It does not explicitly name alternative sibling tools or state when not to use them, 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 readOnly, idempotent, and non-destructive, so the description adds value by detailing the 'at one block' snapshot, the independence of each pool's hypothetical allocation, and the explicit disclaimer that no ownership/eligibility or guaranteed payout is claimed. This goes 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 description is four sentences, front-loaded with the core read action, then the optional estimation, then disclaimers. No fluff; each sentence serves a purpose.

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

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

The output schema covers return values, and annotations cover safety. However, the description does not explain the maxRewardTokens parameter, and it does not mention how the block is chosen (though it says 'at one block'). For a tool with this complexity, the missing parameter semantics is a notable gap, so it's not fully complete.

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

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

Schema coverage is only 25% (only additionalVoteRaw has a description). The description text clarifies pools and veNFTs (tokenIds) and hypothetical votes (additionalVoteRaw), but maxRewardTokens is not explained anywhere. The description partially compensates for the low schema coverage but leaves a gap.

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

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

The description clearly states the tool reads deposited bribes and fees for 1-8 explicit pools at a specific block, and optionally estimates rewards for additional votes or full allocation of veNFTs. It is specific about the action, resource, and scope, and the disclaimers (no ownership/eligibility, no APR) help differentiate it from wallet-focused 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?

The description gives clear context on what the tool does (read bribes/fees and estimate hypothetical rewards) but does not explicitly state when to use it over siblings like aerodrome_voting_position or aerodrome_wallet_rewards. It implies usage for scenario analysis but lacks explicit alternatives or exclusions.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds a genuinely useful behavioral detail beyond the annotations: when no tokenIds are passed it falls back to configured token IDs, and it discloses the breadth of returned data.

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

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

Two tight sentences with no waste, the primary read action front-loaded and the fallback behavior stated second. 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?

There is no output schema, and the description compensates by enumerating the returned fields, which is what an agent needs to decide to call it. A brief note on whether results require a wallet/address context or how multiple token IDs aggregate would make it fully 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?

With a single parameter at 100% schema coverage the baseline is 3, but the description adds meaning the schema lacks: the tokenIds list is optional and defaults to a configured set when omitted. That defaulting behavior is real semantic value beyond the schema's 'Optional' label.

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 ('Read') and a well-scoped resource (veNFT voting position), then enumerates the exact data returned: voting power, pool allocations, pool weight shares, gauge liveness, and epoch timing. It is clearly distinguishable from siblings like wallet_rewards or protocol_status, though it does not explicitly name or contrast with any sibling 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?

The description implies when the tool applies (checking a veNFT's voting state) but gives no explicit when-to-use guidance or alternatives versus the other aerodrome_* tools. The only actionable direction is the fallback rule about configured token IDs, which is usage-adjacent but not a selection criterion.

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, idempotentHint, and non-destructive. The description adds meaningful behavioral context: it verifies protocol logs against receipts and ERC-20 transfers, returns gaps, and follows a specific retry pattern (PARTIAL → retry same page, else nextFromBlock). It also states the scope remains unchanged, which is important for pagination. This goes beyond the annotations and provides transparency about how the tool behaves during a multi-page walk. No contradiction with annotations.

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

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

The description is four sentences, each carrying distinct value: scope, verification behavior, outputs, and exclusions/pagination. It is front-loaded with the primary action and immediately states the resource and its boundaries. No filler or repetition; every clause earns its place. This is exemplary conciseness.

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

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

The description covers the tool's scope, verification, outputs, pagination, and exclusions. The output schema and annotations already provide return types and safety profile. However, it does not explicitly explain the wallet parameter (beyond the 'configured wallet' mention in tokenIds schema) or the exact meaning of blockSpan, though these are secondary. For an agent, the description gives enough to call the tool correctly across pages, but a tiny bit more on the wallet override and blockSpan would push it to a 5.

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 67% (4 of 6 parameters have descriptions). The description adds contextual meaning by tying parameters to the tool's behavior: 'selected veNFT rebases' relates to tokenIds, 'explicit voting-pool reward receipts' to pools, and 'fixed toBlock'/'nextFromBlock' to toBlock/fromBlock. It also clarifies that history is paginated by block (complementing fromBlock's schema description). While it doesn't elaborate on blockSpan or wallet (both lacking schema descriptions), the description does not duplicate schema info and provides a cohesive usage model. Given the high coverage baseline of 3, the added context justifies a 4.

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

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

The description opens with a specific verb and resource: 'Read a bounded Base block page of wallet escrow deposits/withdrawals, selected veNFT rebases and explicit voting-pool reward receipts.' It further clarifies outputs (per-token page sums, event links, gaps, holdings at fixed toBlock) and explicitly excludes lifetime discovery, LP accounting, cost basis, and net profit, which distinguishes it from sibling tools like aerodrome_wallet_rewards, aerodrome_wallet_snapshot, and aerodrome_wallet_report. This is a precise and unambiguous statement of purpose.

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

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

The description gives clear usage boundaries: it is for a bounded page of history, not lifetime discovery, and explicitly excludes LP accounting, cost basis, and net profit. It also provides pagination guidance: 'On PARTIAL retry the same page; otherwise continue with nextFromBlock and unchanged scope/toBlock.' While it doesn't name specific alternative tools, the exclusions implicitly route the agent to other tools for those tasks, and the pagination instructions are concrete. This is more than minimal guidance, though it stops short of explicitly naming siblings.

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?

Although annotations indicate idempotentHint=true and openWorldHint=true, the description adds valuable context beyond these: it explains the atomic commit of report and baseline, partial report saving behavior, and that the tool writes local history but does not mutate blockchain state. This aligns with annotations (idempotent, open world) and adds specific nuances around retries and snapshot baselines.

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 dense but highly informative, with each sentence adding key operational detail. It front-loads the core comparison function and then efficiently covers retry semantics, snapshot initialization, atomicity, and interpretational caveats. No filler or redundant content.

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

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

Given the tool's complexity (state comparison, idempotency, atomic commits) and that it has an output schema, the description covers all necessary operational aspects: how to use requestId, what happens on retries, baseline behavior, local vs blockchain state, and how to interpret missing data. It is complete for an agent to correctly select and invoke the tool.

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

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

The description significantly enriches the parameter semantics beyond the schema. While the schema specifies 'requestId' as a UUID with format/pattern, the description explains the functional role: generate a new UUID for a new comparison and reuse it for retries to fetch the saved report. This is critical for correct usage and goes far beyond the schema's type/format 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?

The description clearly identifies the tool's purpose: comparing wallet state (voting/rewards, liquid balances, locks) since the last complete snapshot. It distinguishes itself from siblings by focusing on 'changes since last snapshot' and mentions a caller-generated UUID for idempotent retries, which is unique among the sibling tools.

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

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

The description provides explicit usage guidance: use the same UUID for retries to avoid re-running RPC calls, and use a new UUID for a new comparison. It also clarifies the behavior for old snapshots without assets and emphasizes that missing reward rows are 'unknown, not zero', which guides interpretation of results.

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, idempotent, and non-destructive. The description adds meaningful behavioral context: it reports at one block, includes an English brief, discovers veNFTs from the official escrow, and explicitly excludes total net worth and APR. This goes beyond the annotations and helps the agent understand scope and limitations without contradicting them.

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 well-structured with the core purpose front-loaded, followed by scope, features, and exclusions. It is not overly verbose, though it could be tightened. Each sentence adds information about capabilities or limitations, earning 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?

Given the tool's moderate complexity (3 optional params), the description covers the main behavioral aspects: what it reports, prerequisites, and exclusions. The output schema is present, so return details are not needed. It is complete enough for an agent to decide whether to use it and to call it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds only marginal value: it mentions 'wallet supplied' and 'no veNFT IDs required,' which is already in the schema's wallet description. It does not elaborate on gauges or tokens beyond what the schema provides. No additional semantics beyond schema coverage.

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

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

The description specifies a clear action (discover, report) on a specific resource (wallet overview, veNFTs, balances) and distinguishes it from siblings by explicitly stating exclusions ('no total net worth or APR') and the convenience of not needing config or manual veNFT IDs. An agent can immediately understand this is a one-block wallet 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?

It states that no wallet config or manual veNFT IDs are needed when a wallet is supplied, indicating when it's appropriate. It also hints at limitations ('Preserve partial and managed-position limits; no total net worth or APR') but does not explicitly name alternative tools or provide when-not-to-use guidance. Clear context but lacks explicit routing to siblings.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds valuable context: it clarifies that the operation does not affect RPC, capture, or baseline, and that it is available even during captures and after restart. This goes beyond the annotations and helps an agent understand operational constraints.

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 the primary action front-loaded: 'Retrieve a committed report by reportId'. It then adds two concise clarifications (no side effects and availability) without redundancy. Every sentence earns its place, making it an efficiently structured description.

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

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

For a simple read tool with one parameter and an existing output schema, the description covers the essential operational aspects: it retrieves a committed report, is read-only, and is available under specific conditions. It does not mention error handling or return format, but the output schema presumably covers that. The description is sufficiently complete for an agent to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explicitly explains that reportId is the original requestId, which is a meaningful semantic clarification beyond the raw schema. While it does not detail the UUID format (already in the pattern), this mapping is crucial for correct usage, giving the description significant added value.

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

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

The description clearly states the tool retrieves a committed report by reportId, with the specific resource being a saved wallet change report. It distinguishes itself from sibling tools by focusing on reading a previously saved report rather than creating or modifying data, though it does not explicitly name an alternative.

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

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

The description provides context on when the tool is available (after restart and during another capture) and states it does not change RPC, capture, or baseline. However, it does not explicitly compare against sibling tools or specify scenarios where this tool is preferred over others, leaving some ambiguity for an agent deciding between tools.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral scope beyond that: rewards are claimable, coverage is limited to configured veNFT current votes and explicitly configured gauges, and historical pools are deliberately skipped — a meaningful data-coverage disclosure.

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, and the primary scope statement is front-loaded before the exclusion. 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?

No output schema exists, but the description adequately covers what is returned, so return-value explanation is not required. The gap is parameter behavior: with two undocumented, non-obvious parameters and no annotations covering them, the definition is adequate but not 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 0% and neither parameter is mentioned in the description. maxItems (pagination/limit, 1-200, default 100) and includeZero (whether zero-value rewards are returned) are left entirely unexplained, and the description does nothing to compensate for that gap.

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 ('Read') and two concrete resources (claimable voting rewards for configured veNFT current votes, LP rewards for explicitly configured gauges), so the agent knows exactly what is returned. It does not name or contrast with any sibling such as aerodrome_voting_position or aerodrome_wallet_report, so the 5-level sibling differentiation is missing.

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 clause 'Historical vote pools are intentionally not scanned' implies a usage boundary and tells the agent this is not a historical/backfill query. However, no alternative tool is named and there is no explicit 'use this when X, use Y when Z' routing, so 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it rechecks the block hash before returning (consistency guarantee) and preserves PARTIAL status and historical coverage limits, which are non-obvious behaviors an agent needs to know.

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

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

The description is a single dense sentence followed by two short imperative clauses. It front-loads the core purpose and packs significant detail (block consistency, metadata, status preservation) without wasted words. The final sentence about PARTIAL status and historical coverage limits is terse but meaningful.

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

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

Given the tool has an output schema and annotations covering safety, the description covers the key behavioral guarantees (single-block coherence, block hash recheck, status preservation). It does not explain the two parameters, but they are simple and self-explanatory. The description is complete enough for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description carries the burden for parameter meaning, but it does not explain maxItems or includeZero. However, the parameter names are fairly self-explanatory and the description's mention of 'including token display metadata' and 'historical coverage limits' indirectly relates to includeZero and maxItems. Baseline 3 is appropriate because the description adds some context but does not explicitly document the parameters.

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

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

The description names a specific verb ('Read') and a clear resource: a coherent wallet snapshot at one Base block, enumerating veNFT positions, rewards, balances, lock principal, and token metadata. It distinguishes itself from siblings by emphasizing coherence at a single block and the inclusion of display metadata, though it does not explicitly name a sibling alternative.

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 usage for obtaining a consistent point-in-time snapshot and mentions preserving PARTIAL status and historical coverage limits, which hints at when it is appropriate. However, it does not explicitly state when to use this tool versus siblings like aerodrome_wallet_overview or aerodrome_wallet_report, nor does it state exclusions.

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