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

Annotations already declare readOnly/idempotent/non-destructive, and the description is consistent with them, adding that nothing is signed or sent and that min-output and deadline are baked into the returned calldata. It goes beyond the structured fields by clarifying the output is inert and requires a separate signing step.

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

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

Two tight sentences with no filler; the core action and the safety-relevant constraint (unsigned, not sent) are front-loaded.

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

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

With 11 params, no output schema, and annotations covering the safety profile, the description covers the essential nature of the result (unsigned Router calldata). It could say more about what the calldata payload contains or that a quote is performed first, but it is largely sufficient.

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

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

Schema description coverage is 100%, so the schema already documents all 11 parameters including `from`, `chain`, `slippageBps` bounds and `userMinOut`. The description only gestures at 'minimum output and deadline', adding no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific action (quote a swap and produce unsigned calldata) plus the target resource (Router) and the key baked-in values. An agent can distinguish this from get_quote (quote only) and simulate_swap (simulation) without inspecting schemas.

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?

Adds workflow guidance ('review it, then sign in your own wallet'), which implies this is the build step before signing. However it never states when to prefer this over get_quote or simulate_swap, nor any prerequisites (e.g. needing an allowance check via the `from` param).

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, openWorld). The description adds that the read is live from chain and returns both a boolean and a decoded struct, but omits failure behavior, RPC prerequisites, and whether results are cached.

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

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

Two tight sentences, no filler, with the core action front-loaded. It is appropriately sized, though the method-name jargon could read as terse for an agent unfamiliar with the contract.

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

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

For a single-optional-parameter read tool with full annotations and no output schema, the description is largely sufficient but leaves the shape of the decoded solvency() struct and any error/latency behavior unstated.

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

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

Schema coverage is 100%, so the chain parameter's accepted values and optionality are already documented. The description adds only the default value ('Base'), which the schema does not state, a small but genuine increment over the schema baseline.

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

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

States a specific verb+resource: a live on-chain solvency read, naming the contract methods (isSolvent() and solvency()) it surfaces. This clearly distinguishes it from the sibling swap/quote/deployment tools, though it never explicitly says so.

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, prerequisites, or alternatives are given. The only implicit context is that it checks a staking position's solvency, and 'Defaults to Base' merely states a default rather than a usage condition.

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, so the safety profile is fully covered. The description adds useful content scope (which addresses and dimensions the registry covers) but nothing about freshness, lookup keys, or whether missing chains/protocol versions yield empty results.

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 colon-fragment is slightly terse but every clause earns its place by naming what the registry contains.

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

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

With no input parameters and no output schema, the description carries the return-value burden and does list the registry's dimensions (entity type, chain, protocol version), though it omits the response shape and how to key into a specific deployment.

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 for the description to compensate for on the parameter axis.

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

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

The description names the specific resource (the versioned deployment registry) and enumerates its contents — Core, Hub, Solver, Quoter and Router addresses — keyed by chain and protocol version. That is far more specific than a tautology, though it never distinguishes itself explicitly from the nearest sibling, verify_deployment.

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

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

There is no when-to-use or when-not-to-use guidance. An agent must infer that this is a reference lookup to resolve contract addresses before invoking build_swap, get_quote or verify_deployment; the description never says so or names an 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 readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered. The description adds real behavior beyond that: it fails closed, the verdict has four enumerated states, output is net of fee, and exact=true changes the execution mode to a per-leg dry-run.

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, front-loaded with verb and resource, then the return contents, then the exact flag. Every clause carries information; the em-dash list is efficient rather than padded.

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

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

With no output schema, the description usefully enumerates the return fields an agent should expect, and the fails-closed behavior is disclosed. Only the routing relative to sibling quote/simulate tools is missing.

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

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

Schema description coverage is 100%, so the schema already documents all eight parameters including exact and version defaults. The description reinforces exact=true semantics but adds no syntax or constraints the schema lacks, so baseline 3 applies.

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

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

