insight-oracle

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

No annotations exist, so the description carries the full burden, and it does substantial work: it enumerates every fail-closed condition (either input assessment not SUFFICIENT, stale/out-of-policy route quote, blocked oracle gate) and states no handle is issued. It also discloses signing (EIP-712), the dual-RPC cross-check, and that this is evidence rather than principal authorization. It omits auth/permission requirements and latency expectations.

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

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

The purpose is front-loaded in the first sentence, but the body is a very dense run-on that crams signing, UIDs, and route-quote mechanics together. One sentence is an orphaned fragment ('participant/source-group counts and the pre-trade signing time.') that dangles without a subject, and the closing 'not principal authorization' point partly repeats the earlier framing.

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 10-parameter nested-schema tool with no output schema and no annotations, the description is unusually complete: it describes what the returned handle contains, what conditions suppress it, and how it links to execution_receipt. The broken fragment about participant counts and signing time is the one place where a promised detail is left unreadable.

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

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

With 90% schema coverage the baseline is 3, and the description earns above that: it explains that routeQuotePrice is a caller-reported quote compared against Insight's own on-chain Uniswap V3 quote, that the policy is capped at 50 bps, and that only ETH/WETH, USDC and WBTC on Ethereum are supported while other routes fail closed. targetProviders and sourceGroupCount are left to the schema, which documents them adequately.

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

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

The description states a specific action and artifact: it runs the oracle safety check and returns a machine-readable execution certification handle (preTradeUid, requestHash, CAIP-19 ids, certified price, maxSlippageBps). It also disambiguates the misleading tool name by clarifying that the caller executes with their own wallet, and it points to execution_receipt as the follow-on. It stops short of distinguishing itself from siblings like pre_trade_safety_check or execution_preflight.

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?

Timing is explicit — call BEFORE trading, then call execution_receipt with the handle plus txHash after executing. It also states the negative branch: if the verdict is DANGER or BLOCK the tool refuses and 'do not trade'. What is missing is a head-to-head comparison with the other pre-trade siblings (pre_trade_safety_check, execution_preflight), which an agent choosing among 36 tools would need.

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?

With no annotations, the description carries the full burden and does well: it discloses that the operation is unsigned, that caller-supplied facts are unauthenticated, and that an ALLOW verdict does not authorize a trade. It doesn't state determinism, cost, or any rate/limits, but the trust-boundary disclosure is exactly the kind of context annotations would otherwise have to provide.

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, front-loaded with the core purpose and immediately followed by the most important caveat. No filler, no restatement of the name.

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?

Behavioral framing is strong, but with no output schema, no annotations, and a large nested input/policy schema at 0% description coverage, the definition leaves the agent guessing about the policy contract and result shape. It is adequate for understanding intent but not for constructing a correct 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?

Schema description coverage is 0% on two deeply nested required parameters (input and policy). The description only alludes to 'supplied ... evidence' and 'explicit policy' without explaining the policy structure, required fields, or how evidence/prices/request fields interact. It fails to compensate for the coverage gap on a highly complex 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 ('Evaluate') and resource ('supplied RWA/tokenized-stock evidence against an explicit policy'). It is clearly a diagnostic rather than an execution tool, so it separates conceptually from agent_begin_trade and pre_trade_safety_check, but it never names a sibling or 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?

'Unsigned diagnostic only' and 'existing pre-trade and authorization checks remain required' imply the usage context (advisory gate, not the final authorizer), but no explicit when-to-use/when-not statement or named alternative tool is given. The agent must infer the workflow position.

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?

No annotations are provided, so the description carries the full burden and does disclose what the tool evaluates: collateral and loan oracle integrity, and the caller-declared LTV against live protocol parameters. It also very clearly states the limits of its behavior, saying it 'never signs, broadcasts, or authorizes a transaction.' What it doesn't say is whether the check is free or rate-limited, or how fresh or cached the protocol parameters are.

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 open with the scope and the output, then state the safety boundary. Every clause carries information, and nothing is 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?

There is no output schema and no annotations, so the description should carry more weight. It covers the return values (ALLOW/CAUTION/BLOCK) and the safety profile well, but it leaves 7 undocumented parameters without units or per-protocol requirements, which is a meaningful gap for a gate whose correctness depends on getting those inputs right.

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 7 parameters, so the description must carry the meaning itself. It adds only fragmentary hints: 'exact Morpho Blue market' implies that marketId is needed for Morpho, even though it isn't in the required list, and 'post-action LTV' implies that collateralValueUsd and debtValueUsd are post-action figures. It doesn't explain units, decimal scaling, or why action only allows supply or borrow, so most parameter meaning is left undocumented in both the schema and the 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 and resource: a read-only pre-signing gate for Base lending actions, scoped to four named protocols (Aave V3, Morpho Blue, Compound V3 USDC Comet, Moonwell), and it names the ALLOW/CAUTION/BLOCK output. It distinguishes itself from chain siblings such as monad_lending_guard by chain and protocol list, but it never names base_lending_guard_exact_call as the alternative for binding a decision to a transaction, so the reader has to infer which sibling to use.

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 context is implied well: call this before signing a supply/borrow on these Base markets. The closing sentence, 'bind a successful decision to an exact user-authorized transaction separately,' hints at the exact_call sibling, but never names it or states the condition that selects it. It also doesn't explain when to prefer check_position_safety or pre_trade_safety_check.

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?

With no annotations to lean on, the description carries the full behavioral burden and does so: it enumerates exactly what is verified (target, selector, token/market binding, sender, nonce, zero value), describes the return artifact (short-lived EIP-712 decision, conditional on Insight signing being configured), and states hard limits ('never authorizes, signs, or broadcasts'). The conditional signing requirement and the required external ALLOW binding are non-obvious traits an agent could not get from the schema.

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

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

Three sentences, each load-bearing: what is produced, what is checked, and what it does not do. Dense with domain jargon but front-loaded and free of filler; the final sentence about PriorSeal is essential rather than padding.

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

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

A verification/attestation tool with a nested schema, zero parameter descriptions, and no output schema needs more: it never says what happens on a failed verification (error shape, reason codes), how long 'short-lived' is, or how the USD amounts feed the risk model. Enough to call it correctly in outline, not enough to interpret results.

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% on a nested two-object schema, so the description must compensate and only partly does: 'target, selector' map to transaction.to/data, 'token or market binding' to collateralSymbol/loanSymbol/marketId, and 'sender, nonce and zero value' to from/nonce/value. The guard's collateralValueUsd and debtValueUsd, the protocolId/action enums, and chainId being fixed at 8453 are never explained in prose.

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 artifact ('Create portable Insight risk evidence') for a precisely scoped resource: one exact unsigned direct supply/borrow call on Aave V3, Morpho Blue, Compound V3, or Moonwell on Base. The 'one exact ... call' framing implicitly separates it from the broader sibling base_lending_guard and from monad_lending_guard_exact_call, so an agent can route without reading 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?

It establishes the usable context (you must already have an exact unsigned transaction plus guard intent) and the downstream step: 'bind an ALLOW through PriorSeal or another user-authorization system.' It does not explicitly say when to choose this over base_lending_guard or pre_trade_safety_check, so alternatives are left 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?

With no annotations, the description carries the full burden. It does add genuine context by disclosing that results are stress-tests 'based on representative benchmark positions' rather than live positions, but it omits whether the call is read-only, what permissions are needed, and what the result shape or failure modes are.

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 short sentences, front-loaded with the action and scope, and the second sentence earns its place by disclosing the benchmark-position basis of the results. 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?

For a one-parameter tool with no output schema this is close to adequate, and the benchmark-positions caveat is helpful. It still leaves the agent without selection criteria against the many sibling risk tools and without any sense of what the stress-test output contains.

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

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

Schema description coverage is 100% and the single date parameter is fully documented there (format plus default-to-today). The description's 'for a specific date' merely restates the schema, adding no syntax or semantics beyond it, 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 ('Check protocol liquidation risk') scoped to a date, which is clear. It does not differentiate from sibling risk tools such as check_position_safety, get_risk_summary, or pre_trade_safety_check, so an agent must infer the boundary.

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 mention of prerequisites, and no routing to or away from the several sibling risk tools. The only implied usage cue is 'for a specific date,' which is not enough to select this over check_position_safety.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It says the tool checks safety against stress tests, but does not state whether it is read-only, what permissions are required, what assumptions the stress test makes, or what the output looks like. These are significant gaps for a 7-parameter tool.

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

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

The description is two tight sentences with no filler, and it front-loads the core purpose before noting the supported position types. It is appropriately sized, though it could be slightly more informative without becoming 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?

Given 7 parameters, no annotations, and no output schema, the description is too thin. It mentions multi-asset and single-asset support but does not explain the relationship between those parameter sets, required protocol context, or what the safety check returns, leaving the agent with material 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 100%, so the schema already documents each parameter's meaning, making a baseline of 3 appropriate. The description adds useful context that both multi-asset and single-asset position modes are supported, which helps interpret the two sets of fields, but it does not explain mutual exclusivity or when to use which mode.

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

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

The description clearly states a specific verb and resource: checking the safety of a DeFi lending position against oracle deviation stress tests. It distinguishes itself somewhat from siblings like check_liquidation_risk and pre_trade_safety_check by naming the oracle-stress-test scope, but it does not explicitly say how it differs from those tools.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as check_liquidation_risk or pre_trade_safety_check. Usage is only implied by the purpose statement, and no prerequisites or exclusion conditions are given.

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?

No annotations are provided, so the description carries the full burden. It does not disclose whether this is a read-only computation, what permissions or rate limits apply, how data is aggregated, or what the output contains. Only the word 'historical' implies a non-mutating query, which is insufficient behavioral detail for a tool with zero annotation coverage.

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, front-loaded with the core purpose and followed by the analytical benefit. Every sentence earns its place with no repetition or 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?

The tool has no output schema and no annotations, so the description should ideally explain return shape or key behavioral constraints. It gives a clear purpose and use case but omits return values, time range defaults, and any limitations. It is adequate for selection but incomplete for confident 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 100%, so the schema already documents symbol, from, to, and interval. The description adds no parameter-level meaning, such as date range defaults or interval behavior. A baseline of 3 is appropriate when the schema fully covers parameters.

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

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

