insight-oracle

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: it discloses the refusal condition (DANGER/BLOCK), that it does not execute the trade (you use your own wallet), that the result is a handle/certification rather than principal authorization, and that maxSlippageBps is pre-committed. It omits auth/pricing/rate-limit or latency context, so it falls short of 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?

Front-loaded with purpose, then sequencing, then refusal semantics, then a scoping disclaimer; every sentence carries information. It is dense and slightly long, with a few parenthetical return-field enumerations that could be trimmed, but nothing is 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 9-parameter mutation-adjacent tool with no output schema, the description compensates by enumerating what the handle returns (preTradeUid, requestHash, CAIP-19 ids, certified price, maxSlippageBps, participant counts, signing time) and by specifying the refusal path and next tool. Missing only auth/prerequisite context, which keeps 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 89% so the schema already documents most parameters (asset, destinationAsset, chainId, action enum, tradeAmountUsd). The description adds value beyond the schema by framing maxSlippageBps as a pre-committed tolerance and by explaining that the returned handle contains requestHash and certified price, tying parameters to the certification concept.

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: obtain oracle assessment evidence (an execution certification handle) for a swap/DeFi intent before trading. It distinguishes itself from siblings by naming execution_receipt as the downstream step and by positioning itself as evidence rather than authorization, so an agent can separate it from pre_trade_safety_check and verify_execution_pair.

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?

Explicit when-to-use (before executing a trade), explicit sequencing (call this first, execute with your own wallet, then call execution_receipt with the handle plus txHash), and explicit failure handling (refuses on DANGER/BLOCK, do not trade). This is a full lifecycle instruction rather than a vague hint.

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?

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?

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?

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?

No annotations provided, so the description carries the full burden. It discloses the aggregation behavior (cross-provider consensus) and the manipulation-resistance trait, but omits operational details like what happens if a provider is missing, staleness handling, or possible errors.

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 action, 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 read-only aggregation tool with full schema coverage but no output schema, the description is adequate but leaves gaps: it doesn't explain the response shape (single price vs per-provider breakdown) or how missing providers affect the aggregate. A 3 fits an adequate-but-shallow definition.

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 enum values are documented in the schema. The description adds no parameter-level meaning beyond what the schema provides (symbol, chain filter, method). 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?

Specific verb (Get) + resource (aggregated consensus price) + scope (across multiple oracle providers). Distinguishable from siblings like get_oracle_price (single source) and compare_oracle_deviation.

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?

Says 'Useful when you need a robust, manipulation-resistant reference price,' which implies usage context but gives no explicit when-to-use/when-not or alternatives. No mention of when to use get_oracle_price vs this tool.

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 supplied, so the description carries the full disclosure burden, and it delivers very little: it never states that this is a read-only operation, whether results are cached, whether there are rate limits, or what happens when the optional baseChain is omitted. 'Get' weakly implies a safe read, but nothing confirms it.

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 operation front-loaded before the use case. The second sentence is slightly generic but still earns its place by signaling intent.

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 is the only guidance available, yet it omits the most consequential behavioral question: how the optional baseChain alters the returned pairwise set (all-pairs versus anchored pairs). For a 3-parameter analytical tool this is a meaningful gap, though the core purpose is adequately conveyed.

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 already defines symbol, provider, and the baseChain enum, making 3 the correct baseline. The description restates the required provider/symbol pair but adds no meaning for baseChain, which materially changes the computation ('Base chain for spread calculation').

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 ('Get pairwise price spreads across chains') scoped to a provider and symbol, which is concrete and unambiguous. It does not, however, explicitly distinguish itself from potentially adjacent siblings such as compare_oracle_deviation or get_correlation, 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?

'Useful for cross-chain arbitrage and risk tracking' hints at the intended context but gives no explicit when-to-use or when-not-to-use rule, and never names an alternative tool. Usage is implied rather than prescribed.

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 behavioral burden. It conveys that results are a point-in-time snapshot ('current') across many feeds, which is useful context beyond the schema, but it says nothing about auth/permissions, pagination, or whether stale feeds are flagged versus filtered out. Adequate but with real gaps for a no-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?

