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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and data-source profile is covered. The description adds useful context that the output combines quantitative metrics with 'plain-language flags', but says nothing about latency, rate limits, caching, or how stale the market snapshot may be — relevant for a market-health call on an open-world data source.

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

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

One dense sentence front-loads the purpose and then lists the computed metrics after a colon, so nothing is wasted. The framing clause 'the way a Bactory agent would before proposing an action' is slightly decorative, but it earns its place by signaling workflow position.

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

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

With no output schema, the description carries the burden of describing returns, and it does name both halves of the output: metrics and plain-language flags, with the metric categories enumerated. An agent still cannot predict the exact field names or flag semantics, but it has enough to decide whether this tool answers its question.

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

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

There is a single required parameter with 100% schema description coverage, including a 0x address pattern, so the schema does the heavy lifting. The description adds nothing about the address beyond what the schema states (token contract on Base), which is the expected baseline here.

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 composite analysis over a specific resource (a token's Base market) and enumerates the exact metrics computed: liquidity depth and its spread across pools, volume-to-liquidity, 24h volatility, and cross-pool price divergence. That is far more specific than the sibling read tools (get_asset_pools, get_price_history, list_top_markets), though it never explicitly names which sibling it supersedes for a given question.

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

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

The phrase 'the way a Bactory agent would before proposing an action' situates the tool in a pre-proposal workflow, which implies when to reach for it. However, it gives no explicit when-not condition and never names alternatives such as get_asset_pools or get_price_history for an agent that only needs raw pools or price history rather than an aggregate health read.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds genuinely useful behavior beyond that—it is an offline simulation, and it enumerates the check order (suspension, pause, rate limit, sequencer/oracle freshness, approval, per-action limit, reserve/allocation). It stops short of saying what a failing result looks like or whether all checks run or short-circuit.

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 what the tool does, then when to use it, then the mechanics. Dense but every clause carries information; 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?

For a 15-parameter, no-output-schema simulation tool, the description covers the core intent and the check pipeline but omits the shape of the result (pass/fail per check, error reasons) and the meaning of roughly half the inputs. Adequate but with clear gaps an agent would have to guess at.

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 only 40% across 15 parameters, and the description compensates for part of that by explaining that amounts are integer strings in the token's smallest unit and by mapping reserve/per-action/existing-allocation concepts to inputs. But the boolean and oracle-freshness toggles (sequencerUp, agentSuspended, strategyApproved, oracleMaxAgeSeconds) receive no added meaning, leaving a real coverage 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 and resource: it runs a proposed treasury action through AgentGuard's checks offline against caller-supplied market state. Clear on its own, but it never acknowledges the sibling `preview_agent_proposal`, which by name appears to overlap heavily, so an agent cannot confidently distinguish the two from the description alone.

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 two concrete use cases: testing a proposal before a market is deployed, and explaining why the guard would reject one. However, it offers no explicit exclusion or alternative-routing guidance against `preview_agent_proposal`, which is presumably the closest 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 already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description usefully adds what data surfaces (strikes, rate limit, accepted/rejected counts), but says nothing about authentication, pagination, or freshness of the on-chain state.

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 with the primary read scope stated before the optional agent lookup. No filler, though it is a dense sentence that merges return-value detail into the purpose statement.

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

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

With no output schema, the description correctly takes on the burden of naming returned fields, and it flags the agent lookup as optional. The main gap is the undocumented network parameter and no indication of how large the agent's record list can get.

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%, and the description adds real meaning for the agent parameter by naming the record fields it returns, and clarifies that guard is the deployed contract. The network parameter (base vs base-sepolia) is left unexplained in both description and schema, so compensation is partial.

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 ('Reads') and resource ('a deployed AgentGuard') and enumerates the returned data (market, proposal count, oracle settings, agent record). It is distinguishable from siblings like preview_agent_proposal and check_agent_proposal, though it never explicitly contrasts itself with them.

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

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

The word 'optionally' implies that supplying an agent address widens the read to that agent's record, which hints at usage. However, there is no explicit statement of when to use this versus the sibling proposal tools, no prerequisites, and no exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description usefully signals that this is a multi-metric aggregate read (rather than a single value), but it says nothing about auth requirements, rate limits, or what happens with a non-token address.

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

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

A single front-loaded sentence that names the resource first and then the payload. There is no filler and nothing that could be trimmed without losing information.

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

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

For a read-only, single-parameter tool with no output schema, the description carries the important job of telling the agent what comes back (price, liquidity, volume, market cap, top pools) and constrains it to Base tokens. It is largely complete, with only cross-sibling routing left 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?

With one parameter and 100% schema coverage, the schema fully documents the address field and its 0x pattern. The phrase 'for a Base token' reinforces that the address must be a token on Base but adds no syntax or format 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?

The description names the specific resource (a Base token) and enumerates the returned data categories: price, liquidity, 24h volume, market cap, top pools. That makes the tool's scope clear without opening the schema, though it never explicitly distinguishes itself from overlapping siblings like get_asset_pools or get_oracle_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?

There is no when-to-use or when-not-to-use guidance, despite several near-overlapping siblings (get_asset_pools for pool-only data, get_oracle_price for price-only, get_price_history for time series). The agent must infer that this is the aggregate overview call from the field list alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds useful value by enumerating the returned metrics (liquidity, volume, fee tier, 24h change), but says nothing about result size, pagination, or ordering despite 'Every DEX pool' implying a potentially unbounded list.

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

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

A single front-loaded sentence with no wasted words; the resource scope comes first and the returned fields follow. It reads as a noun fragment without an explicit verb, which is minor but slightly less crisp than a full directive.

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

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

With no output schema, the description correctly compensates by listing the return fields, and the sole parameter is fully specified in the schema. The main remaining gap is that a tool returning 'every' pool for a token gives no hint about volume of results or limits.

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 address parameter is fully documented in the schema with a pattern. The description only implicitly ties the input to 'a token', adding no format or constraint detail beyond the schema, 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 names a specific resource ('Every DEX pool on Base that trades a token') and the fields returned, which cleanly separates it from singular siblings like get_pool and get_asset. It does not explicitly name those siblings, so differentiation is inferred from the plural 'every' rather than stated.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as get_pool for a single pool or search_assets for asset discovery. The usage context is only implied by 'that trades a token'.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the external-read safety profile is covered. The description adds that it hits two live on-chain feeds (price + sequencer uptime) and that it is a dependency of AgentGuard, which is useful context, but it omits failure modes, rate limits, and what a stale feed means for the caller.

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 that front-load the primary read and follow with the secondary feed and the downstream consumer. No filler or redundancy.

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

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

With no output schema, the description does not say what is actually returned — a price value, an update timestamp, and/or a freshness verdict against maxAgeSeconds. For a tool whose whole stated purpose is a freshness check, that return-shape ambiguity is a real gap, though annotations and schema inputs are otherwise adequate.

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%; feed and maxAgeSeconds carry schema descriptions, and network is constrained by an enum. The description confirms the ETH/USD default and Base network but adds no syntax, format, or semantics beyond the schema, so the baseline of 3 applies.

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

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

Names a specific verb (reads), a specific resource (Chainlink price feed on Base, L2 sequencer uptime feed), and defaults (ETH/USD). This is clearly distinguishable from data-heavy siblings like get_price_history or analyze_market, which are not oracle reads.

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?

Implies usage by tying it to 'AgentGuard's oracle-freshness check', which tells the agent when this tool is relevant. However, it names no alternatives and gives no explicit when-not guidance (e.g., use get_price_history for historical OHLC data).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile and external-data nature are covered. The word 'Live' usefully signals that this returns current on-chain state rather than cached/historical data, but nothing is said about rate limits, latency, or what happens with an unknown/invalid address.

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

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

A single six-word sentence with zero filler and the key qualifier ('one', 'Live') front-loaded. It is efficient, though it is so terse that it verges on under-specification rather than true 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?

With no output schema, the description should carry more about the returned shape, and it does not; neither does it route the agent away from the plural sibling get_asset_pools. For a trivial one-param read tool this is minimally adequate but leaves real gaps.

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

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

Schema coverage is 100%: the single 'address' parameter is fully documented with a regex pattern and the note 'Pool address on Base'. The description adds nothing beyond that, so the baseline 3 for schema-documented params 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 fragment 'Live state of one Base DEX pool' identifies the resource (a single Base DEX pool) and the nature of the return (current/live state), so an agent can roughly tell it fetches one pool rather than many. But there is no verb, no mention of the address input, and no explicit differentiation from the sibling get_asset_pools, which is the tool most likely to be confused with it.

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

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

There is no when-to-use guidance at all. Nothing says to prefer this over get_asset_pools (plural) or list_top_markets when the agent already has a pool address, and no preconditions or error expectations are stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact — results are ordered oldest first — but says nothing about the default window, default candle count, or how limit and timeframe interact.

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 nine-word sentence with the resource first and the ordering constraint second; there is no filler. 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 output schema, a 3-parameter tool, and low schema coverage, the description leaves real gaps: what a 'day' candle window covers, how many candles are returned by default, and why to choose this over get_oracle_price or get_trades. It is not enough to call the tool confidently.

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 only 33%: only 'pool' is documented, while 'limit' and 'timeframe' have no schema descriptions. The description does not compensate — it never explains that limit caps the number of candles or what day/hour/minute aggregation means, so two of three parameters remain dark.

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 (OHLCV candles) and scope (a Base pool), which is enough to separate it from get_trades or get_oracle_price. It does not explicitly name or contrast with any sibling, so it stops short of a 5.

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

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

There is no when-to-use guidance and no mention of the alternatives (get_oracle_price for a single price, get_trades for raw fills). The agent must infer that this is the historical-candle tool purely from the resource name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context by naming the returned fields and implying recency ordering via "Latest", but says nothing about pagination, refresh cadence, or how far back "latest" reaches. Adequate against the annotation baseline, not rich.

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 names the resource, scope (Base pool) and return fields with zero filler. Appropriately sized for a simple read tool, though it could fold in one clause about the 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 only two parameters, one required, and no output schema, the description's enumeration of returned fields usefully covers the return shape. However, it leaves the limit parameter and any ordering/pagination behavior unexplained, so an agent lacks enough to call it optimally.

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

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

Schema coverage is only 50%: pool is documented in the schema while limit has no description anywhere. The description's "Latest" hints at ordering, which is tangentially relevant to limit, but it never explains the limit range (1-100, default 20) or whether results are capped. It does not compensate for the coverage 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+resource ("Latest swaps in a Base pool") and enumerates the returned fields (side, USD size, price, tx hash), which clearly separates it from siblings like get_price_history or get_pool. It stops short of naming those siblings explicitly, so it is clear but not sibling-differentiating.

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 you need a pool address to fetch trades but offers no when-to-use guidance, no exclusions, and no mention of alternatives such as get_price_history or analyze_market. An agent must infer the appropriate context on its own.

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 the ranking metric (24h volume), which is genuine behavioral context, but says nothing about result size, refresh cadence, or what 'top' means in practice.

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

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

One front-loaded fragment with zero waste, but it is under-specified rather than efficient. Nothing is padded, yet the brevity costs clarity on scope and return shape.

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 an undocumented parameter and no output schema, the description should clarify what a 'market' is, the meaning of the limit, and how results are shaped. Annotations cover only the read-only/open-world profile, so the remaining gaps are unfilled.

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 0% and the single parameter (limit, default 10, max 20) is undocumented in both schema and description. The description does not compensate at all for this gap, leaving the agent to infer how many markets are returned.

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

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

Names the resource (Base pools) and the ordering criterion (24h volume), which is more specific than a bare title restatement. It does not distinguish itself from siblings like get_asset_pools or analyze_market, and there is no explicit verb, so it stops short of a 5.

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

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

No indication of when to call this versus get_asset_pools, analyze_market, or the other pool-related siblings. The agent gets no context about prerequisites, when the ranked view is preferable, or any exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is partly covered. The description adds real value beyond them: it names the underlying contract method and clarifies that no transaction is signed or broadcast, which is exactly the behavioral fact a caller needs before invoking a preview.

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

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

Two tight sentences with no filler; the core behavior (simulate, don't execute) is front-loaded ahead of the safety reassurance. Slightly terse for the number of required parameters, but nothing 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?

For a read-only simulation tool there is no output schema, so the description carries the burden of explaining what preview returns (which checks ran, pass/fail, reasons) — and it omits this. It also leaves the check_agent_proposal ambiguity unresolved, though it is adequate on the safety profile.

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?

Seven parameters, six required, with only 57% schema description coverage (amount, kind, and network have no descriptions at all). The description supplies no parameter meaning whatsoever, so it fails to compensate for the coverage gap and adds nothing beyond the schema.

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

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

States a specific verb and resource ('preview' an agent's proposed treasury action) and pins it to a concrete contract call (AgentGuard.preview on a deployed guard). It does not, however, distinguish itself from the near-identical sibling 'check_agent_proposal', leaving the agent to guess which one to pick.

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?

'Runs every check ... without executing it. Nothing is signed or sent' implies a dry-run/simulation use case, which is useful implied guidance. But there is no explicit when-to-use statement and no routing against the similar sibling check_agent_proposal.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds useful output context ('each token with its most liquid pool'), but says nothing about result limits, ordering, pagination, or empty-result behavior for a search endpoint.

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

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

Two sentences, front-loaded with the search domain and immediately followed by the return contract. No filler or restated boilerplate.

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 must carry the return contract and it does at a high level (tokens plus most liquid pool). Missing are result caps/pagination and tie-breaking when a query matches multiple tokens, which are the only real gaps for a one-parameter search tool.

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

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

Schema description coverage is 100% and the schema already gives the example "AERO". The description restates the same three accepted key types without adding format rules, address normalization, or ambiguity handling, 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 (Find/search), resource (tokens on Base) and the three lookup keys (name, ticker, contract address), plus the return shape. It does not explicitly distinguish itself from the singular sibling get_asset, so an agent must infer that this is the discovery path for unknown identifiers.

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

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

Usage is implied by the accepted query forms (partial name/ticker/address), which suggests discovery when the exact asset is unknown. There is no explicit when-to-use, when-not, or pointer to get_asset/get_asset_pools for follow-up, so the agent must infer routing.

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