The description states a specific verb (compare) and resource (historical price deviations across oracle providers) for an asset, and adds the intended insight (identifying consistently diverging providers). It does not explicitly differentiate itself from any of the many sibling tools that also report oracle data, 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 phrase 'Helps identify which providers consistently diverge from consensus' implies the analytical use case, but there is no explicit when-to-use guidance, no alternatives named (e.g., get_anomalies or get_oracle_health), and no exclusions. Usage must be inferred from the purpose.

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?

With no annotations, the description carries the full burden and does well: it discloses the three-value output (ALLOW/CAUTION/BLOCK), that missing evidence is enumerated, that a signed assessment may be returned, and that a pyth-only snapshot remains CAUTION under the quorum policy. It never explicitly labels the operation read-only or states auth/rate-limit behavior, so it is strong but not exhaustive.

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

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

The scope and exclusions are front-loaded in the first three sentences, and each sentence conveys new information. Some phrasing is dense ('chain-neutral', 'strict quorum policy') but 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 9-parameter tool with nested objects and no output schema, the description explains the decision outcome shape and the missing-evidence list, which is the key return-value context. It leaves the reviewed-pool lane semantics to the schema, which handles them adequately.

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

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

Schema coverage is already 89%, so the baseline is 3; the description adds real value on top by showing the targetProviders=["pyth"] usage pattern and explaining that fresh venue quote evidence is what lifts a result from CAUTION to ALLOW. It does not explain the reviewed-lane objects, though the schema covers those.

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 opening states a specific verb and resource: a 'data-sufficiency gate' for a named set of intended actions (swap, borrow, lend, liquidation, repay). It also explicitly bounds what the tool is NOT ('never contract safety, custody, profitability, or transaction execution'), which separates it from pre_trade_safety_check and the lending-guard 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?

It gives clear usage context (pre-execution check for an intended action) and a concrete configuration instruction for Monad via targetProviders=["pyth"], plus the rule that decisionInput is required for an ALLOW. It stops short of naming a sibling as the alternative for contract/custody safety, leaving that routing 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?

No annotations are provided, so the description carries the full burden. It discloses that Insight collects the on-chain fill, signs a receipt, and returns one of four verdicts (FAITHFUL / DEVIATED / NOT_EXECUTED / UNDETERMINED), which is useful behavioral context. It does not explain signing requirements, failure modes, rate limits, or how the receipt is secured, leaving gaps for a signing operation.

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

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

The description is four sentences and front-loads the core action and required inputs before describing the verdict and scope limitation. It is efficient, though the long list of fields in the first sentence is somewhat dense.

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 18-parameter signing tool with no output schema, the description covers purpose, required inputs, verdict output, scope boundaries, and related tools. It lacks details on signing requirements or error handling, but is otherwise complete enough for an agent to invoke correctly.

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

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

Schema description coverage is 100% and all 18 parameters are documented in the schema. The description groups the required pre-trade fields and settlement txHash, adding grouping context but no syntax or format details beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb and resource: it issues signed execution-price evidence comparing an observed fill to the oracle-assessed quote and signed slippage band, and returns a verdict. It distinguishes itself from siblings by explaining it pairs with pre_trade_safety_check and oracle_watch and produces a fidelity receipt rather than a safety or price query.

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

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

The description gives a clear context: provide the pre-trade fields plus settlement txHash after execution, and it names pre_trade_safety_check and oracle_watch as companion tools. It states what it does not do (principal authorization or overall transaction safety), which helps avoid misuse, though it doesn't explicitly state when not to call it versus verify_execution_pair.

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?

With no annotations, the description carries the full burden and does disclose meaningful behavior: data is 'fresh, block-pinned,' and Factory/QuoterV2/runtime code identities are re-verified at the quoted block, giving the agent confidence in integrity. The main gap is that it doesn't hint at what the returned 'market evidence' contains, which matters given there is no output schema.

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

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

Three compact sentences: what/scope first, integrity behavior second, disambiguation third. Every sentence is front-loaded and earns its place with 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?

For a single-parameter, fully-schema-covered read tool, the definition covers scope, freshness, integrity verification, and its relation to oracle pricing. The only shortfall is that, absent an output schema, it doesn't describe the shape or fields of the 'market evidence' returned.

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

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

Schema coverage is 100% and the single profileId parameter is fully documented with an enum and default (Base WETH/USDC CL100). The description adds the 'one allowlisted pool' constraint but no additional detail on the parameter beyond the schema, so baseline 3 applies.

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

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

States a specific verb ('Get') and a tightly scoped resource: fresh, block-pinned market evidence for one allowlisted Aerodrome Slipstream Base pool. It clearly distances itself from oracle price tooling, though it doesn't explicitly contrast with the generic sibling get_base_dex_market, so the boundary there is left to inference.

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 closing line 'This is DEX venue context, not an oracle-consensus price' explicitly routes agents away from oracle-consensus tools like get_consensus_price. The 'allowlisted' framing signals this only works for reviewed pools. However, no exclusion or comparison against get_base_dex_market is given, so one key alternative is unaddressed.

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?

No annotations are provided, so the description carries the full burden. It does not disclose pagination, result limits, whether data is cached, freshness, or what the aggregation entails beyond a high-level phrase. For a read tool with no annotation coverage, this is a meaningful gap.

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, front-loaded with the action and resource. No wasted words, though it could arguably be split to separate scope from return contents.

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 data-retrieval tool with no annotations, no output schema, and no parameter guidance beyond the schema, the description omits freshness, aggregation semantics, sorting, truncation limits, and error/empty behavior. It leaves too much for the agent to assume given the complexity of oracle event data.

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

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

Schema description coverage is 100% and the single 'days' parameter is fully documented in the schema, including min/max in constraints. The description mentions 'lookback period (1-30 days)' which duplicates the schema without adding syntax or default behavior. Baseline 3 is correct.

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 (Get) and resource (aggregated oracle anomaly events), with scope (lookback period 1-30 days) and content (top deviation events, risk impacts). It is fairly distinguishable from siblings like get_incidents or compare_oracle_deviation, though it doesn't explicitly name alternatives.

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 use this versus siblings such as get_incidents, compare_oracle_deviation, or get_oracle_health. The only contextual hint is the implied lookback default, leaving the agent to infer appropriate usage.

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?

With no annotations, the description carries the full burden, and it does disclose key behavioral traits beyond structure: the data is 'fresh' and 'block-pinned' (a staleness/pinning guarantee), the exact metrics returned, and the important scope caveat that this is not an oracle consensus. It omits failure modes, rate limits, and what happens if the pool is unavailable.

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

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

Two sentences, front-loaded with the verb and the data payload, with the scope disclaimer placed last where it belongs. No restatement of the name and 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?

No output schema exists, so the description must carry the return contents, and it does by listing the four evidence components. For a fixed-query, no-argument read tool this is nearly sufficient; only the response shape and failure behavior remain unspecified.

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

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

Zero parameters gives a baseline of 4, and the description justifies the empty schema by fixing the chain, venue, and pair (Base, Uniswap V3, WETH/USDC), so the agent understands there is nothing to configure. It does not clarify whether alternative pairs or blocks might be available in future.

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 definition pairs a specific verb ('Get') with a precisely scoped resource: block-pinned Base Uniswap V3 WETH/USDC market evidence, enumerating the four outputs (spot, 30-minute TWAP, active liquidity, quote ladder). The closing clause distinguishes it from oracle-price siblings like get_consensus_price and get_oracle_price by declaring it a single-venue DEX read.

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 line 'This is one DEX venue, not an oracle-consensus price' implicitly steers the agent away from consensus-price tools toward venue-level data, but no sibling is named and there is no explicit when-to-use or when-not-to-use statement, such as when a TWAP-based quote ladder is preferable to get_monad_dex_market or get_solana_dex_route equivalents.

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?

With no annotations, the description carries the full burden and does provide meaningful behavioral context: it is a block-pinned snapshot, the response distinguishes enabled unsigned-calldata lanes from read-only venues, and it explains the review condition for read-only status. It does not detail permissions, failure modes, or response structure, but covers the key behavioral distinction.

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

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

Two sentences, front-loaded with the core purpose. The venue list is long but necessary for clarity; the second sentence adds useful behavioral distinction. Minor redundancy from listing venues also present in the enum, but overall efficient.

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

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

For a simple read-only lookup with one optional parameter and no output schema, the description explains what evidence is returned and the enabled/read-only distinction. It does not specify the shape of the evidence payload, but it is complete enough for an agent to call the tool correctly.

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

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

Schema coverage is 100%, and the single 'venues' parameter is fully documented in the schema. The tool description lists the same venues in prose but adds no syntax, format, or selection semantics beyond what the schema already provides, so it meets the baseline of 3.

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 ('Get') and resource ('block-pinned code-identity evidence') scoped to reviewed Base DEX deployments, listing the covered venues. It is clearly distinct from market-data siblings like get_base_dex_market, but it never names or contrasts with those alternatives, leaving differentiation to inference.

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

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

Usage is implied by the tool's nature—use it to inspect code-identity evidence for reviewed Base venues—but there is no explicit when-to-use, when-not-to-use, or alternative selection guidance relative to the many other Base DEX and market tools.

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

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

With no annotations, the description carries the full behavioral burden. It adds meaningful context by saying the price is aggregated across multiple oracle providers and manipulation-resistant, but it omits operational details like read-only nature, rate limits, default method, staleness handling, and what the returned payload 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?

Two sentences, both front-loaded and free of filler. The purpose comes first, followed by the practical use case, with no wasted wording.

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 three-parameter read tool with full schema coverage and no annotations, the description is adequate: it explains what the tool returns and why to use it. It could be more complete by noting default behavior for optional parameters or the shape of the returned price data, but it covers the essentials.

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

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

Schema description coverage is 100%, and the schema documents all three parameters including enum values for 'chain' and 'method'. The description adds no parameter-level meaning beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description states a specific verb ('Get'), a specific resource ('aggregated consensus price'), and the source scope ('across multiple oracle providers'). It distinguishes the tool from single-provider siblings like get_oracle_price by emphasizing multi-oracle aggregation.

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

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