Three tight sentences, front-loaded with purpose and scope, then usage, then the sibling disambiguation. Every sentence carries information; nothing is redundant 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 read-only filtered list tool with no output schema, the description covers purpose, scope, filters, and routing. The only omission is any hint at what the response contains (freshness values, staleness thresholds, counts), which an agent might want but can discover on 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% and all three filters (symbol, category, provider) are documented with enum values in the schema itself. The description only restates the filterable dimensions without adding format or combination semantics, so it earns the baseline rather than more.

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 (scan) and resource (current freshness/staleness) with explicit scope: 'across many active feeds'. It also distinguishes itself from siblings by naming get_feed_health (single feed) and get_oracle_health (dated ecosystem report), so an agent can route 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 an explicit when-to-use ('to find feeds needing attention right now') plus two named alternatives with the conditions that select them. The decision boundary between this tool and the two get_* health tools is fully 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 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 non-mutating read, but it says nothing about pagination semantics (limit/offset with a 500 cap), the default page size, or whether a total count is returned — real gaps for a paginated list tool. It does add the useful fact that results come from a registry and include metadata.

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

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

Two tight sentences with the action and filters front-loaded; no filler. Slightly less than full marks only because the filter list partly duplicates 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?

With no output schema and no annotations, the description should cover return shape and pagination behavior. It covers purpose and filters adequately but leaves an agent guessing about result size, ordering, and how to page through a large registry.

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 seven parameters are already documented in the schema (including enums for provider and category). The description adds little beyond echoing five of them and omits limit/offset entirely, 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?

States a specific verb+resource ('List oracle feeds from the registry') and enumerates the filter dimensions, which matches the schema. It is distinguishable from read-heavy siblings like get_feed_health or get_oracle_price, though it never explicitly names a sibling to route against.

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 gives implied usage ('discovering available feeds and their metadata'), which is enough to pick the tool for discovery, but there are no when-not conditions and no named alternatives such as get_symbols or get_coverage for overlapping lookups.

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 behavioral burden. It does usefully disclose the computed output metrics, which is meaningful beyond the schema, but says nothing about permissions, rate limits, default date-range behavior when from/to are omitted, or pagination.

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 earning their place: the first defines the operation and output, the second routes the agent to the correct sibling. Front-loaded with the core purpose and zero 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?

With no output schema, the description usefully summarizes what the analysis returns (success rate, hours with data, coverage %, avg snapshots/day). It is close to complete, though it omits behavior when the zero required params (from/to) are not supplied.

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 four parameters are already documented in the schema, so the baseline is 3. The description adds only the 'per provider+symbol' grouping hint, not format or default semantics for the optional filters.

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 ('Analyze feed data-delivery reliability over a date range') and enumerates the exact metrics produced (success rate, hours with data, coverage %, avg snapshots per day). It explicitly differentiates itself from the two nearest siblings, get_feed_health and get_latency.

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 case ('assess how completely a feed delivered data over time') and names alternatives with the distinguishing condition for each — get_feed_health = point-in-time status, get_latency = speed. An agent can select this tool without opening any sibling schema.

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 lookup, which is the key safety signal, but it says nothing about authentication, rate limits, or how pagination behaves despite limit/offset parameters being present.

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 with the resource stated first and filters second; nothing is wasted, though it is telegraphic rather than richly informative.

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 6-parameter query tool with no annotations and no output schema, the definition covers purpose and filters but omits pagination behavior (limit/offset semantics, defaults) and result shape, leaving some gaps an agent must infer.

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 are documented in the schema with formats and enums. The description restates the date-range, provider, and severity filters but adds no syntax or semantics beyond the schema, which is the expected baseline.

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

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

Names a specific verb and resource ('Get oracle incidents and deviation events') plus the scoping dimension (date range). It distinguishes itself reasonably from price/health siblings, though it doesn't explicitly contrast with near neighbors like get_anomalies or compare_oracle_deviation.

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

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

The description implies when it's useful ('within a date range, filter by provider and minimum severity'), which is adequate usage context, but there is no explicit when-not or alternative-routing guidance among the many sibling 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 discloses useful context such as the 15-minute interval and the computed latency statistics, and analysis implies a read-only operation. However, it does not describe output shape, pagination, default date-range behavior, or any access requirements.

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

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

The description is a single, front-loaded sentence with no wasted words. It puts the core resource and scope first, followed by optional filters.

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 analysis tool with four optional parameters and no output schema, the description covers the main statistics and filters but omits expected output structure and what happens when no date range or filters are supplied. It is adequate but leaves meaningful 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 parameter meanings are already fully documented in the input schema. The description only restates the date-range and provider/symbol filtering at a high level and adds no syntax or default-value 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?

