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

Annotations already cover readOnly/idempotent/non-destructive/closed-world, but the description adds two things they don't: all results are read at one pinned chain block (a consistent snapshot rather than a series of live reads) and there is no token discovery. That is genuine behavioral context. It doesn't say what happens on invalid or unlisted tokens, or whether the pinned block is the latest.

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 well-formed sentence with the capability first and the exclusion in a trailing parenthetical. No filler and nothing buried.

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

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

For a 3-required-parameter tool with no output schema, the definition covers the core contract (explicit tokens, one pinned block, max 32) which is enough to call it. But it omits token address format, chain_id expectations, and whether the pinned block is fixed at latest, all of which the agent must guess.

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%, so the description must carry parameter meaning. It explains 'tokens' as an explicit caller-supplied list capped at 32 (partly redundant with maxItems: 32) but says nothing about the expected format (contract addresses?), nothing about 'chain_id' (no indication of supported IDs or which registry lists them), and never mentions 'wallet' at all beyond the implication of 'balances'.

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

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

Specific verb ('Read') plus resource ('token balances') with a clear scope: explicitly supplied tokens only, capped at 32, evaluated at a single pinned block. The parenthetical explicitly excludes portfolio discovery, so the agent knows this is not an enumeration tool. It stops short of naming a sibling such as accounts.positions as the 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 phrase 'explicitly provided' and 'no automatic portfolio discovery' implies the caller must already know the token list, which is real usage guidance. However, it never states when to prefer this over accounts.positions or which call to make when discovery is needed, leaving the routing decision implicit.

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 this as a safe, idempotent, closed-world read. The description adds real value by clarifying that a positive result is not an authorization decision ('not an access grant'), which is a behavioral claim annotations cannot express. It still omits what happens when no rules are configured and what the result looks like.

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 compact sentence with the core action front-loaded and a valuable disambiguating caveat at the end. No filler, though the terseness comes partly at the cost of the missing detail noted elsewhere.

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 that evaluates eligibility with no output schema and no parameter documentation, the description never says what is returned (boolean, reasons, rule set used), what 'explicitly configured' means, or how missing configuration is handled. That is a substantial gap for an agent deciding whether its result can be acted on.

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% for both required parameters, so the schema contributes nothing beyond types. The description only indirectly implies a wallet and a chain ('on-chain balances'), with no format, validation, or scoping guidance for chain_id or wallet to compensate.

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 verb (check) and resource (on-chain balances vs. configured Orchard root/LP rules) are stated, so it is more than a restatement of the name. However, the domain terms 'Orchard root/LP rules' are unexplained and the description does not differentiate it from the nearby accounts.balances or policy.evaluate 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 only usage signal is the negative caveat 'not an access grant', which tells the agent what not to conclude rather than when to call this versus accounts.balances (raw balances) or policy.evaluate (policy check). No preconditions, no exclusions, no named alternative.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the single-token vs. portfolio scope constraint, but says nothing about return shape, decimal normalization, or behaviour for unknown tokens, which is the remaining burden for a balance read.

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 filler; the scope qualifier is placed where it matters. It is telegraphic to the point of being slightly ambiguous ('explicitly named' by what key?), but every word 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 should convey what comes back (raw amount, decimals-adjusted, symbol/decimals metadata) and it does not. Annotations cover safety, and the token-type hint helps, but the return contract and chain_id semantics remain gaps for a 3-parameter read 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 0% across three required parameters. The description clarifies only that 'token' may be an ERC20 or LP token, which is genuinely useful; it says nothing about 'wallet' (address format?) or 'chain_id' (which networks, numeric IDs vs. names?), leaving two parameters undocumented everywhere.

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 the balance of an explicitly named token for a wallet. The phrase 'not full portfolio' scopes it against the broader sibling accounts.balances without naming it, so an agent can reasonably distinguish the two, though it stops short of an explicit sibling reference.

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?

'not full portfolio' implies when to prefer this over a portfolio-wide read, but the guidance is negative scoping only. It never names accounts.balances as the alternative, nor states what happens if the token is not held or if an unsupported token type is passed.

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, closed-world, so the safety profile is covered. The description adds the substantive behavioral fact that ranking is based on observed indexed swap counts rather than other metrics, but says nothing about sort direction, tie-breaking, or how many pools are considered.

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 zero filler; the metric definition leads and the disambiguation trail clause follows.

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 ranking tool with no output schema, an agent still needs to know the ordering convention, the meaning of limit, and why chain_id is required. None of that is present, leaving real gaps beyond a one-line purpose statement.

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 there are two parameters, one of them required. The description never mentions chain_id (required, and it scopes the whole ranking) or what limit controls, so it fails to compensate for the undocumented 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 (rank pools) plus the exact ranking metric (observed indexed swap count), which tells an agent this is not analytics.tvl or analytics.volume_fees. It stops short of explicitly naming those siblings, so the differentiation is by metric only.

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

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

Usage is only implied: rank pools when you care about indexed swap activity. The negative clause 'not wallet ELO or APY' rules out a couple of misreadings but does not define when to pick this over analytics.turnover/tvl/volume_fees.

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, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds only a vague validation hint ('known, matching') and says nothing about failure modes when denominators are missing or how results are shaped.

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 filler. Brevity is not the issue here; the missing content is covered under other dimensions.

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 an analytics tool with zero schema descriptions, no output schema, and an undocumented pool/chain_id pair, the description should at minimum define turnover and state the pool scoping rules. It leaves an agent unable to call or interpret 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% for the two real parameters, pool and chain_id, and the description never mentions either. Worse, it references 'volume' and 'TVL denominator', which are not parameters at all, so it adds no usable meaning to 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?