It gives a clear usage context ('robust, manipulation-resistant reference price') that tells the agent when the tool is appropriate. It does not name alternatives or when-not conditions, so it falls short of explicit routing 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?

No annotations are provided, so the description carries the full burden. It discloses the scope (asset + date range) and the computed statistic, but says nothing about the shape of the result (pairwise matrix), whether the operation is read-only, or any limits. Moderate detail, notable gaps.

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

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

Two compact sentences, front-loaded with the operation and scope, with no filler. Every sentence 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 and no annotations, the description should convey more about the return value (e.g. a provider-pair matrix) and any constraints. It covers what is computed but leaves the result shape and safety profile implicit.

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 symbol/from/to are already documented with formats and examples. The description only restates that the computation is per-asset over a date range, adding no syntax or default details beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource: 'Compute pairwise Pearson correlation of oracle provider deviations', scoped to an asset over a date range. It is understandable on its own, though it does not explicitly distinguish itself from nearby siblings like compare_oracle_deviation or get_provider_reputation.

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 'Helps identify independent vs correlated providers' implies the use case but does not say when to reach for this tool versus alternatives such as compare_oracle_deviation or get_provider_reputation. Usage is inferable but not explicit.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the output dimensions (provider, chain, symbol breakdowns) which is genuinely useful given there is no output schema, but says nothing about auth requirements, rate limits, or the precise shape of the response. Read-only nature is only implied by 'Identify'/'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?

Four compact clauses: definition, parenthetical disambiguation of the risk concept, return scope, and routing to the alternative. Front-loaded with the core purpose and no filler sentences.

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 annotations, the description supplies the essential missing context: what is returned and when to call it versus get_metrics. It stops short of describing the concrete response fields or ordering, but nothing critical for correct invocation is absent.

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. The description correctly implies there is nothing to configure and adds no misleading parameter hints.

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 ('Identify oracle coverage gaps and single-provider-risk symbols'), defines the key concept inline (assets served by only one oracle = concentration risk), and tells the agent what it returns (breakdowns by provider, chain, symbol). It explicitly contrasts itself with get_metrics, so an agent can pick it without opening sibling 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?

Gives an explicit use condition ('Use this when assessing where coverage is thin') and names the alternative with its selecting condition ('For ecosystem scale plus top reputable providers, use get_metrics instead'). This is the when/when-not/alternative pattern in full.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read-style operation through 'Get' and gives use-case context, but it does not state whether the operation is read-only, how fresh the data is, whether there are rate limits, or what the response 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?

The description is two short sentences, front-loads the core operation, and follows with relevant use-case context. There is no wasted text.

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

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

For a simple read tool with full schema coverage and no output schema, the description is minimally adequate. It is missing details about how baseChain affects the result and what the pairwise spread output includes, which would help an agent use it correctly.

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

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

Schema description coverage is 100%, so the schema already fully documents provider, symbol, and baseChain with enums and descriptions. The description mentions provider and symbol but adds no additional meaning, and it does not explain the role of the optional baseChain parameter. Baseline 3 applies.

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

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

The description states a specific verb and resource: getting pairwise price spreads across chains for a provider and symbol. It is clear what the tool does, but it does not differentiate the tool from nearby siblings such as compare_oracle_deviation or get_correlation.

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 'Useful for cross-chain arbitrage and risk tracking' gives implied usage context, but it does not explicitly say when to use this tool versus alternatives or when not to use it. An agent must infer the selection criteria from the name and use cases.

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?

No annotations are provided, so the description carries the full burden. It helpfully discloses what the report contains (liquidation risks, anomalies, market summary), which implies a read-only aggregate, but says nothing about auth requirements, rate limits, data freshness, or whether the report is cached/precomputed.

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 resource and its contents; nothing is wasted or 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, the description usefully enumerates the report's sections so an agent knows roughly what comes back. For a one-parameter read tool this is nearly sufficient, though it omits behavioral caveats and any routing guidance versus similar siblings.

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

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

Schema coverage is 100% and there is only one parameter, whose format and default are fully documented in the schema. The description's 'for a specific date' merely restates the parameter, adding no format or edge-case detail beyond the schema.

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

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

States a specific verb+resource ('Get the full daily oracle/risk report') and enumerates the contents (liquidation risks, anomalies, market summary). It does not, however, distinguish itself from siblings like get_risk_summary or get_anomalies, which cover overlapping territory.

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 when-to-use statement and no mention of alternatives, despite several siblings (get_risk_summary, get_anomalies, check_liquidation_risk) that an agent must choose between. The date-scoping is implied only by the description's phrasing.

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?

No annotations are provided, so the description carries the full burden. 'Scan' and 'find feeds needing attention' establish a read-only, diagnostic operation and the 'many active feeds' phrasing scopes the population, but it never says what the response contains (per-feed status rows? aggregated counts?), whether pagination or limits apply, or how 'stale' is thresholded. Useful but incomplete behavioral disclosure.

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

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

Two tight sentences: capability and scope first, then routing to alternatives. Zero filler and no redundancy with the schema.

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-required-parameter read tool, the description gives everything needed to decide when to call it and with what filters. The remaining gap is the absence of any signal about the return shape, which matters more here because no output schema exists to compensate.

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

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

Schema description coverage is 100% and both enums are enumerated in the schema, so the parameters are already fully documented. The description only restates the three filter dimensions ('provider, symbol, or category') without adding combination semantics (e.g., whether filters AND together) or defaults, 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?

Specific verb ('Scan') plus resource ('current freshness/staleness') plus scope ('many active feeds') and an enumeration of filter dimensions. It explicitly separates itself from get_feed_health (single UUID) and get_oracle_health (dated ecosystem report), so an agent can route without opening any schema.

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

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

Gives the positive trigger ('Use this to find feeds needing attention right now') and then names two concrete alternatives with the exact condition that selects each. Nothing is left 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?

With no annotations, the description carries the full behavioral burden. It discloses the returned fields and the point-in-time nature of the snapshot, which is useful. However, it says nothing about behavior for unknown/invalid UUIDs, auth requirements, or rate limits.

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

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

Two sentences with zero waste. The core scope (one feed, by UUID) is front-loaded, followed by the sibling-routing clause; every clause earns its place.

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

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

For a simple single-parameter read tool with no output schema, listing the returned facets and the disambiguation from two siblings covers nearly everything needed. The only gap is behavior on invalid or unknown UUIDs.

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

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

Schema description coverage is 100% and the single feedId parameter is already documented as an Oracle feed UUID with a format and pattern. The description restates 'by its UUID' but adds no syntax or constraint detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (Get), resource (oracle feed health), and scope limitation (ONE specific feed by UUID), and enumerates the returned facets: consecutive failures, last success/failure, status. It explicitly distinguishes itself from sibling tools get_oracle_health and get_feed_freshness.

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

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

It gives explicit alternatives with the condition that selects each: use get_oracle_health for ecosystem-wide health by date, use get_feed_freshness to scan freshness across many feeds. An agent can route correctly without 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?

No annotations are provided, so the description carries the full behavioral burden. 'List' implies a read-only registry lookup, but the description does not discuss pagination behavior, response size, permissions, or whether filtering is applied server-side; for a low-risk list tool this is adequate but not rich.

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

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

The description is two sentences, front-loads the main action and resource, and then adds a concise discovery use case. Every sentence contributes without repetition.

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

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

The schema is rich and fully described, but there is no output schema and the description only vaguely says 'metadata.' For a discovery tool with seven filters and no annotations, it would benefit from more detail about returned feed fields or intended workflow positioning against sibling tools.

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 seven parameters, including enums for provider and category. The description names most filter dimensions but omits limit/offset and adds no syntax or defaulting details beyond the schema, so baseline 3 is appropriate.

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

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

The description states a specific verb and resource: list oracle feeds from the registry. It also names the optional filter dimensions and frames the tool as a discovery/metadata lookup, which helps distinguish it from price, health, and incident tools. It stops short of explicitly differentiating itself from close siblings such as get_symbols or get_coverage.

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 'Useful for discovering available feeds and their metadata' gives implied usage guidance, but the description does not state when to use this tool instead of sibling discovery or lookup tools. There are no explicit exclusions or alternative-routing instructions.

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?

No annotations are supplied, so the description carries the full behavioral burden. It does disclose the computed outputs and the per-provider+symbol aggregation grain, which is real context, but it omits what happens when from/to are omitted (schema marks all four params optional), the granularity/aggregation window, and any cost or rate-limit characteristics. Adequate but with clear gaps for an unannotated analysis tool.

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

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

Two sentences, both front-loaded and dense with usable information: the first names the metrics, the second routes to alternatives. No filler and no restatement of the tool name.

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 annotations, the description compensates well by enumerating the returned metrics and the aggregation grain. The remaining gap is the unspecified default date range and time bucketing, which materially affects how the agent should call it.

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%, including date patterns and the provider enum, so the baseline is 3. The description adds only the grouping semantics ('per provider+symbol'), and says nothing about default date windows or how symbol/provider filters interact with the date range, so it adds marginal value beyond the schema.

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

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

Specific verb ('Analyze') plus resource ('feed data-delivery reliability over a date range') and it enumerates the exact metrics returned (success rate, hours with data, coverage %, avg snapshots per day). It explicitly distinguishes itself from two named siblings, get_feed_health and get_latency, so an agent can select it without opening a schema.

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

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

States the selection criterion directly: use this for completeness-over-time, whereas get_feed_health is point-in-time status and get_latency is speed. That maps three sibling tools onto three distinct questions, leaving little inference for the agent.

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?

With no annotations provided, the description carries the full burden and does meaningful work: it declares the tool read-only, signals that values are 'fresh' and that impact figures are 'bounded' estimates rather than exact, and warns that the output is not an executable quote. Missing are rate/latency behavior of the 'fast-quoter' proxy, staleness guarantees, and what happens when the venue is unreachable or the proxy set changes.

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

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