The description gives a specific verb (Analyze), a clearly scoped resource (15-minute oracle collector latency statistics), and lists the exact statistics returned (min, mean, p50, p90, p95, p99). This distinguishes it from generic sibling tools like get_oracle_health or get_metrics.

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 the scope (date range) and optional filters (provider, symbol), giving implied usage context. It does not explicitly say when to use this tool instead of related health or metrics tools, nor does it state prerequisites or defaults.

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 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 provided, so the description carries the full behavioral burden. It states nothing about caching versus upstream freshness (despite get_price_history, get_feed_freshness, and a forceRefresh parameter in the schema implying cache behavior), staleness guarantees, failure modes when a provider lacks the asset, 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?

A single front-loaded sentence with zero waste. It is efficient, though arguably too terse for a tool with four parameters and no annotations.

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

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

With four parameters, no annotations, and no output schema, the description should carry more weight. It omits how chain interacts with provider (e.g., must the chain match the provider), how symbol formats like 'BTC/USD' versus 'BTC' resolve, and caching behavior that forceRefresh controls.

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 enum values and per-parameter descriptions (chain, symbol, provider, forceRefresh) are already fully documented. The description adds no meaning beyond the schema, so the baseline 3 applies.

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

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

The description gives a specific verb (fetch), resource (latest price), and scope (a specific oracle provider for a given asset), which implicitly separates it from get_consensus_price and get_oracle_prices_batch. It stops short of naming those siblings explicitly, so the agent must infer the boundary rather than being told it.

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

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

Choosing 'a specific oracle provider' hints that this is the single-provider query rather than an aggregate, but there is no explicit when-to-use, when-not, or named alternative. Usage is only implied by the phrase 'specific oracle 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 behavioral burden and largely fails it. It does not state cache/staleness behavior (despite a forceRefresh parameter existing), whether a failed sub-query aborts the whole batch, or whether any auth or rate limits apply.

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 action, and no padding. The second sentence largely duplicates the schema's maxItems constraint, which is mild redundancy rather than bloat.

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 batch/mutation-adjacent tool with no output schema and no annotations, the description omits critical context: response shape for N queries, partial-failure semantics, and what forceRefresh costs. It is not complete enough for an agent to call this confidently in a risk-sensitive pricing context.

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 the nested provider/symbol/chain fields and forceRefresh are documented in the schema itself. The description only restates the maxItems limit, adding no syntax, format, or semantics beyond structured data, which fits the baseline 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?

States a specific verb and resource ("Fetch prices") plus a clear scope modifier ("multiple assets/providers in a single request"). It does not, however, distinguish itself from close siblings like get_oracle_price or get_consensus_price, so an agent must infer from the name alone that this is the batch variant.

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

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

No when-to-use guidance is given. There is no mention of when to prefer this over the single-asset get_oracle_price, when to use get_consensus_price instead, or what happens on partial failures. The agent is left to guess at routing.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about caching behavior (even though forceRefresh exists), rate limits, or the range/shape of returned data. It only restates the data category.

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 essential scope (provider + period) comes early. It is appropriately sized, though it omits detail that would have earned a 5.

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 getter with no annotations and no output schema, the description covers the core purpose and required inputs are well documented in the schema. However, the caching default, output format, and period cap are left for the agent to discover.

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 provider, symbol, period, chain, and forceRefresh. The description's 'over a period (in hours)' merely echoes the schema's 'Historical period in hours' without adding syntax or constraints (e.g., the 8760 cap).

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 (historical price data) with scope qualifiers: a specific oracle provider, an asset, and a period. It is clear enough to distinguish from get_oracle_price or get_consensus_price, but it never names siblings to sharpen 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?

No when-to-use or when-not-to-use guidance is given. With siblings like get_oracle_price, get_consensus_price, and oracle_watch_history, the agent has to infer that this is the historical/time-series variant rather than being told.

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 supplied, so the description carries the full behavioral burden. It implies a read operation but never states read-only safety, whether results are cached or live, rate limits, or what happens if an unknown provider is requested. For a metrics tool with zero annotation coverage, this is 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?

A single front-loaded sentence with the action and resource first and the optional modifier last. No waste, though the 'optionally with historical trend' clause is somewhat redundant with the schema's trend flag.

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

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