It names the resource (turnover) and a precondition, but never defines what turnover is (presumably volume/TVL) nor how it differs from the sibling metrics analytics.tvl and analytics.volume_fees. An agent can guess the domain but not the exact computation.

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 'only with known, matching volume and TVL denominator' reads as a data-quality caveat, not a routing rule. It never says when to pick this over analytics.tvl or analytics.volume_fees, nor what to do when the denominator is unknown.

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, closed-world behavior, so the safety profile is covered. The description adds real value by disclosing that TVL is derived from verified price/reserve inputs and that USD estimates will be withheld rather than guessed, which tells the agent to expect partial or absent values; however it never says what the response actually looks like when data is missing.

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 compact sentence with no filler, and the integrity constraint is placed prominently. It is efficient, though efficiency comes at the cost of saying almost nothing operational.

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 two undocumented parameters, no output schema, and an ambiguous return type, the description should explain what is returned (a value, a status, or an explanation) and what pool omission means. None of that is present, so an agent cannot reliably predict the result of a call.

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?

Neither parameter is mentioned in the description while schema description coverage is 0%, so nothing explains what chain_id denotes (numeric chain identifier) or how the optional pool narrows the scope from chain-level TVL to a single pool. The description leaves the entire parameter burden to an undocumented schema.

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

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

The verb 'Explain' plus 'TVL availability' signals something, but it is ambiguous whether the tool returns a TVL number, a boolean availability flag, or a narrative explanation. It never names the sibling analytics tools (rankings, volume_fees, turnover) it should be contrasted with, so sibling differentiation is absent.

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 statement of when to call this versus analytics.rankings, analytics.volume_fees, or other analytics siblings, and no prerequisites are given. The only guidance is a negative constraint about not fabricating, which is about output conduct rather than tool selection.

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's one added fact — that indexed coverage may be partial — is genuinely useful caveat context, but it says nothing about aggregation window behavior, pagination, or how gaps manifest.

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 filler; the coverage caveat is placed where it will be read. It is efficient, though arguably too sparse for a tool with three undocumented parameters.

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 and 0% parameter documentation mean the description carries the full burden, and it does not: return shape, aggregation granularity, and parameter behavior are all unstated. Only the partial-coverage warning is provided.

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% across three parameters, and the description supplies no meaning for chain_id (required), pool, or since_timestamp. Without any hint on units, timestamp semantics, or whether pool is optional scoping, an agent must guess.

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 verb ('Aggregate') and a resource ('indexed swap input and fee amounts in raw token units'), so the general intent is graspable. But it never clarifies whether the result is a total, a time series, or per-pool breakdown, and it draws no line against siblings like analytics.turnover or analytics.tvl, leaving overlap ambiguous.

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 named alternative among the many analytics.* siblings. 'Never presume complete coverage' is a caution about results, not a routing hint about when this tool is the right choice.

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 closed-world, so the safety profile is covered. The description adds that data comes 'directly from chain' (on-chain read rather than cache/registry), but does not disclose what happens for non-contract addresses or which metadata fields are returned.

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 filler. Every word carries 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?

Adequate for a simple two-parameter read tool with full safety annotations, but it lacks the metadata fields returned and the behavior for failed lookups, and neither parameter is documented anywhere. It leaves real gaps an agent would want filled.

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 provides no parameter meaning at all. The two parameters (address, chain_id) are guessable from their names, but format, expected chain ID conventions, and address validation are undocumented in both schema and description.

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 ... ERC20 contract metadata', with the qualifier 'directly from chain' adding scope. It is distinguishable in spirit from sibling assets.wrapper_underlying, though neither sibling nor boundary is named.

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 when-to-use or when-not-to-use guidance. The word 'explicit' hints that this reads direct contract data rather than derived/wrapper data, but an agent gets no explicit routing versus assets.wrapper_underlying or registry.verify_contract.

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

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

Annotations already cover read-only, idempotent, closed-world behavior, and the description adds a genuine failure-mode disclosure: unsupported wrappers return "unknown" instead of erroring. It still doesn't say what a probe costs (RPC round-trip, latency) or that "directly" means an uncached on-chain call.

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

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