Two sentences, front-loaded with verb and resource, then a compact list of returned data, then a single scoping disclaimer. Given there is no output schema, the field enumeration earns its place rather than being redundant padding.

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

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

With no annotations and no output schema, the description supplies the two things an agent most needs: what comes back and that the data is context rather than a tradeable quote. Gaps remain around refresh cadence ('fresh' is unquantified) and error/degraded-venue behavior, which matter for a live market-context tool.

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

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

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The description's field enumeration is useful for interpreting output but is not parameter semantics.

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 ('Get') plus a precisely scoped resource ('fresh Hanji Monad MON/USDC CLOB context'), followed by an enumeration of exactly what the response contains (proxy identities, L2 spread, displayed depth, book-impact estimates). It also draws a clear line against adjacent concepts ('not an oracle-consensus price or executable order quote'), which separates it from get_consensus_price and the prepare_*_swap 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 exclusion clause ('read-only venue context, not an oracle-consensus price or executable order quote') tells an agent when NOT to reach for this tool, which is valuable given how many price/quote siblings exist. However, it never states a positive trigger ('use when inspecting MON/USDC book depth before sizing') and names no sibling alternative explicitly, so routing still requires 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?

With no annotations, the description carries full burden and discloses important behavioral traits: read-only, CLOB context, non-executable quote, non-consensus price, and the exact evidence fields returned. It omits operational details like rate limits or error behavior, but for a read-only data tool this is largely sufficient.

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 tightly written sentences: the first front-loads what the tool returns, the second clarifies what it is not. Every phrase earns its place with no redundancy.

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

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

Given one parameter, no output schema, and no annotations, the description is largely complete: it lists all returned evidence types and draws key boundaries (not consensus price, not executable quote). Minor gaps remain around freshness guarantees or failure modes, but the essential context is present.

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

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

Schema description coverage is 100% and the single enum parameter is fully documented with a default to BTC. The description reinforces the supported markets ('reviewed BTC, ETH, or HYPE market') but adds no semantics beyond the schema, so a baseline 3 is appropriate.

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 (Get) and resource (Hyperliquid mainnet perpetual-market evidence), then enumerates the data fields returned. It explicitly contrasts with oracle-consensus prices and executable quotes, which distinguishes it from siblings like get_consensus_price and execution_preflight.

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?

Clearly scopes usage to 'reviewed BTC, ETH, or HYPE market' and says it is read-only CLOB context, not an oracle-consensus price or executable exchange quote. However, it does not name a specific sibling tool to use instead for alternative needs, leaving some inference to the agent.

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?

With no annotations, the description must carry the safety profile; 'Get' implies a read-only query, and the date-range scoping is disclosed. However, nothing is said about pagination behavior, default/maximum result counts, ordering, or what an incident record contains, so the behavioral picture is only partially filled in.

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 short sentences, front-loaded with the core purpose, and zero redundant text. Nothing could be removed without losing information.

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

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

For a read-only list tool with full schema coverage and no output schema, the definition covers purpose and filters adequately. The main omissions are return-volume expectations (limit/offset semantics up to the 200 cap) and whether the date range is effectively required despite no required parameters.

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 all six parameters including the two enums (provider, minSeverity) are already documented in structured form. The description only restates the filter concepts without adding format/semantic detail (e.g., whether minSeverity is inclusive, or how from/to boundaries are treated), 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 and resource ('Get oracle incidents and deviation events') plus the scoping mechanism (date range, provider, minimum severity). It is distinguishable from neighbors like get_anomalies and oracle_watch by naming incidents/deviations, though it does not explicitly contrast itself with those 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?

Usage is implied by the date-range and filter framing, but there is no explicit statement of when to prefer this over get_anomalies, oracle_watch, or oracle_watch_history, and no prerequisites or exclusions are given. The agent must infer the choice from sibling names 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?

With no annotations, the description carries the full behavioral burden. It discloses the 15-minute granularity and the computed statistics, which is useful context, but it does not state that the operation is read-only, mention rate limits, or describe how the data is aggregated or 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?

The description is a single, front-loaded sentence that packs the key information—what is analyzed, the granularity, the statistics, and the optional filters—without any filler or redundancy.

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

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

For a query tool with four optional parameters and no output schema, the description is adequate but leaves gaps. It does not explain the return structure or behavioral traits like read-only safety, and with no annotations the agent has to infer these details.

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 all four parameters are fully documented in the schema itself. The description adds only a high-level note that provider and symbol are optional filters and that a date range is required, without providing format or syntax details beyond what the schema already provides.

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 ('Analyze') and names the resource ('15-minute oracle collector latency statistics') with enumerated metrics, making its purpose clear. It does not explicitly differentiate itself from siblings like get_feed_uptime or get_metrics, but the focus on latency statistics is distinctive enough to infer the difference.

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 guidance on when to use this tool versus alternatives such as get_feed_uptime, get_metrics, or get_anomalies. It only implies its use case by stating it analyzes latency over a date range, leaving the agent to infer selection criteria.

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?

No annotations exist, so the description carries the full behavioral burden. It usefully discloses what is returned (counts and a reputation-ranked provider list), which matters since there is no output schema, but it never states that this is a read-only/non-mutating snapshot, nor any rate limits or permissions. Adequate but with clear gaps given zero annotation coverage.

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

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

Three tight sentences, front-loaded with what it returns before the usage routing. Every sentence earns its place; no filler or restatement of the name.

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 parameterless, annotation-free tool with no output schema, the description supplies the return contents and the routing decision, which is most of what an agent needs. Minor gap: it does not confirm the operation is read-only or describe the shape/size of the ranked list beyond 'top providers'.

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 per the rubric the baseline is 4. There is nothing for the description to disambiguate, and it correctly does not invent filtering options.

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

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

States a specific resource (compact ecosystem overview) and enumerates the exact contents returned: provider/feed/symbol/chain/category counts plus top providers ranked by reputation score. It also explicitly distinguishes itself from the get_coverage sibling, so an agent can route between them without opening 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?

Gives explicit when-to-use conditions ('quick scale snapshot or provider ranking') and names the alternative plus the condition that selects it ('To find coverage gaps and single-provider risk, use get_coverage instead'). Both routing directions are stated, nothing is left 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?

With no annotations, the description carries the full burden and does disclose meaningful behavior: data is fresh and block-pinned, volume is finalized rather than partial, and the values are single-venue rather than consensus — an important caveat that prevents misuse as an oracle price. It omits operational traits such as staleness thresholds, behavior when the pool is unavailable, and any caching/rate-limit notes.

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

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

Two sentences, front-loaded with the verb and resource, followed immediately by the payload enumeration and the disambiguating caveat. No filler; every clause adds either scope or differentiation.

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 convey return content and does so by naming the five data components returned. For a zero-parameter read tool that is largely sufficient, though it leaves open what an agent should expect when the venue has no fresh block or the ladder is empty.

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 4 applies. The description correctly implies a parameterless call by specifying the fixed pair (WMON/USDC) and chain (Monad) inline.

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 (get) and a precisely scoped resource (Monad Uniswap V3 WMON/USDC market evidence), then enumerates exactly what comes back: spot, 15-minute TWAP, active liquidity, quote ladder, rolling volume. The closing clause distinguishes it from oracle-consensus price tools, so an agent can separate it from get_oracle_price/get_consensus_price without opening any schema.

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

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

The clause 'single-venue DEX market source, not an oracle-consensus price' gives clear selection context and implicitly routes price-consensus questions to the oracle siblings. It stops short of an explicit 'use this when X, use Y when Z' statement, so the routing is inferential rather than spelled out.

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?

With no annotations, the description carries the full burden, and it does disclose the report's dimensions (uptime, staleness, success rates) and that it is ecosystem-wide. It stops short of stating that this is a non-mutating read or how it behaves for dates with no data, but the scope and content disclosure are substantial.

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

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

Three tightly front-loaded sentences: purpose first, then usage, then alternatives. Every sentence carries routing or scope information with no padding.

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

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

No output schema exists, and the description compensates by naming what the report returns. The single optional date parameter is fully covered by the schema, so nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100% and the schema already documents the date pattern (YYYY-MM-DD) and the today default. The description only adds 'for a specific date', matching rather than exceeding the schema, so baseline 3 applies.

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

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

States a specific verb (Get) plus resource (ecosystem-wide oracle health report) and scope (all providers), and enumerates the report's contents (uptime, staleness, success rates). It explicitly distinguishes itself from get_feed_health and get_feed_freshness by name.

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

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

Explicitly says when to use it ('a dated snapshot of overall health') and names both alternatives with the condition that selects each: a single feed by UUID vs. scanning current freshness across many feeds. Nothing is left 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?

No annotations are supplied, so the description carries the full disclosure burden, and it does convey that results are 'latest' (not historical) and provider-scoped. It says nothing about caching semantics implied by the forceRefresh parameter, staleness/fallback behavior, or what errors occur when a provider does not cover the requested asset/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 front-loaded sentence with no filler, and the operation is stated immediately. It is efficient but so terse that it leaves the sibling-routing and return-shape questions entirely unaddressed.

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 input schema is fully documented and covers all four parameters, so callers can construct a request. With no output schema and no annotations, the description should have said what comes back (price value, decimals, timestamp, freshness) and how the default chain is resolved; those gaps remain.

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

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

Schema description coverage is 100% and both enums are documented inline, so the schema does the heavy lifting for provider, symbol and chain. The description adds no parameter-level meaning beyond that, such as what happens when chain is omitted or how symbol formats like 'BTC/USD' map to a provider's feed 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?

States a specific verb ('Fetch') and resource ('latest price') and scopes it to 'a specific oracle provider for an asset', which implicitly separates it from get_consensus_price and get_price_history. It never names a sibling explicitly, so the agent must infer the boundary with get_oracle_prices_batch and get_consensus_price on its own.

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 'specific oracle provider' implies single-provider spot lookup rather than an aggregated or historical query, which is a usable hint. However, there is no explicit when-to-use/when-not guidance, no mention of when to prefer get_consensus_price or get_oracle_prices_batch, and no prerequisites such as whether a symbol must be supported by that provider.

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?