With no output schema, the description should describe what 'reputation metrics' actually contains and how the trend is returned. It specifies neither the metric contents nor the relationship between days and trend, leaving the agent unable to anticipate the response for a multi-parameter analytics 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%, so provider, trend, and days are all documented in the schema. The description reinforces provider scoping and the optional trend, but adds no meaning beyond the schema (e.g., no default trend duration or interaction between days and trend). 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), resource (reputation metrics), and scope (a specific oracle provider), with the optional trend qualifier. It is reasonably distinguishable from get_reputation_rankings, though it never explicitly contrasts 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?

There is no explicit guidance on when to use this versus alternatives like get_reputation_rankings or get_oracle_health. The phrase 'optionally with historical trend' hints at when to enable trend, but no prerequisites, exclusions, or sibling routing 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?

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 behavioral burden. It lists the risk components included but does not disclose whether the operation is read-only, what permissions are needed, data sources, caching, rate limits, or the shape of the response, leaving notable gaps for a composite 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 tightly written sentences with zero filler. The core purpose is front-loaded, and the second sentence efficiently lists the included risk dimensions.

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

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

The description covers the tool's purpose and the dimensions returned, which is useful given there is no output schema. However, it omits usage context relative to the many sibling tools and provides no behavioral details, so it is only minimally complete for a composite risk-analysis operation.

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, providers, and period, including defaults and minimum provider counts. The description adds no syntax, format, or selection guidance for these parameters beyond restating that the summary is for an asset across selected oracle providers.

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 (composite risk summary) for an asset across selected oracle providers, and enumerates the included risk dimensions. It is clear what the tool computes, but it does not explicitly differentiate itself from sibling risk or health tools such as get_oracle_health or get_protocol_oracle_exposure.

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 says what the tool returns but provides no guidance on when to use it instead of alternatives like get_oracle_health, assess_rwa_evidence, or get_correlation. There are no stated conditions, exclusions, or prerequisites to help an agent select this tool.

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?

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?

No annotations are provided, so the description carries the full burden, and it does disclose meaningful behavior: the signal is continuous rather than a point-in-time read, it aggregates five named components, and it maps to a three-level verdict plus a three-value action recommendation — effectively the return semantics in prose. It does not state refresh cadence, cost/latency, or failure modes for a 'ongoing' signal, so it falls short of full disclosure for a 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?

Three sentences, zero filler: the purpose and verdict semantics come first, the gating guidance second, and the sibling pairing last. Each 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, the description must convey return shape, and it largely does via the verdict levels and named components. The gap is operational: the optional chain parameter's default/aggregation behavior and the signal's refresh cadence are undefined, which matters for an ongoing watch signal.

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 documented as an asset symbol, chain as an optional blockchain filter), so the schema already does the heavy lifting and the baseline is 3. The description adds no syntax, format, or defaults — notably it never explains what omitting chain means (cross-chain aggregation vs. default chain).

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 and scope: an ongoing cross-oracle risk signal for an asset, condensed into a NORMAL/CAUTION/DANGER verdict with a proceed/halt recommendation. It names its measurable inputs (consensus deviation, agreement, quorum, outliers, staleness), which cleanly separates it from one-shot siblings like get_oracle_health or compare_oracle_deviation.

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 (gate long-running strategies: yield, keeper, portfolio) and draws a boundary against a nearby use case ('not just one-off trades'). It also names the complementary tool and the moment to pair it, 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 burden and does well: it discloses the committed-universe coverage guarantee (ETH/BTC/USDC/USDT x ethereum/arbitrum/base) and the degraded fallback behavior for other pairs. It omits operational traits such as auth requirements, rate limits, or whether the window is capped by data retention.

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?

Front-loaded with the core purpose and metric list, then the usage rule, then the coverage caveat. Every sentence earns its place; the metric enumeration is a little dense but functional.

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 describe returns, and it does so concretely (verdict stability, degraded-time ratio, worst deviation, mean credibility, series). The fallback return is also covered. Minor gap: the length/granularity of the 'recent series' and any retention cap are 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 schema already documents days, chain, and interval (including the roll-up rules), giving a baseline of 3. The description only gestures at 'the last N days' and adds no meaning 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?