A single tight sentence with the operation and its caveat front-loaded, no filler. Brevity is achieved but borders on under-specification for a tool with two undocumented parameters.

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 describe what comes back (underlying address? null? the literal "unknown"?) and confirm the address is the wrapper, not the underlying. It only gestures at the unknown case, leaving a two-parameter, output-describing 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 0% and both parameters are undocumented, so the description must compensate and does not. It never clarifies that address is the wrapper contract address or that chain_id selects the network to probe, leaving the agent to infer both.

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 ("Probe") and resource (ERC4626 asset(), i.e. a wrapper's underlying), so the agent knows this resolves a wrapper to its underlying asset. It does not explicitly distinguish itself from the closest sibling, assets.lookup, which likely also answers asset questions.

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

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

Usage is only implied: "directly" suggests an authoritative on-chain ERC4626 asset() read rather than a cached/registry lookup, which hints at when to prefer it over assets.lookup. There is no explicit when-to-use, no prerequisites, and no named alternative.

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, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered structurally. The description adds only that the listing is restricted to implemented and read-only capabilities, which is a meaningful scope qualifier but not rich behavioral context (no mention of ordering, scale, or response shape).

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 redundancy. Every word ('implemented', 'read-only', 'schemas') carries scope information.

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

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

For a zero-parameter introspection tool with no output schema, the description should say what the response looks like — a list of capability names with schema payloads — and it only gestures at this with 'and their schemas'. Adequate to select the tool, thin on what to expect back.

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 disambiguate; baseline is 4. The absence of any parameter text is appropriate rather than 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?

States a specific verb (list) and resource (implemented read-only capabilities plus their schemas), which is clear enough to act on. It doesn't distinguish itself from discovery-oriented siblings such as skills.list or registry.list_contracts, so an agent can't tell from the text alone which listing tool answers which 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?

No indication of when to call this versus skills.list or the registry listing tools, nor any note that it is typically a session-start introspection call. Usage is only weakly implied by 'implemented' and 'read-only'.

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 closed-world, so the safety profile is covered. The description adds the meaningful hint that results come from a local index (implying possible lag or incompleteness versus chain head), but says nothing about ordering, pagination, or freshness.

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?

It is a single front-loaded sentence with no waste, but for a five-parameter tool with zero schema documentation this level of brevity reads as under-specification rather than conciseness; the space saved is space the agent needed.

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, no parameter descriptions, and no annotations explaining data semantics, the description should say what an event record looks like and how results are bounded. It leaves the agent unable to predict the return shape or pagination behavior.

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% across five parameters, so the description must carry the burden and does not. 'swap, pool and liquidity events' loosely gestures at the undocumented `kind` string, but `pool`, `limit`, `chain_id`, and `since_block` get no semantics, formats, or defaults explained anywhere.

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 (Query) and a specific resource (locally indexed Vault swap, pool and liquidity events), which is far more informative than the bare name history.events. It also hints at the local-index scope, which separates it from a live RPC/observation tool, though it never names a sibling to contrast with.

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 statement of when to use this versus history.status, watch.poll, or observations.status, all of which plausibly return event-like data. The only guidance is implicit in the words 'locally indexed', leaving the agent to guess.

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, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: no indication of what 'local data coverage' means operationally, how staleness is reported, or whether the answer is scoped to a single chain.

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 short sentence with no filler and the core idea front-loaded, but the brevity comes from under-specification rather than economy — nothing here earns its place beyond a restated 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 should at minimum hint at the return shape; it only gestures at it via 'checkpoints' and 'coverage'. For a one-parameter read-only diagnostic on a closed-world server, a slightly richer sentence would close the 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 0% and the single required parameter (chain_id) is never mentioned in the description at all. The description does not compensate for the missing schema documentation, leaving the agent to infer what the identifier refers to.

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 verb ('Describe') and an object ('event-index checkpoints and local data coverage'), so the intent is inferable, but the vocabulary is abstract and never explains concretely what is returned (e.g., indexing progress, lag, block range). It does not differentiate itself from near-neighbors like history.events, observations.status, or rpc.get_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?

There is no guidance on when to call this versus history.events or the health/status siblings, and no stated prerequisites or exclusions. The agent must guess at the use case.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description does add one useful behavioral fact beyond that: the call performs gap analysis (what exists vs. what analytics are missing) rather than a plain listing. It says nothing about return shape, cost, or whether 'missing' results indicate an error or a normal 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?

One front-loaded sentence with no filler. It is efficient, though the brevity reflects under-specification rather than disciplined editing.

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 burden of explaining return values; it gestures at two result categories but not their structure, ordering, or format. For a read-only, single-parameter status tool this is minimally adequate, but it leaves the meaning of the required chain_id and the interpretation of 'missing' unexplained.

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 single parameter chain_id is undocumented in both schema and description. The description never mentions chain scoping, so the agent gets no semantics for the only input it must supply; the low-coverage rule requires the description to compensate and it does not.

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 verb 'Report' plus the resources 'indexed observations' and 'missing analytics' give a general sense of intent, but 'observations' is an undefined domain term and the description never says what a report looks like or what the two halves mean together. It also does not distinguish the tool from nearby siblings such as history.status, rpc.get_health, or pools.observe.

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 statement of when to call this tool, what prerequisite state must exist, or which sibling to use instead (history.status is the most obvious alternative for status queries). The agent must infer usage entirely from the tool 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 readOnly, idempotent, non-destructive, and closed-world behavior. The description adds meaningful policy semantics beyond that: 'fail-closed', 'reads allowed, writes denied', and explicitly not equivalent to signer authorization. It does not explain return behavior or edge cases, but the annotations carry the safety profile.

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 compact sentence that front-loads the key policy constraint. It is efficient and avoids waste, though its terseness contributes to ambiguity elsewhere. It could still be slightly better structured by separating the exclusion from the core behavior.

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 tool is simple in shape—two required parameters, no output schema—but the description omits both parameter semantics and any explanation of what a successful evaluation returns. With no schema descriptions to fall back on, the description should do more to explain how 'action' and 'chain_id' drive the policy result. The high-level policy statement is not enough for correct invocation.

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 input schema has 0% description coverage and the description says nothing about the two required parameters, 'action' and 'chain_id'. It does not explain what kinds of actions are valid, how chain_id affects evaluation, or whether values are constrained. An agent cannot rely on the description to understand parameter meaning.

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 says this is a 'fail-closed policy demonstration' with reads allowed and writes denied, which gives some sense of the resource and policy semantics. However, 'demonstration' is vague and the exact operation—evaluating an action against a chain-specific policy—is not stated clearly. It distinguishes itself from signer authorization, but not from other 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 only usage guidance is a negative exclusion: 'not signer authorization.' There is no statement of when to call this tool, what it should be used for, or which sibling tools are alternatives. An agent still has to infer whether this is for testing policy behavior or for real authorization decisions.

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, open-world, non-destructive, so the safety profile is covered. The description adds the meaningful context that results come from Rootstock Vault rather than heuristics, but says nothing about output shape, latency, or failure modes when a pool is unknown.

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 compact sentence with the key qualifier front-loaded; nothing is wasted. It is arguably too terse for the information gaps it leaves, but not verbose.

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 and the description does not explain the return value (a set of token addresses?) or how the two required parameters map to it. For a tool with 0% schema coverage and no output schema, more explanation is needed.

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 both parameters (pool, chain_id) are required but undocumented anywhere. The description never mentions them, so an agent gets no guidance on whether 'pool' is an address, a symbol, or an id, nor what chain_id format is expected.

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 resource (pool token addresses) plus the data source (Rootstock Vault). The clause 'no guessed reserve/TVL' distinguishes it from analytics-style tools, though it doesn't name pools.list or pools.observe explicitly.

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

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

No explicit when-to-use or when-not-to-use guidance. 'no guessed reserve/TVL' hints that this is the authoritative alternative to computed data, but the agent is left to infer whether to call this instead of pools.list, pools.observe, or analytics.tvl.

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 establish the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower. The description adds the meaningful constraint that the window must be bounded and inclusive and that results carry block provenance, but says nothing about the `limit` cap, pagination, or what happens when the window is too large.

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

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

A single sentence with no filler; the key constraint ('explicitly bounded inclusive block window') is front-loaded right after the verb and resource.

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 should clarify what a result looks like — 'with block provenance' gestures at it but does not say whether it returns raw logs, decoded PoolRegistered entries, or paginated batches. For a 4-param event query the definition is 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 description coverage is 0%, so the description carries the burden. It successfully explains that from_block/to_block are an inclusive range and implicitly scopes chain_id via 'Vault', but the `limit` parameter is left entirely unexplained in both schema and description.

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 resource ('Vault PoolRegistered events') plus scope ('explicitly bounded inclusive block window'), which is far more precise than the title. It is distinguishable from pools.inspect/pools.observe by being event-log oriented, though it never names those siblings explicitly.

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

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

There is an implied constraint ('explicitly bounded inclusive block window'), but no statement of when to choose this over history.events, pools.observe, or pools.inspect, and no prerequisites or exclusions. An agent must infer the selection criteria from the name 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 establish that this is a safe, idempotent, read-only operation. The description adds useful context that the tool combines onchain data with local indexed registration evidence, but it does not disclose freshness, caching, pagination, or error 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?

The description is a single front-loaded sentence with no wasted words. It is terse, but structurally clean and easy to scan.

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

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

For a two-parameter read tool with no output schema and no parameter descriptions, the description is too thin. It should clarify return shape, data freshness, and parameter expectations to be complete enough for reliable invocation.

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 neither 'pool' nor 'chain_id' is documented in the schema. The description does not compensate by explaining identifier formats, chain-id conventions, or what 'pool' refers to, leaving parameter meaning largely implicit.

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 ('Read') and identifies the resource as pool onchain data plus local indexed registration evidence. It is clearer than a tautology, but it does not explicitly distinguish the tool from siblings like pools.inspect or pools.list.

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 no when-to-use guidance, no exclusions, and no alternatives. An agent must infer usage purely from the word 'Read' and the tool 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, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds a real precondition (an audited Rootstock SOR must exist) but does not say what happens when it fails, whether an error or empty result is returned, or what the quote contains — and the phrasing is cryptic enough to be ambiguous.

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?

Short but not informative: a single clause pair that is under-specified rather than concise. It leads with an abstract phrase instead of the operation, so the brevity costs clarity rather than gaining it.

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, no annotation gaps filled, and zero parameter documentation in the schema, the description carries the full explanatory load — and it delivers only a precondition. An agent knows it may fail but not what it returns or how to fill the six inputs.

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?

Six parameters, four required, at 0% schema description coverage — chain_id, token_in, token_out, amount_raw, pool and sender are documented nowhere. The description supplies no parameter meaning at all, so an agent cannot tell whether token addresses are symbols, whether amount_raw is a decimal string in base units, or what `pool` constrains.

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 never says what the tool actually does. "Return explicit routing prerequisites" names an abstract concept rather than a verb+resource pair like "get a swap quote for a token pair on a chain"; the only concrete noun, "quote", appears in a negative clause about unavailability.

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 one gating condition ("quote unavailable without audited Rootstock SOR") but gives no when-to-use framing and never points at any of the 36 siblings, such as transactions.simulate or transactions.call_router, that an agent might confuse this with.

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 (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still earns credit for disclosing a non-obvious behavioral trait: the ABI is 'reviewed' and 'partial', i.e. deliberately incomplete and curated, which warns the agent not to treat it as authoritative for a full build. No return format or ordering details are given.

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 stating what is returned followed by the key caveat. No filler, no restatement of the title, and the most decision-relevant information (partial, read-only, not full build) comes first.

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 strong annotations, most of the burden is lifted, but there is no output schema and the description says little about the shape of the returned catalog (format, keying, how topics and signatures are grouped). For a zero-arg lookup tool it is adequate but leaves the agent guessing about return structure and freshness.

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 and the schema is an empty object with additionalProperties false, so there is nothing to document. Baseline 4 applies; nothing in the description adds or detracts from parameter understanding.

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 concrete verb ('Return') and resource ('reviewed partial read-only ABI signatures and verified Vault event topics'), so an agent knows what comes back. It also negates the wrong expectation ('not a full exact build ABI'). It does not, however, distinguish itself from the close sibling registry.abi_selector, so a reader cannot fully disambiguate the two from this text 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?

The exclusion 'not a full exact build ABI' implies when this is the wrong choice, but there is no positive statement of when to reach for it or which sibling (e.g. registry.abi_selector, registry.verify_contract) to use instead. Usage is only inferable from the 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, idempotentHint, and openWorldHint=false, so safety is covered. The description adds the meaningful constraint that only 'reviewed' ABIs are served and that the output is a selector rather than an authorization, but it says nothing about failure behavior for unreviewed or unknown signatures.

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 filler. Its brevity is a virtue in structure but contributes to the under-specification noted elsewhere.

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 two required, entirely undocumented parameters and no output schema, the description does not say what a 'selector' looks like on return (hex length/format) or how the two inputs combine. An agent can guess but cannot be certain it is calling this correctly.

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

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

Schema description coverage is 0% and both parameters are required, so the description carries the full burden — yet it explains neither what 'interface' identifies (network, contract, interface name?) nor that 'signature' is presumably a canonical function signature string. Only a loose hint is derivable from the phrase 'ABI function'.

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 verb+resource ('Return an exact selector for a ... ABI function') is present and the negative clause rules out deploy/transaction authorization. However, 'selector' and 'ABI function' are left undefined, and the sibling registry.abi_catalog is never referenced, so the boundary between this tool and that catalog is not established.

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 a 'what this is not' (not a deploy/transaction authorization) but no positive when-to-use condition and no named alternative such as registry.abi_catalog or registry.verify_contract. The agent must infer the selection rule from a negation 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 readOnly, idempotent, non-destructive behavior, so the bar is lower. The description usefully signals that deprecated records are retained in results, but 'preserving task identity' is unexplained and there is no note on result shape or filtering.

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 efficient sentence with the resource front-loaded. It wastes little, though the second half is abstract.

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 should describe what is returned, yet it only hints at 'deprecated records' and says nothing about chain_id's role or the record fields. For a registry listing tool this 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?

The single parameter chain_id has 0% schema description coverage, and the description never mentions it or what values are valid. With one undocumented parameter, the description should compensate but does not.

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 ('List') and resource ('Rootstock registry deployments'), which is distinguishable from siblings like registry.list_networks and registry.resolve_deployment. The trailing phrase 'preserving task identity and deprecated records' is vague but doesn't obscure the core 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?

No when-to-use guidance and no alternatives named. An agent cannot tell from the description whether to prefer this over registry.list_networks or registry.resolve_deployment for a given task.

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 annotations already communicate that this is a safe, read-only, idempotent, non-destructive, closed-world operation. The description adds only the scope of returned registry information and says nothing about ordering, local provenance meaning, or limitations, so it adds modest value beyond structured metadata.

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 front-loaded sentence with no redundant or filler content. It states the resource and scope immediately.

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

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

For a zero-parameter read-only list operation, the description is minimally adequate, but with no output schema it could better clarify what a "network identity" contains and what "available local source provenance" means. The annotations cover safety, but return-shape context remains thin.

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 parameter semantics are inherently simple and the baseline is 4. The schema is empty and fully covered, leaving nothing further to explain.

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 has a clear verb ("List") and a specific resource ("Rootstock network identities and available local source provenance"), so an agent can distinguish it from contract- or ABI-oriented registry siblings. It does not explicitly name sibling tools or contrast use cases, which keeps it from a 5.

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

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

The usage is implied by the name and description: this is the registry tool for listing network identities. However, it gives no explicit when-to-use guidance, exclusions, or alternatives such as registry.list_contracts or topology.explore.

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 closed-world, so safety is covered. The description adds one useful fact beyond them: resolution happens against a pinned canonical *local* registry, implying static/offline data rather than live chain state. It does not describe failure behavior when a name is unresolvable or what the ambiguity error looks like.

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 with no waste, front-loading the action and following with the scoping constraint. Nothing is repeated from the schema or annotations.

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

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

No output schema and zero parameter descriptions, so the definition carries the burden; it covers purpose and the ambiguity rule but leaves the return shape and two of three parameter meanings undocumented. Adequate to attempt a call, not adequate to predict 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?

Schema description coverage is 0%, so the description must compensate and only partly does: it explains that `task` disambiguates ambiguous names, which is real added meaning. `chain_id` and `name` receive no clarification (e.g., what a deployment name looks like, which chain IDs are valid).

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+resource (resolve a Rootstock deployment) and a sourcing constraint (against a pinned canonical local registry), which separates it from enumeration siblings like registry.list_contracts. It stops short of stating what a resolution yields (address, ABI, metadata), so the output intent stays fuzzy.

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 'ambiguous names require task' gives a conditional usage rule tied to the task parameter, which is genuinely actionable. However, it never says when to prefer this over registry.list_contracts, registry.verify_contract, or registry.abi_catalog, leaving the routing decision implicit.

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 annotations already establish that this is a safe, idempotent, closed-world read, so the bar is lower. The description adds real value by clarifying the shallow depth of the check (existence only, not bytecode verification), but leaves behavior unspecified: it does not say whether a missing contract yields a false or an error, nor what 'pinned' constrains.

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 scope stated first and the disambiguation second. Nothing is padded and nothing is buried.

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

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

With no output schema and no annotation covering return values, the description should say what a check produces and how a negative result is surfaced. Combined with zero documented parameters, an agent knows roughly what the tool is for but not what to pass or expect back.

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% across three parameters, so the description carries the full burden here and mostly drops it. It never explains that 'name' identifies the contract or what 'task' means in this context, leaving one required parameter and one optional parameter semantically opaque.

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 sentence names a specific verb (check) and a specific resource (pinned Rootstock contract code) scoped to the selected chain, and the trailing clause rules out a nearby misreading (bytecode audit). It stops short of distinguishing the tool from registry siblings such as resolve_deployment or list_contracts, and 'pinned' is internal jargon the agent must guess at.

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?

'not a bytecode audit' is a useful negative boundary that implicitly routes code-correctness questions elsewhere. But there is no positive when-to-use statement and no named alternative among the many registry.* siblings, so the agent must infer selection from the tool name 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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds value by enumerating the three returned values (chain ID, block, hash), which matters because there is no output schema. However, it says nothing about network dependency, rate limits, or what happens if the RPC is unreachable, which is relevant for an openWorld health check.

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

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

A single tight sentence that front-loads the verb and lists the resources. It borders on being under-specified rather than verbose, and the phrase 'configured Base RPC chain ID, latest block and hash' is slightly ambiguous in how the three items parse.

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?

Listing the returned values compensates somewhat for the absent output schema. However, with a required, entirely undocumented chain_id parameter and no stated failure behavior, the definition is only minimally sufficient for calling 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?

There is one required parameter, chain_id, with 0% schema description coverage, so the schema provides no meaning at all. The description never mentions chain_id or its format, and 'the configured Base RPC chain ID' could even suggest no argument is needed. The description fails to 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?

The description uses a specific verb (Read) and names the exact values returned: chain ID, latest block, and hash. That makes the tool's purpose distinct from most siblings, though it doesn't explicitly name a competing tool like observations.status or history.status, so the differentiation is implicit.

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 guidance on when to call this versus alternatives such as observations.status, history.status, or capabilities.list. There are no exclusions or prerequisites stated. An agent is left to infer that this is a connectivity/health probe from the tool name 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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description's one contribution is the catalog boundary (bundled only), which is useful but thin; it says nothing about whether the list is static or versioned, or what a returned entry contains.

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 clause pair, scope stated first and the exclusion second. Nothing is wasted and nothing important is buried.

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

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

For a no-arg, read-only list tool with no output schema, the definition is close to sufficient but leaves the return shape entirely unspecified — an agent cannot tell whether entries carry names, descriptions, or identifiers to feed into skills.read.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing to disambiguate and the description correctly implies an unfiltered full dump rather than a search.

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 ('List bundled Rootstock and Orchard agent skills') and narrows scope with 'no third-party skill installation', so an agent knows this enumerates a curated catalog. It never names the sibling skills.read, so the distinction between listing and reading a skill must be inferred from the verb 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?

The exclusion ('no third-party skill installation') implicitly tells the agent not to come here for external skills, but there is no positive when-to-use guidance and no mention of skills.read as the follow-up for fetching one skill's details.

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, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds the useful constraint that the name is 'validated' (i.e., invalid names fail rather than fuzzy-matching), but says nothing about what a successful read returns.

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 zero filler; the key constraint (exact, validated name) lands immediately.

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

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

For a one-parameter read tool with full annotations and no output schema, the essentials are present, but the description omits where valid names come from (skills.list) and what the call yields (SKILL.md content). A brief return hint would close the remaining gap.

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

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

Schema description coverage is 0%, so the lone 'name' parameter is undocumented in structured fields. The description partially compensates by specifying the name must be 'exact' and 'validated', but gives no format, case-sensitivity, or example of a valid skill name.

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 ('Read') and resource ('one bundled SKILL.md'), and the singular 'one' implicitly separates it from the sibling skills.list. It does not name the sibling explicitly, but an agent can distinguish read-one from list-many without opening the schema.

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

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

The phrase 'by its exact, validated skill name' implies this tool is for fetching a single known skill and that the name must already be valid, suggesting skills.list as the source. However, neither that prerequisite nor any when-not condition is stated outright.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful provenance context by disclosing that the graph is built from 'indexed pools and RPC token lists' and that missing tokens are labeled. It does not disclose cost, latency, or output shape, but with annotations present this is a reasonable middle score.

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 with no filler, and the core action ('Construct token-pool graph') is front-loaded. It could be slightly clearer about the two data sources, but every phrase contributes to the 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?

There is no output schema, so the description should explain the graph's return shape and how limit affects it, but it only vaguely says a graph is constructed and missing tokens are labeled. Combined with 0% parameter coverage, an agent lacks enough information to invoke this 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 0%, so the description carries the full burden for explaining the two parameters. It never mentions chain_id or limit, leaving the required chain identifier and the limit's effect on graph size undocumented. Only weak domain inference connects 'chain' concepts to chain_id.

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 action and resource: 'Construct token-pool graph from indexed pools and RPC token lists.' It also notes edge-case handling ('labeling missing tokens'), so an agent can tell this is a graph-building tool. However, it does not explicitly distinguish itself from the sibling topology.rooted, leaving the relationship between the two topology tools ambiguous.

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 explains what inputs are used but gives no guidance on when to call this tool versus topology.rooted or pools.list. There are no stated prerequisites, exclusions, or alternative-routing hints, so the agent must infer usage from the name 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, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful context that results are provisional, based on observed pools and configured root, and not canonical Orchard ranks, but it does not describe return format or edge-case 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?

It is a single compact sentence with no filler and the main classification purpose is front-loaded. The dense domain jargon makes it less accessible, but it is not verbose.

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 not explain what the returned classification contains beyond the Branch/Graft/Whorl terminology. With 0% schema description coverage, it should compensate by clarifying chain_id, limit, and the configured root, but it does not.

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 two parameters. It never defines chain_id or limit, leaving the required chain_id semantically undocumented.

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 identifies a specific classification operation: provisional rooted Branch/Graft/Whorl classification from observed pools and a configured root. It also clearly states it is not canonical Orchard ranks. However, it does not explicitly contrast itself with the sibling topology.explore 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 does not say when to use this tool versus alternatives such as topology.explore. The 'provisional' and 'not canonical' caveat hints at scope, but it is a limitation statement rather than usage guidance.

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

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

The annotations already declare the safety profile (readOnlyHint, idempotentHint, non-destructive), and the description adds real value on top: an allowlist gate on the spender and a simulation-first, policy-checked flow. However, it never resolves whether the call only simulates/prepares or also broadcasts, and it gives no detail on policy failure modes or what the caller receives back.

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

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

Three short sentences, front-loaded with the operation and then the constraint and the execution model. Nothing is redundant and no sentence simply restates 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 four-parameter, no-output-schema mutation-adjacent tool, the description omits the outcomes an agent needs: whether a transaction is broadcast, what the simulation result contains, and how the policy gate reports refusal. The readOnlyHint annotation sits uneasily beside 'ERC20 approve' and the description does not reconcile that.

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% across four required parameters, so the description carries the full burden and mostly drops it. It clarifies that 'router' means an allowlisted Rootstock router and ties the call to a spender, but chain_id, token (address format?) and amount_wei (string-encoded wei, decimals handling) are left entirely unexplained.

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 operation and resource: an ERC20 approve restricted to an allowlisted Rootstock router. The constraint ('spender must be an allowlisted Rootstock router') makes it distinct from a generic approve, though it never names the neighbouring tools (transactions.call_router, transactions.prepare, transactions.simulate) it could be confused with.

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?

'Arbitrary spenders refused' and 'policy-gated' imply the preconditions, so an agent can infer that unlisted routers will fail. But it never says when to pick this over transactions.prepare or transactions.call_router, nor what to do after the simulation returns.

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 says "Broadcast a raw contract call", an on-chain write, while annotations declare readOnlyHint=true and destructiveHint=false. That is a direct contradiction about the single most important property of the tool. The additional "allowlisted router only" constraint is useful context, but it cannot outweigh a reversed safety 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?

Three short front-loaded fragments with no filler; the scoping constraint lands first. The trade-off is telegraphic compression ("Sim-first, policy-gated") that leaves terms unexplained rather than truly concise.

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 4-parameter, zero-coverage mutation tool with no output schema and contradictory annotations, the description omits prerequisites, failure modes, what gets broadcast, and what comes back. An agent knows the intent but not how to call it safely or 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?

Schema description coverage is 0%, so the description must carry all parameter meaning, yet it only hints at `router` (allowlisted). It says nothing about `chain_id` validity, the encoding expected in `data`, or the units/format of `value_wei`, leaving three of four parameters undocumented in both places.

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?

"Broadcast a raw contract call to an allowlisted Rootstock router only" gives a specific verb (broadcast) plus constrained resource, and "Arbitrary targets refused" distinguishes it from a generic send/execute. It does not name the nearest siblings (transactions.send, transactions.prepare, transactions.approve_router), so the differentiation is implicit rather than routed.

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?

"Sim-first, policy-gated" implies a workflow (simulate before broadcasting) and suggests a policy check, but never says when to pick this over transactions.send or transactions.prepare, nor what happens if policy evaluation fails. Usage is inferable but not 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 cover safety (readOnlyHint=true, idempotent, non-destructive, closed-world); the description adds genuinely new context by declaring the result is unsigned and not yet policy-approved. It does not say what happens for non-pinned chains or what the caller should do next with the envelope.

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 filler. It is arguably too terse for the amount of undefined jargon packed into it, 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?

No output schema and no parameter documentation mean the description should explain the envelope payload and the meaning of 'pinned'. It omits both, leaving the agent unable to construct transaction_json or know how to consume 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?

Schema coverage is 0% with two required parameters, so the description carries the full burden — and it explains neither. 'pinned Rootstock targets' hints that chain_id must be a supported chain, but transaction_json's expected shape (the critical unknown) is never described.

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

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

Specific verb+resource: returns an unsigned transaction envelope, and it distinguishes the scope ('only for pinned Rootstock targets') from sibling transactions.send/simulate. It stops short of full clarity because 'policy-unapproved' and 'pinned' are undefined jargon an agent must already know.

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?

'only for pinned Rootstock targets' is an implicit usage constraint, but no alternative is named (transactions.simulate, policy.evaluate, transactions.send) and no when-not-to-use is stated. The agent can infer this is a pre-signing step but must guess the ordering.

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 says 'Sign and broadcast', an unambiguous state-changing write, while annotations declare readOnlyHint=true and destructiveHint=false. This is a direct contradiction of the structured safety profile. The extra context (env signer key, chain+value caps, no bypass) is useful but cannot offset a contradictory annotation.

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 dense sentences with the action front-loaded and the constraint ('Caps are structural; no bypass.') placed as a closing guardrail. 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?

Explains the signing model and cap enforcement well, but for a mutating broadcast tool it omits failure behavior, whether a tx hash is returned, and confirmation semantics — and no output schema exists to fill that gap. Combined with the annotation mismatch, the agent is left uncertain about the operation's effects.

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% for all three required parameters, so the description carries the full burden. It only vaguely implies value and destination through 'ETH value transfer' and 'chain+value caps'; chain_id, to, and value_wei (notably its string-encoded wei format) are never explained.

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 pair ('Sign and broadcast') and resource ('ETH value transfer') plus the execution path (policy-gated executor). It is clearly distinguishable from siblings like transactions.prepare, transactions.simulate, and transactions.call_router.

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 when to use by naming the executor path and 'simulation-first', but never explicitly states when to prefer this over transactions.prepare, transactions.simulate, or transactions.call_router, nor any prerequisites (funded account, allowlisted recipient).

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one genuine behavioral fact beyond that — that no signing or policy approval is required — which matters in a system with a policy.evaluate sibling. It says nothing about the shape of the result or what 'pinned' target means operationally.

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 clause with zero filler, and the differentiating constraint (no signing/approval) is placed where it is read first. It is efficient, though its terseness is part of why parameter and return semantics are missing.

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 should explain what an eth_call simulation returns (result data, revert behavior, encoding), and it does not. Combined with 0% parameter coverage and additionalProperties:false leaving no room for extension, an agent cannot reliably construct a correct call from this definition alone.

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%: neither chain_id nor transaction_json carries any documentation. The description does not mention either parameter, so an agent gets no guidance on the transaction_json format or whether chain_id must be Rootstock-specific despite the 'pinned Rootstock target' phrasing. For a low-coverage 2-param tool this is a meaningful 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 states a concrete operation: an explicit eth_call simulation against a pinned Rootstock target. That specific verb+resource pairing distinguishes it from transactions.send and transactions.call_router, which actually submit transactions. It stops short of naming a sibling, but the operation is unambiguous.

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 signing or policy approval' implies this is the path for dry-run/read-only calls where send/prepare would be inappropriate, which is useful implied routing. However, it never explicitly says 'use this when you want to simulate instead of send' or names transactions.prepare/transactions.send as the alternatives, leaving the selection to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds useful context that finality is 'unverified' and data comes from RPC, but it omits what happens if the transaction is unknown or the RPC is unavailable. With annotations carrying the safety profile, a 3 is appropriate.

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 front-loaded sentence with no filler. Every phrase contributes: read operation, transaction receipt, unverified finality, RPC source.

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 not explain the shape of the receipt or finality response. Combined with 0% parameter documentation, an agent lacks enough detail to call this confidently without inspecting the schema and guessing parameter meanings.

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 for undocumented parameters. It does not explain that 'hash' is the transaction hash or what 'chain_id' is used for, leaving both required parameters semantically bare beyond their names.

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 read operation: fetching a transaction receipt and 'unverified finality' from RPC. That is a clear verb+resource pairing. However, it does not differentiate from similarly named siblings like history.status or observations.status, so an agent must infer which status endpoint applies.

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 explicit guidance on when to use this tool versus history.status, observations.status, transactions.simulate, or other transaction-related siblings. The description implies a read-after-send use case but does not state prerequisites 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds a genuine behavioral trait beyond that: 'preserving intra-block updates' signals ordering/completeness guarantees for events sharing a block. However, it says nothing about pagination behavior, default limits, or what a caller gets back to advance the cursor.

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 filler; the cursor constraint and ordering guarantee come in one compact clause. It could still spend one more clause on what is returned to advance the cursor.

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 cursor tool with no output schema, an agent still lacks the return shape (list of events? next cursor?) and the meaning/default of limit. The ordering guarantee is covered, but the pagination contract is not.

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%, so the description must compensate. It clarifies the two cursor parameters (since_block, since_log_index) and the ordering semantics between them, but leaves chain_id and limit entirely unexplained in both schema and description.

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 ('Query') and resource ('indexed Vault events') plus the cursor semantics of 'after a specific block and log index'. It implicitly contrasts with watch.poll by describing cursor-based continuation, but never names or explicitly distinguishes itself from that 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?

'after a specific block and log index' implies incremental pagination use, but there is no explicit when-to-use guidance, no mention of when to prefer watch.poll or history.events, and no prerequisites 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 readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds two genuinely new facts: the data comes from a local index (not live RPC), and polling cadence is external to the tool. It says nothing about result shape, ordering, or truncation behavior when limit is reached.

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 compact sentence with the core scope front-loaded and no filler. It is efficient, though the terseness is partly the cause of the uncovered parameters.

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 should sketch the return shape and whether results are ordered or capped, which it does not. It does correctly convey the incremental-poll contract, leaving it adequate but incomplete for a 3-parameter event 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 0%, so the description carries the full burden, yet it only explains since_block ('newer than a given block'). chain_id and especially limit (units? default? truncation?) are left entirely undocumented in both schema and description.

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 (check) and resource (locally indexed events newer than a given block), which is far more informative than the title 'watch / poll'. It implicitly distinguishes the pull-based polling model from the sibling watch.cursor, though it never names that sibling or history.events.

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?

'caller schedules repeated polls' gives useful usage context: this tool does one incremental read, and the loop is the caller's responsibility. However, there is no explicit guidance on when to prefer watch.poll over watch.cursor or history.events, and no stated prerequisites.

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