No annotations are provided, so the description carries the full burden. It mentions nothing about caching behavior (only implied by the schema's forceRefresh), rate limits, per-query partial-failure handling, or auth requirements – significant gaps for a batch network 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?

Two short, front-loaded sentences with no filler and the batch nature stated first. It is efficiently sized, though extremely terse for a tool with behavioral nuances.

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?

Inputs are fully covered by the schema and no output schema exists, so the description needn't explain return values. But with no annotations, it should say more about result ordering, per-query error semantics, and caching – gaps that matter for a batch tool.

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

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

Schema description coverage is 100%, so the schema already documents queries, symbol, provider, chain, and forceRefresh. The description only restates the maxItems=20 cap already encoded in the schema, adding no new 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?

States a specific verb and resource ('Fetch prices') with explicit batch scope ('multiple assets/providers in a single request'). This implicitly separates it from the singular get_oracle_price sibling, but it never names an alternative outright.

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?

'multiple ... in a single request' implies the batch use case, so an agent can infer when this beats the single-asset tool. However, there is no explicit guidance on when to prefer it over get_oracle_price, get_consensus_price, or get_oracle_health, and no exclusion criteria.

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?

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: values are block-pinned, and the Factory, QuoterV2, and Pool runtime identities are re-verified at the quoted block. It stops short of stating read-only semantics explicitly, latency/RPC cost, or failure behavior for an unverified pool.

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 redundancy, and the core purpose plus the block-pinning guarantee are front-loaded. The negative scoping sentence earns its place by preventing confusion with oracle price tools.

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 convey what 'market evidence' actually returns (quote amounts, tick/liquidity, gas estimate, verification status). It pins the trust model well but leaves the payload shape ambiguous, which is the main gap for a single-param 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 coverage is 100% and the single profileId enum already documents the only valid pool id with its default, so the schema does the heavy lifting. The description reinforces the 'allowlisted'/'one pool' constraint but adds no format or selection detail beyond what the enum and its description provide.

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 ('Get fresh, block-pinned market evidence') scoped to exactly one allowlisted PancakeSwap V3 Base pool. It also draws an explicit boundary against the oracle-price siblings ('not an oracle-consensus price'), so an agent can separate it from get_consensus_price and get_base_dex_market without opening a schema.

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

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

The clause 'This is DEX venue context, not an oracle-consensus price' implicitly routes the agent away from oracle tools, which is a real usage signal. However, it never states the positive condition for choosing this over get_base_dex_market, get_aerodrome_slipstream_market, or prepare_pancakeswap_v3_swap, and gives no explicit when-not 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?

No annotations exist, so the description carries the full behavioral burden, yet it discloses nothing about caching (only the schema mentions a cache via forceRefresh), rate limits, or required permissions. It also omits the maximum lookback window (8760 hours) and any indication of data granularity or result size.

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 provider, asset, and period dimensions all appear immediately. Nothing redundant is included.

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 annotations and no output schema, the description should at least sketch the return shape (time-series points, granularity, sample count) and caching/rate-limit behavior. The input side is fully covered by the schema, but the output and behavioral sides are left entirely to inference.

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 five parameters including the enum lists and the period range. The description's only added phrasing ('over a period (in hours)') restates the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource: 'Get historical price data for an asset' from 'a specific oracle provider over a period (in hours)'. The word 'historical' implicitly separates it from get_oracle_price/get_consensus_price, but no sibling is named or explicitly excluded.

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 via the term 'historical' – an agent can infer this is the tool for time-series price lookups versus the spot-price siblings, but there is no explicit when-to-use, when-not, or alternative named. No prerequisites or provider-selection guidance are given.

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?

No annotations are provided, so the description carries the full disclosure burden. It does disclose the return content (provider/asset coverage plus concentration metrics), which implies a read-only analysis, but it never explicitly states the operation is read-only, nor does it mention permissions, data freshness, or limits.

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, front-loading the analysis purpose before the output content. Every clause earns its place.

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

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

For a single-parameter read tool with no output schema, the description adequately conveys purpose and return shape, so an agent knows what it will get. It stops short of complete because it omits any read-only/permission note and any sense of data scope or recency.

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

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

Schema coverage is 100% and the single parameter is well documented with examples (aave-v3, compound-v3), so the schema does the heavy lifting. The description adds only that the protocol must be a lending protocol, a marginal elaboration rather than new semantic detail.

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: analyzing oracle provider concentration risk for a specific lending protocol, plus the two things it surfaces (provider-asset coverage, concentration metrics). It is distinguishable from general siblings like get_protocol_risk_params, but never names a sibling or clarifies the boundary with related oracle-exposure tools.

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

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

Usage is only implied by the scoping phrase 'for a specific lending protocol' and the concentration-risk framing. There is no explicit when-to-use guidance, no exclusions, and no pointer to alternatives such as get_protocol_risk_params or get_oracle_health.

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

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

No annotations are provided, so the description bears the full disclosure burden. It implies a read operation via 'Get' but says nothing about whether these are static protocol config values vs. live values, whether results are cached, or any auth/permission requirements. That is a meaningful gap for a tool with zero annotation coverage.

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 tight, front-loaded sentence with no filler. Every clause earns its place by naming the resource and the returned field categories. Not padded, but also very short, leaving little room for structure.

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

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

For a simple single-parameter read tool with no output schema, the description does list the key returned fields (liquidation thresholds, LTV ratios, collateral factors), which partially compensates for the missing output schema. Only the absence of usage context keeps it from being fully complete.

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

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

Schema coverage is 100% and the single `protocol` parameter is fully documented with format examples (aave-v3, compound-v3) in the schema. The description adds only the phrase 'for a specific DeFi protocol', which is already implied. Baseline 3 is appropriate since the schema does the heavy lifting.

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 (Get) and resource (risk parameters for a specific DeFi protocol), and enumerates the concrete fields returned (liquidation thresholds, LTV ratios, collateral factors). It does not, however, differentiate itself from near siblings like get_risk_summary or check_liquidation_risk, 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?

There is no guidance on when to use this tool versus the many adjacent risk tools (get_risk_summary, check_liquidation_risk, check_position_safety, pre_trade_safety_check). No prerequisites, no exclusions, no named alternative. 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?

With no annotations, the description carries the full load, and it does disclose the fields returned (TVL, asset counts, oracle providers), implying a read-only listing. However, it says nothing about pagination, result limits, ordering, or freshness of the 'dynamic data', which an agent would want for a listing endpoint.

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

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

Two compact sentences with the core purpose and return contents front-loaded, and the filter mentioned second. No wasted words, though formatting as a distinct usage line could improve scanability.

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

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

For a simple optional-filter list tool with no output schema, one parameter at full schema coverage, and no nested structures, the description covers purpose and return contents adequately. Missing pagination/ordering notes keep it from a 5.

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

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

Schema coverage is 100% for the single query parameter, so the schema already documents it. The description adds only that the query matches name/slug, a marginal clarification beyond the schema's 'search query to filter protocols'.

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 (Get) and resource (lending protocols) and enumerates the returned data (TVL, asset counts, oracle providers), which distinguishes it from siblings like get_feeds or get_stablecoin_list. It stops short of explicitly contrasting with those siblings, but the resource is clear enough to route correctly.

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 only notes that the query filter is optional; there is no guidance on when to reach for this tool versus related siblings such as get_protocol_oracle_exposure or get_protocol_risk_params. Usage must be inferred from the resource name.

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

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

No annotations are provided, so the description carries the burden. 'Get' implies a read-only operation, which is useful context, but it says nothing about what metrics are returned, whether results are cached, or auth requirements. With no output schema, this leaves notable behavioral gaps.

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 waste; the resource and the optional trend qualifier are both stated efficiently.

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 no annotations and no output schema, the description should say more about what 'reputation metrics' actually comprise and what the trend data looks like. As written it is adequate to identify the tool but under-specifies the return contract.

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

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

Schema coverage is 100% and all three parameters are documented in the schema itself, so the baseline of 3 applies. The description only adds the linking of 'historical trend' to the trend/days parameters, no extra syntax or format detail.

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 ('Get'), resource ('reputation metrics') and scope ('a specific oracle provider'), and flags the optional trend dimension. The singular 'specific provider' implicitly distinguishes it from the sibling get_reputation_rankings, though it never names that 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 'optionally with historical trend' hints that trend/days are opt-in, but there is no explicit when-to-use guidance or named alternatives (e.g. get_reputation_rankings for multi-provider comparison). Usage is only implied.

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

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

With no annotations, the description must carry the full behavioral burden, and it does disclose meaningful traits: the snapshot is 'fresh, block-pinned', the scope is one reviewed pair, and the quote ladder is 'bounded'. However it never states that the call is a read-only/no-side-effect operation, how block-pinning is enforced or how stale it can be, what 'bounded' means for the ladder, or anything about latency/rate limits. Useful context, but incomplete for a zero-annotation tool.

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

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

Two sentences, front-loaded with the verb+resource, followed immediately by the scope disambiguation. Every clause earns its place: the field inventory tells the agent what comes back, and the negation clause prevents mis-selection.

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, yet the description enumerates the returned evidence, which is exactly what the agent needs to judge suitability. For a one-parameter, single-pair market read, the remaining gap is mainly the absence of an explicit read-only/freshness statement, which is borderline given the 'block-pinned' wording.

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 optional parameter is fully described in the schema (enum of the one reviewed pair id, with a default), so the schema does the work and the description adds nothing about it. 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 ('Get'), resource ('Base QuickSwap V2 USDC/USDT market evidence'), and enumerates the payload (factory/router/pair identities, reserves, spot, quote ladder). It also draws explicit boundaries against siblings: 'not an oracle-consensus price' (cf. get_consensus_price) and 'not a generic QuickSwap route' (cf. route/swap tools), so an agent can select it between near-neighbors without reading either schema.

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

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

The negative framing ('This is one reviewed pair, not an oracle-consensus price or a generic QuickSwap route') gives an agent a clear condition for when to pick this tool and when to reach for consensus or route tools instead. It stops short of prescribing positive usage conditions or naming the alternatives by tool name, so it is strong but not fully explicit.

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?

With no annotations, the description carries the full burden, and it does convey that this is a read-style aggregation returning rankings plus a trend over a window. However, it says nothing about ranking criteria, whether results are cached/refreshed, ordering, or permissions, so behavioral disclosure remains thin.

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 tight sentence with the resource and the modifier front-loaded and no filler. Nothing in it is wasted.

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

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

For a simple read tool with one fully described parameter and no output schema, the definition is serviceable but leaves the agent guessing what the ranking output contains and how it differs from the sibling reputation endpoint. Adequate but with clear 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?

There is a single parameter and schema description coverage is 100%, so the schema already documents 'days' with its 1-90 bounds. The description only repeats the same (1-90 days) range and adds no extra semantics such as default window behavior, so the baseline of 3 applies.

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

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

The description names a specific verb and resource ('Get oracle provider reputation rankings') and adds the returned dimension ('with trend'), so an agent knows what it produces. It does not distinguish itself from the sibling get_provider_reputation, leaving the ranking-vs-individual-reputation distinction 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?

There is no when-to-use guidance, no prerequisites, and no mention of the closely related get_provider_reputation sibling. The agent must infer that this is the aggregated-ranking endpoint rather than the per-provider lookup.

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?

With no annotations, the description carries the full burden; 'Get ... summary' implies a read-only, non-destructive operation, which is reasonable but unstated. It does add real behavioral value by disclosing what the composite actually aggregates, which is beyond structured fields. Missing: cost/latency expectations, whether the summary is a score or a structured breakdown, and the two-provider minimum needed for any comparison to be meaningful.

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

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

Two sentences, zero padding, with the core purpose front-loaded and the dimension list following as supporting detail. Every clause contributes either scope or content 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 3-parameter read tool with a fully documented schema and no output schema, the description supplies the one thing the schema cannot: what the composite summary contains. It falls short only on interpretation guidance (what a high HHI or weak manipulation-resistance result means) and on the fact that a cross-provider composite requires at least two providers to be analytically meaningful.

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% — symbol, providers, and period are all documented with bounds and examples in the schema itself. The description adds only the framing 'across selected oracle providers', which restates the providers parameter without extra semantics such as how provider mix affects the aggregate.

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: a composite risk summary for an asset across selected oracle providers, then enumerates the six dimensions it aggregates (HHI, volatility, correlation, freshness, manipulation resistance, shared-dependency). That enumeration implicitly differentiates it from single-dimension siblings like get_correlation or get_feed_freshness, though it never names a sibling 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 guidance on when to choose this over get_oracle_health, get_protocol_oracle_exposure, compare_oracle_deviation, or pre_trade_safety_check, all of which overlap in domain. 'Across selected oracle providers' hints that it is multi-provider comparative analysis rather than a single-feed check, but the agent must infer this.

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?

With no annotations, the description carries the full burden and does meaningful work: it discloses that the data is first-party (not an independent oracle), that it never counts toward oracle quorum, and that it does not authorize a trade. Those authority/trust limits are exactly the kind of behavioral context structured fields cannot convey. It still omits freshness/staleness behavior and failure modes, so it is not exhaustive.

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 tightly packed sentences with zero filler. The capability list is front-loaded and the scope limitation follows immediately, so an agent gets the 'what' and the 'how far you can trust it' in one pass.

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 annotations and no output schema, the description enumerates the returned data domains and sets trust boundaries, which is most of what is needed. It falls short of 5 only because it does not address response shape, staleness, or what happens when on-chain verification fails or is unavailable.

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 are already documented in the schema, including the verifyOnchain cross-check semantics. The description reinforces the reference-price and on-chain verification concepts but adds no syntax, format, or default behavior beyond what the schema states. Baseline 3 is appropriate.

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 ('Get') and a precisely scoped resource ('Robinhood Stock Token issuer context'), then enumerates the contents: asset identity, trading capabilities, halt state, corporate actions, reference price, ERC-8056 verification. This is far more than a restated name. It stops short of 5 because it never contrasts itself with the very close sibling get_robinhood_rwa_instrument, leaving the agent to infer the boundary between 'issuer context' and 'instrument'.

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 second sentence establishes the tool's role in the workflow ('First-party evidence only... not an independent oracle'), which implies when its output is and isn't authoritative. However, there is no explicit when-to-use guidance and no named alternative, even though assess_rwa_evidence and get_robinhood_rwa_instrument sit adjacent and could plausibly be confused with it.

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?

With no annotations, the description must carry the full behavioral burden. It usefully discloses the cross-checking behavior (issuer UID, ISIN, contract deployment) and the safety scope (reference/admission evidence only, no trade authorization), which is meaningful context. It stops short of stating authentication needs, idempotency, or what the resolution returns on failure.

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

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

Two sentences, front-loaded with the core action and followed by a scoping disclaimer, with no filler. The dense domain jargon (FIGI, MIC, UID, ISIN) is efficient but slightly raises parsing cost.

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

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

For a 2-parameter tool with no output schema and no annotations, the description covers the resolution logic and safety scope adequately. It does not describe the returned master-data shape, which leaves a modest gap given the absence of an output schema.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema, setting the baseline at 3. The description mentions the underlying identifiers (FIGI, MIC) but adds no syntax, format, or default behavior beyond what the schema already provides for 'symbol' and 'verifyOnchain'.

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

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

The description opens with a specific verb and resource: 'Resolve a Robinhood Stock Token to Insight committed master data,' and details the resolution keys (share-class FIGI, ISO 10383 MIC). It is highly specific, but it does not name the close sibling get_robinhood_rwa_context, so an agent must infer the boundary between the two.

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 provides a clear exclusion ('never counts toward price quorum or authorizes a trade') that tells the agent this is reference-only, not a trading gate. However, it never states when to prefer this over assess_rwa_evidence or get_robinhood_rwa_context, so the routing guidance is only implied.

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

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

With no annotations, the description must carry the behavioral burden. It usefully discloses non-execution ('not a simulated or guaranteed swap'), freshness, and finalized RPC witness provenance. It omits rate limits, auth needs, failure behavior, and the fixed input sizing assumption, so it is strong but not complete.

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. The first front-loads the action and enumerates returned evidence; the second adds the key non-execution limitation. No redundant restatement of the name or 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?

Given no output schema and no annotations, the description does useful work by listing returned evidence and clarifying that this is not a simulated swap. However, an exact-input route quote requires an input amount, and with zero parameters the description never states the fixed/default amount or sizing assumption, leaving an important contextual 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?

The tool has zero parameters, so the baseline is 4 and there is no parameter-level schema to supplement. The description could note the implicit quote size, but with no parameters present there is little additional parameter semantics to provide.

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?

Uses a specific verb ('Get') plus a precise resource ('Jupiter SOL/USDC exact-input route evidence') and enumerates the evidence fields. The chain, DEX, and pair scope clearly distinguish it from generic DEX market tools and execution-oriented 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 use case is clear: fetch fresh SOL/USDC route evidence. It also explicitly excludes simulation or guaranteed swap interpretation, which helps avoid confusion with execution/preflight tools. It does not name a sibling alternative or give a fuller when-not condition, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose return format, whether 'tracked' implies a curated/whitelisted set, or ordering. 'List all' implies a read-only operation but this is minimal for a tool with zero annotation coverage.

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 wasted words, front-loaded with the verb and resource. Ideal brevity for a simple listing tool.

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 one optional parameter and no output schema, the tool is simple enough that the description is largely adequate. However, with no annotations, no output schema, and no usage guidance, an agent has gaps around return shape and how this differs from get_symbols or get_stablecoin_peg.

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 schema fully documents the optional query parameter. The description adds no information about the semantics of 'query' (e.g., substring match vs symbol prefix) beyond what the schema provides. Baseline 3 is appropriate.

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 (tracked stablecoin symbols), distinguishing it from siblings like get_symbols and get_stablecoin_peg. The word 'tracked' adds useful scoping.

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 use this versus get_symbols or get_stablecoin_peg. The agent must infer from the name alone that this is the stablecoin-specific listing.

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?

No annotations are provided, so the description carries the full burden. It never defines what "peg status" contains (deviation value, threshold, direction), whether the result is cached or real-time, or what freshness guarantees apply. For a read query whose entire value is the returned status, this is a substantive gap.

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 short sentences, front-loaded with the purpose and then the parameter behavior. No filler, padding, or 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?

For a simple one-optional-parameter query, the description covers purpose and both calling modes. But with no output schema and no annotations, it leaves the return shape (what a peg "status" actually reports) undefined, which is the main thing an agent cannot infer elsewhere.

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

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

Schema coverage is 100% and the enum is documented in the schema, so the baseline is 3. The description adds real value beyond the schema by explaining that omitting the optional symbol returns all tracked stablecoins — behavior the schema alone (which only marks it non-required) does not convey.

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 gives a concrete verb+resource ("Check stablecoin peg status") and explains the two calling modes. It does not differentiate itself from close siblings like get_stablecoin_list or get_wrapped_asset_peg, so an agent must infer the boundary on its own.

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 clearly states the conditional use of the single parameter (provide a symbol vs. omit for all), which is genuine usage guidance. However, it never says when to prefer this tool over get_stablecoin_list or get_wrapped_asset_peg, so alternative selection is left 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?

No annotations, so the description carries the full burden. 'List' implies read-only and the optional filter is noted, but for a list tool with no output schema the description says nothing about result size, truncation/pagination, or whether the full universe is returned. Adequate but with a real gap.

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, zero waste, with the core purpose front-loaded ahead of the filter detail and the usage cue. Every sentence 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 simple single-optional-parameter lookup tool, the definition is largely sufficient: purpose, filter, and when to reach for it are all present. The only omission is any indication of result scope/volume, which is minor for a list 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?

There is a single parameter with 100% schema description coverage ('Optional search query to filter symbols'), and the description mirrors that wording without adding syntax, matching behavior, or format detail. Baseline 3 applies when the schema already fully documents the parameter.

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

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

States a specific verb and resource: 'List supported asset symbols.' The resource (symbols) is distinct from sibling getters like get_feeds and get_protocols, so an agent can differentiate it. It stops short of explicitly naming a sibling alternative, 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?

Gives an explicit trigger condition: 'Use this when you are unsure whether a symbol is supported.' That is a clear when-to-use statement. It does not name what to use instead once symbol support is confirmed, so no exclusions/alternatives are covered.

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?

No annotations and no output schema, so the description carries the full behavioral burden, yet it only says 'check peg status.' It does not disclose what a peg status comprises (deviation threshold, healthy/degraded flag), data freshness/staleness, or data source, all of which materially affect interpretation for a peg-monitoring tool.

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

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

Two sentences, no filler, with the core purpose front-loaded and the parameter behavior trailing. Every clause earns its place.

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

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

For a simple one-parameter lookup this is close to adequate, and the omit-for-all behavior is covered. But with no output schema, the description should characterize what 'peg status' returns (thresholds, units, staleness), which it leaves undefined.

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

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

Schema coverage is 100% and the enum already lists all seven supported symbols with documentation. The description adds only the optionality behavior (omit to fetch all), not new syntax or semantics, so the baseline 3 for a fully documented parameter is appropriate.

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 ('Check wrapped asset peg status') and grounds it with concrete examples (WBTC, wstETH). The wrapped-asset scope cleanly distinguishes it from the sibling get_stablecoin_peg without needing to name it 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 description explains the invocation choice for its own parameter ('provide a symbol... or omit it to get all tracked wrapped assets'), which is useful. However, it gives no guidance on when to prefer this over sibling tools like get_stablecoin_peg or compare_oracle_deviation, so tool-selection guidance is only implied.

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

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

With no annotations, the description carries the full burden and does well: it discloses the simulation step, the rejection policy for preliminary-tx bundles, and that it returns short-lived evidence without signing. It omits auth/permission prerequisites and rate-limit or failure behavior, keeping it below a 5.

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

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

The core intent is front-loaded in the first clause, but the sentence is a dense run-on stacking jargon ('Insight evidence for PriorSeal', 'oracle evidence') without unpacking it. Mostly earns its place, but could be split and de-jargoned.

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 8-required-param mutation-builder with no output schema, the behavioral narrative is thorough, but the complete absence of parameter guidance leaves a significant gap in what an agent needs to call it correctly.

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

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

All 8 parameters are required with 0% schema description coverage, yet the description explains none of them. Terms like 'live vault and principal mint' loosely map to vault/assetMint, but loanSymbol, collateralSymbol, collateralValueUsd, minLpAmount, and principalAmount are never clarified, leaving most 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?

The description names a specific verb and resource ('Build a single Solana mainnet Loopscale lending-vault deposit') and enumerates the pipeline steps (verify vault/mint, resolve lookup tables, simulate, check oracle, return evidence). This clearly separates it from siblings like solana_lending_guard or pre_trade_safety_check, which check rather than build a transaction.

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 clear boundaries: 'It does not sign, authorize, or broadcast' and 'Deposit bundles requiring preliminary transactions are rejected.' That is strong when-not guidance, but it never names an alternative tool to use for signing/broadcasting or for the rejected multi-step 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?

No annotations exist, so the description carries the full burden and it does substantial work: it declares read-only, discloses the three-way verdict (ALLOW/CAUTION/BLOCK), states what is evaluated separately (collateral vs loan oracle integrity), and explicitly disclaims signing, broadcasting, or authorizing. Remaining gaps (stale-oracle handling, rate limits, failure behavior) keep it at 4.

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 dense sentences with the read-only scope front-loaded and no filler. The middle sentence is long but every clause adds a distinct capability; the final sentence delivers the critical safety disclaimer.

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 annotations, the description does explain the return verdict values and the non-signing contract, which is the most important missing piece. However, for a 7-parameter gate with zero parameter documentation, it leaves an agent guessing at how to populate the USD value fields and when the optional marketId is required.

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 7 parameters, so the description must compensate and largely does not. It only obliquely hints at protocolId (Aave V3 / Morpho Blue) and marketId ('an exact Morpho Blue market') and mentions caller-declared LTV, but never explains collateralSymbol, loanSymbol, collateralValueUsd/debtValueUsd, or the supply/borrow action semantics.

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 read-only pre-signing gate for Monad lending against Aave V3 or an exact Morpho Blue market, with named checks (oracle integrity, LTV vs live params) and a verdict output. An agent can distinguish this from the sibling monad_lending_guard_exact_call and the generic pre_trade_safety_check 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 description makes the usage context clear ('pre-signing gate', 'direct Aave V3 or an exact Morpho Blue market') and adds a binding instruction: bind a successful decision to an exact user-authorized transaction separately. It never names an alternative tool or an explicit when-not-to-use case, so it stops short of a 5.

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

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

With no annotations, the description carries the burden and does meaningful work: it discloses the verification checks performed (target, selector, token/market binding, sender, nonce, zero value), that the decision is short-lived EIP-712 and only issued when Insight signing is configured, and that it never authorizes, signs, or broadcasts. It omits what happens on a failed verification (error vs negative decision) and any rate/latency characteristics.

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 dense sentences with the purpose front-loaded, the verification behavior next, and the safety hand-off last. No filler, though jargon ('Insight risk evidence', 'PriorSeal', 'ALLOW') is used without definition, which costs a bit of immediate comprehensibility.

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

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

For a complex two-object nested schema with no annotations and no output schema, the description covers the essentials an agent needs: what it verifies, that it produces a short-lived signing decision rather than a transaction, and what must happen afterward. Gaps remain around the shape of the returned EIP-712 decision and failure modes.

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 supply meaning, and it does map the transaction fields implicitly (target=to, selector=data, sender=from, nonce, value must be zero) plus token/market binding from the guard object. However, it says nothing about collateralValueUsd/debtValueUsd, the optional marketId, the protocolId enum values, or the fixed chainId 143, leaving several leaf fields undocumented 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?

The description gives a specific verb and artifact ('Create portable Insight risk evidence') and narrows scope to one exact unsigned direct Aave V3 Monad or Morpho Blue Monad supply/borrow call, which implicitly separates it from the broader monad_lending_guard and the base/other-chain variants. It never names those siblings explicitly, so the differentiation relies on the reader inferring 'exact' vs non-exact.

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 carves out a clear usage envelope: a single, exact, unsigned, direct call on two named protocols, which excludes batched/router calls by implication. It also states the downstream step ('bind an ALLOW through PriorSeal or another user-authorization system'), but gives no explicit when-to-use-this-vs-monad_lending_guard 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?

With no annotations, the description carries the full burden and does well: it declares read-only semantics, enumerates the three possible verdicts, states the evidence basis (live protocol state plus independent oracle evidence), and gives per-protocol acceptance constraints such as Euler's four-step EVC batch and Fluid's collateral-only supply. It leaves out failure behavior for unsupported chain/protocol combinations and any rate-limit or auth expectations.

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

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

Three sentences, front-loaded with the core purpose and verdict contract, then protocol-specific exceptions. The protocol roster sentence is dense but each clause carries constraints an agent needs; nothing is redundant 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?

Behavior and output contract are covered well, and the lack of an output schema is offset by the ALLOW/CAUTION/BLOCK statement. However, for a 13-parameter, 7-required tool with zero schema descriptions and no annotations, the absence of any per-parameter guidance (especially the protocol-dependent identifier fields) leaves a meaningful 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% across 13 parameters, so the description must compensate — and it barely does. 'Caller-declared post-action values' hints that collateralValueUsd/debtValueUsd are projected post-action figures, but marketId, loanMarketId, collateralMarketId, accountNumber, marketAddress, and collateralVaultAddress are 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+resource: a read-only pre-signing gate that checks caller-declared post-action values against live protocol state and returns ALLOW/CAUTION/BLOCK, scoped to named chains and protocols. The chain/protocol enumeration implicitly separates it from base_lending_guard, monad_lending_guard, solana_lending_guard and the _exact_call sibling, but 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?

The 'pre-signing gate' framing and 'never signs, broadcasts, or authorizes' clause make the use context clear, and the Euler/Dolomite/Fluid eligibility rules tell the caller which input shapes are accepted. It stops short of naming alternatives (e.g. when to prefer the base-only or exact-call guards), so it falls short of a 5.

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

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

With no annotations, the description carries the full behavioral burden and does well by explicitly ruling out authorization, signing, relaying, and broadcasting. It also discloses that a short-lived Insight signature is bound when configured, though it does not describe whether evidence is persisted, returned, or otherwise exposed.

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 short, front-loaded with the core action, and wastes little space. The second sentence adds important safety boundaries, though the term 'Insight evidence' remains jargon that slightly reduces immediate clarity.

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

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

For a complex nested-schema tool with no annotations and no output schema, the description covers purpose and non-execution behavior but leaves major gaps around the required guard fields and what the created evidence consists of. An agent would still need substantial inference or trial-and-error to populate the input 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 the input schema has two nested objects with many required fields. The description maps some key transaction fields (target, calldata, sender, nonce, value) and mentions 'protocol market', but it does not explain the guard fields such as action, collateralSymbol, loanSymbol, collateralValueUsd, or debtValueUsd, leaving much of the required schema 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?

The description states a specific verb+resource: create portable Insight evidence for one exact unsigned direct reviewed EVM lending call, and names the supported chains. It distinguishes itself from a generic guard through 'exact unsigned direct reviewed' but does not explicitly name or contrast with the sibling multichain_evm_lending_guard or chain-specific exact_call tools.

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

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

It clarifies this is for an exact unsigned lending call and explicitly says it never authorizes, signs, relays, or broadcasts, directing authorization to PriorSeal. However, it does not explain when to choose this tool over the sibling multichain_evm_lending_guard or base_lending_guard_exact_call, nor does it state required preconditions beyond the call being exact and reviewed.

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?

With no annotations, the description carries the burden and does well: it enumerates the inputs to the verdict (consensus deviation, agreement, quorum, outliers, staleness) and the output shape (verdict plus proceed/proceed_with_caution/halt recommendation), which is effectively the missing output schema. It does not disclose auth needs, rate limits, caching, or how quickly the signal refreshes.

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

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

Three tight sentences, front-loaded with the capability and its condensed output, followed by usage gating and the sibling pairing. No filler or restatement of the tool name.

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 signal tool with no output schema, the description covers purpose, output composition, usage context and the sibling relationship, which is close to complete. It leaves minor gaps around how the optional chain filter changes results and whether the signal is cached or computed per 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?

Schema description coverage is 100%, so the schema already documents both parameters, and the description adds no syntax or semantics for 'symbol' or the optional 'chain' filter. Baseline 3 applies when the schema does the heavy lifting.

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 capability: a cross-oracle risk signal for an asset that condenses deviation, agreement, quorum, outliers and staleness into a NORMAL/CAUTION/DANGER verdict. It is clearly distinguishable from siblings like compare_oracle_deviation (single comparison) and pre_trade_safety_check (one-off decision moment).

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 explicitly when to use it ('gate long-running strategies (yield, keeper, portfolio)') and when not to lean on it alone ('not just one-off trades'), then routes the agent to the complementary tool: 'Pair it with pre_trade_safety_check for the decision moment.'

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?

With no annotations, the description carries the full behavioral burden and does disclose important traits: history is guaranteed only for the committed universe (ETH/BTC/USDC/USDT x ethereum/arbitrum/base), and unsupported pairs silently degrade to a live point signal with no curve. It does not mention auth requirements, rate limits, or error behavior, which leaves some gaps for a read tool with no annotation support.

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

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

Two sentences, front-loaded with the returned metrics before the usage framing and coverage caveat. Dense and mostly waste-free, though the metric list and the coverage/fallback clause are both packed into long clauses that could be trimmed slightly.

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 correctly enumerates what comes back (verdict stability, degraded-time ratio, worst deviation, mean credibility, recent series), which is the right substitute. Combined with the coverage limitation and the oracle_watch fallback, an agent has enough to call it correctly, though error/empty-history behavior is 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 description coverage is 100%, so the baseline is 3: days, chain, symbol and interval (including the 8-30d hourly and >30d daily rollup rules) are all documented in the schema. The description only restates the window as "last N days" and "recent series," adding no syntax or format detail beyond what the schema already carries.

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 (retrospective trend) and resource (Oracle Watch for an asset) and enumerates the exact outputs: verdict stability, degraded-time ratio, worst deviation, mean credibility, plus the recent series. It explicitly distinguishes itself from the live sibling (oracle_watch) by framing itself as historical judgment rather than an instantaneous health check.

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?

"Use it to judge whether a feed has been dependable, not just whether it is healthy this instant" states the when-to-use case and implicitly routes instantaneous checks to oracle_watch. It also gives an explicit coverage boundary and the fallback behavior (other pairs return a live point signal from oracle_watch but no curve), so the agent knows when this tool will not give what it expects.

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?

With no annotations provided, the description carries full burden and succeeds: it discloses that the tool obtains a pinned quote, re-verifies contract identities (Factory, QuoterV2, Pool, Router), returns only unsigned approval and swap calldata, and never receives a key, signs, relays, or broadcasts. This gives the agent a complete safety and side-effect 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?

Four sentences, front-loaded with purpose, then inputs and internal checks, then return values and safety guarantees. Every sentence adds distinct value with no repetition or padding.

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

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

The description covers what the tool does, what it returns, and what it never does—sufficient for a preparation tool with no output schema. It could be slightly more explicit about the structure of the returned calldata or failure modes (e.g., what happens if the pool is not allowlisted), but the core behavioral contract is clear.

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 each parameter is already documented in the input schema. The description summarizes the parameters (reviewed profile id, exact input amount, recipient, short deadline, slippage bound) and adds minor linking context, but no new semantics beyond what the schema provides. Baseline 3 is appropriate.

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 ('Prepare') and resource ('user-signable exact-input swap against one allowlisted Base Aerodrome Slipstream pool'), clearly distinguishing it from siblings like get_aerodrome_slipstream_market or prepare_hyperliquid_perp_order. An agent can immediately tell this is a swap-preparation tool, not a market data or execution 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 gives clear context: it prepares an unsigned swap for a reviewed profile id, with short deadline and slippage bound. It doesn't explicitly name alternatives or say when not to use it, but the scoping to 'one allowlisted pool' and the return of 'unsigned calldata only' implicitly routes the agent away from tools that broadcast or query markets.

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?

With no annotations, the description carries the full burden and does well: it enumerates the gates (live asset metadata, lot/tick rules, notional cap, mark-oracle divergence, L2 fill/impact), states the output only materializes when all gates pass, and explicitly disclaims key handling, signing and submission. It doesn't say what the agent receives on gate failure or whether validation is performed against cached or live state at call time.

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?

Four dense sentences, front-loaded with what is produced, then the validation gates, then the safety disclaimer. Every clause carries information, though the middle sentence is a long list that an agent may need to parse twice.

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 no annotations, so the description must cover both behavior and contract; it does the behavioral side well but leaves the parameters and the failure/error shape undocumented for a 12-param mutation-adjacent tool. Adequate to know when to call it, incomplete for calling it correctly without reading the schema carefully.

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 12 params, so the description should carry more. It maps conceptually to maxNotionalUsd ('caller notional cap'), maxMarkOracleDeviationBps ('mark-oracle divergence'), maxPriceImpactBps and requireFullFill ('displayed-L2 fill/impact bounds'), and 'short-expiry' hints at expiresAfterSeconds. But builderFee, clientOrderId, reduceOnly and the interplay of the cap thresholds are never explained beyond their regex/range constraints in the schema.

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

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

States a specific verb (prepare), a specific resource (Hyperliquid perpetual IOC order) and narrows scope to BTC/ETH/HYPE for local signing. The phrase 'unsigned, short-expiry exchange envelope' separates it from the sibling verify_hyperliquid_perp_execution, which checks rather than builds an order.

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's clear this is a pre-signing step whose output goes to a LOCAL wallet, and the negative scope ('Insight never creates a nonce, receives a key, signs, or submits') tells the agent not to expect submission from this tool. It never names verify_hyperliquid_perp_execution or pre_trade_safety_check as the follow-on/alternative, so routing between siblings is left 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?

With no annotations, the description carries the full behavioral burden and does so: it discloses that a pinned quote is obtained, that Factory/QuoterV2/Pool/Router runtime identities are re-verified, that the return is unsigned approval plus swap calldata, and explicitly that it never receives a key, signs, relays, or broadcasts. This is a complete safety and output 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?

Two sentences, zero filler, and the operative purpose is front-loaded before the behavioral and safety disclosures. Each sentence contributes distinct 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 5-parameter tool with full schema coverage and no output schema, the description covers purpose, verification behavior, return shape (unsigned approval and swap calldata), and non-custodial guarantees. It omits failure modes such as quote unavailability or allowlist rejection, which an agent preparing a transaction would benefit from knowing.

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 amountIn, recipient, maxSlippageBps, deadlineUnixSeconds, and profileId. The description adds only directional context (exact-input, USDC in / USDT out, single allowlisted pool) and no per-parameter semantics beyond what the schema provides. Baseline 3 applies.

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

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

The first clause states a specific verb, resource, and scope: prepare a user-signable exact-input swap against one allowlisted Base PancakeSwap V3 pool. That is enough to distinguish it from sibling preparation tools such as prepare_aerodrome_slipstream_swap (different venue) and from read-only market tools like get_pancakeswap_v3_market.

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 establishes clear context for use: exact-input direction, single allowlisted Base PancakeSwap V3 pool, unsigned output for a user to sign. It does not, however, name a sibling alternative or state when NOT to use it (e.g., use get_pancakeswap_v3_market for quotes-only, or the Aerodrome variant for a different venue).

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?

With no annotations, the description carries the full burden and does a lot: it discloses the four-level verdict taxonomy, the fail-closed rule for DANGER/BLOCK, that the optional decisionInput assessment never changes the verdict, that a signature is independently verifiable via EIP-712, and that PASS is not authorization or a price guarantee. It omits operational traits — auth/API-key requirements, latency, rate limits, caching of oracle data. The explicit 'never changes the verdict' clause is a genuinely useful behavioral detail an agent couldn't infer.

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 when-to-call instruction and the MUST-NOT rule are front-loaded, followed by scope and caveats. It is dense but each sentence does work — aggregation scope, decisionInput semantics, verdict enums, and disclaimer. Slight cost from the jargon-heavy opening ('decision-input integrity checkpoint') and the caveat stacking at the end.

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 no annotations and no output schema, the description does explain the verdict domain and mentions a recommended max position size, which covers the most decision-relevant return values. However, the return shape beyond the verdict is unclear (deviation figures? per-provider breakdowns?) and the phantom decisionInput parameter conflicts with a closed schema, leaving an agent with an inaccurate mental model of the 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?

Schema coverage is 80% (asset, chainId, tradeAmountUsd, targetProviders all documented), so the baseline is 3 and the description adds little per-parameter guidance — no explanation of how tradeAmountUsd interacts with the 'recommended maximum position size' output. Worse, it describes an 'optional decisionInput object' that does not exist in the schema, which has additionalProperties: false; this can send an agent looking for a parameter it cannot supply.

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 capability — a pre-execution integrity checkpoint that aggregates cross-oracle consensus price, per-provider deviation, freshness, stablecoin peg, and reputation into a single PASS/CAUTION/DANGER/BLOCK verdict. It implicitly distinguishes itself from the granular siblings (get_oracle_health, compare_oracle_deviation, get_feed_freshness) by framing itself as the aggregated decision gate. It stops short of naming a specific sibling as the alternative, but the 'one verdict vs many data points' framing is clear.

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 explicit and actionable: 'Call this BEFORE executing any on-chain swap/borrow/lend/liquidation/repay,' and it states a hard rule — agents MUST NOT execute when the verdict is DANGER or BLOCK. That maps cleanly onto the action enum. It does not state when NOT to use it or how it relates to adjacent preflight tools like execution_preflight or check_position_safety, leaving sibling selection partly 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. The words 'recommend' and 'decide' imply an advisory, non-mutating output, which is useful, but there is no statement about permissions, determinism, cost, or side effects for an agent that must reason about safety.

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