Names a specific verb+resource (retrospective oracle watch trend for an asset) and enumerates the exact outputs: verdict stability, degraded-time ratio, worst deviation, mean credibility, recent series. It is clearly distinguishable from the sibling oracle_watch, which the description implicitly positions as the live/instant counterpart.

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 states the usage condition ('judge whether a feed has been dependable, not just whether it is healthy this instant'), which routes the agent away from instantaneous tools like get_feed_health/oracle_watch. It also gives an explicit when-not: non-committed pairs return only a live point signal with no curve.

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 verdict semantics, the mandatory blocking behavior, that a recommended max position size is returned, and an important caveat that PASS is not authorization or a guarantee. It omits operational traits like latency, auth requirements, or failure behavior.

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

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

Front-loaded with purpose and the critical pre-execution timing, then the verdict set, then the caveat. The disclaimer sentence is long but earns its place by limiting liability. Slightly dense, but 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?

With no output schema, the description does the work of explaining the return values (verdict plus recommended max position size), and the required/optional parameter split is covered by the schema. For a pre-trade safety gate this is nearly complete, though it could say more about what happens on error or timeout.

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%, so the schema already documents almost all parameters. The description adds only marginal meaning, restating the action types (swap/borrow/lend/liquidation/repay) that are already in the enum and hinting at trade size via the position-size recommendation, with no added syntax or format guidance.

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 ('pre-trade oracle safety checkpoint') and precisely describes what it produces: an aggregated PASS/CAUTION/DANGER/BLOCK verdict from consensus prices, deviation, freshness, peg status and reputation. This clearly distinguishes it from granular siblings like get_oracle_health or compare_oracle_deviation.

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 call it ('BEFORE executing any on-chain swap/borrow/lend/liquidation/repay') and the hard rule that agents MUST NOT trade on DANGER/BLOCK. It does not name a sibling alternative for narrower checks, but the aggregation scope implies when to use this versus the granular 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?

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.

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

Two tight sentences with the core purpose front-loaded and no redundant restatement of the name or title. It is efficiently sized for a one-parameter tool, though the second sentence could be sharper.

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 tool this is nearly adequate, but there is no output schema and the description never states what the recommendation actually returns (a ranked provider list? a config?). It only implies a set of providers to include, leaving the return shape 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?

The single parameter is fully documented in the schema (100% coverage, with an example such as BTC/ETH), so the schema does the heavy lifting. The description adds the notion that the recommendation is derived from active feeds but contributes no additional per-parameter syntax or constraint 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?

Names a specific verb (recommend) and resource (oracle provider setup for an asset) and adds the basis for the recommendation (active feeds), which distinguishes it from the read-only siblings like get_oracle_health or compare_oracle_deviation. It stops short of explicitly contrasting itself with any of the many neighboring oracle tools, so it is clear but not fully differentiated.

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 gives a concrete use context: deciding which providers to include in price feeds or risk analysis. That is a real when-to-use signal, but it offers no exclusions and never names an alternative tool or the conditions under which a different sibling should be preferred.

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 returned verdict vocabulary (CLOSED_FAITHFUL/DEVIATED/NOT_EXECUTED/UNDETERMINED, PRICE_-prefixed on v3, PAIR_INVALID) and the binding assertions checked. It omits operational traits such as signing/permission requirements or performance, so not 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?

Front-loaded with the core operation, then the return values, then the binding requirements and scope limits. The enumeration of status values is dense but purposeful; 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?

For a complex, no-output-schema tool the description handily explains the return shape and the binding assertions, plus the v3 destination-gate requirement. It is nearly complete, though the phantom destinationPreTradeAttestation parameter and lack of any auth/operational note leave small gaps.

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

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

Schema coverage is 100% and both parameters already have descriptions ('the pre-trade oracle-safety attestation the agent gated on', 'the Execution Receipt to check against'), so the baseline is 3. The description adds binding context but also references a destinationPreTradeAttestation parameter that is absent from the schema, which muddies rather than clarifies 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?

Names a specific verb and resource — verifying that a pre-trade attestation and an Execution Receipt describe the same trade and that the certify→execute→prove loop closed. It is clearly distinguishable from siblings like execution_receipt or pre_trade_safety_check, and the closing note ties it to agent_begin_trade and execution_receipt.

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 context (use after a trade to check attestation/receipt binding), a concrete prerequisite (on v3 receipts committing a destination gate, pass destinationPreTradeAttestation or the pair cannot close), and scope exclusions (does not establish principal authorization, price correctness, or economic safety). It stops short of naming alternative tools for those other concerns, so not a full 5.

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