States a specific verb (quote) and resource (swap) and enumerates the returned quantities: net output after fee, Router minimum, price impact, Phoenix Check verdict. An agent can distinguish this from build_swap/simulate_swap, though no sibling is named explicitly.

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

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

There is no statement of when to use this versus simulate_swap or build_swap, and no prerequisites or exclusions. The only usage hint is the parameter-level 'exact=true for an execution-grade dry-run,' which is guidance about a flag, not about 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, openWorld and non-destructive, so safety and caching behavior are covered. The description adds that values come live from the chain via the caller's RPC rather than a cache, which is useful context beyond the annotations, but it says nothing about behavior for unknown or ambiguous symbols.

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 returned fields and the data source front-loaded; every clause earns its place and nothing is redundant.

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 rich annotations and no output schema, the description listing the returned fields effectively covers the output contract and the data source. Only the error/ambiguity behavior and explicit routing against sibling read tools are missing.

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

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

Schema description coverage is 100%, so both parameters (chain, token) are fully documented in the schema, including the enum-ish chain list and address-or-symbol token format. The description contributes no additional parameter meaning, so baseline 3 applies.

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

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

The description names a concrete resource and enumerates the exact fields returned (symbol, decimals, name) plus the data source ('read from the chain through your RPC'). It is clearly distinct in subject matter from siblings like get_quote or build_swap, though it never explicitly contrasts itself with them.

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

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

There is no statement of when to use this tool versus alternatives or what preconditions apply. The only implicit cue is 'through your RPC,' which hints at the environment but not at when an agent should pick this over get_quote or get_deployments.

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, so safety is covered structurally; the description adds real value by disclosing the execution mechanism (eth_call on your node, implying an RPC dependency) and the return contents ('the plan and the simulation'). It stops short of describing failure/revert behavior.

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

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

Three short sentences, zero filler, with the core action front-loaded and the key non-mutating guarantee placed last for emphasis. Every sentence carries information.

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

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

For a read-only, 11-parameter tool with full schema coverage and no output schema, the description is nearly sufficient: it names the mechanism and says what is returned. It omits what a failed/reverting simulation looks like and any chain/version caveats that a caller might want.

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

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

Schema description coverage is 100%, so the schema fully documents all 11 parameters including the amount/amountIn and slippage/deadline semantics. The description only loosely anchors the 'from' parameter ('from the given account') and adds no other parameter meaning, so the baseline 3 applies.

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

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

States a specific verb and resource (simulate/dry-run a swap) plus the exact mechanism (eth_call from the given account), which is more precise than the bare name. It implicitly relates to sibling build_swap by saying it 'builds the swap, then dry-runs it', but never names alternatives to route against 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?

The phrase 'dry-run' and 'Nothing is signed or sent' imply the use case (preview before executing), so usage is inferable. However, it never states when to choose this over build_swap or get_quote, nor any preconditions or exclusions.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description adds that the check runs through the user's RPC against live on-chain state, which is meaningful context, but it doesn't say what happens on mismatch or what the result conveys.

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 clause (what is compared, for which inputs, via what channel) earns its place.

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

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

For a two-optional-parameter read-only verification tool with annotations covering the safety profile, the description is largely sufficient. A brief note on the outcome shape (match/mismatch or error) would close the remaining gap, since no output schema exists.

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

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

Schema description coverage is 100%: the chain enum values, numeric-chain-id fallback, optionality, and version formats are all documented in the schema. The description adds no syntax or format detail beyond that, so the baseline 3 applies.

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

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

States a specific verb (verify/check) and a precise resource (registry addresses for a chain and version) and clarifies it compares against on-chain state. An agent can tell it apart from listing tools conceptually, but no sibling is named (e.g., get_deployments), so it falls short of a 5.

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

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

The description never says when to prefer this over siblings like get_deployments or check_solvency, nor any prerequisites or exclusions. Use is only implied by the check itself, matching the 'no when-to-use guidance' bar.

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