Insight MCP

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses refuse-on-DANGER/BLOCK semantics, the all-or-nothing handle issuance condition, the fixed 50 bps cap, EIP-712 signed assessments, dual-RPC cross-checking, fail-closed unsupported pairs, and that it is evidence not principal authorization. Auth/rate-limit behavior is not addressed, keeping it below 5.

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

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

The purpose and failure conditions are front-loaded, but the middle degrades into a garbled fragment ('participant/source-group counts and the pre-trade signing time.') with no subject, and several clauses are dense and repetitive. Length is defensible for the tool's complexity, but the structure could be tightened.

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

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

For a 10-parameter, deeply nested, no-annotation, no-output-schema tool, the description covers the workflow, refusal/failure modes, signing model, and the follow-up call to execution_receipt. It is nearly complete; remaining gaps are auth/rate-limit behavior and explicit routing versus the similarly named pre_trade_safety_check sibling.

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

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

Schema coverage is already 90%, so baseline 3, but the description adds real meaning: the decisionInput gate is described as a required operation-input check for both legs plus an exact-notional Uniswap V3 quote cross-checked by two RPCs, and it explains the maxSlippageBps=50 pre-committed tolerance policy. This clarifies intent beyond the schema's field-level text.

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 ('Obtain oracle assessment evidence for a swap/DeFi intent BEFORE trading') and enumerates the concrete artifacts returned (preTradeUid, requestHash, CAIP-19 asset ids, certified price, maxSlippageBps). It distinguishes itself from sibling execution_receipt by positioning the handle as pre-execution evidence and execution_receipt as the post-execution verifiable 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 clear sequencing: call this BEFORE trading, execute with your own wallet, then call execution_receipt with the handle + txHash. It also states the refusal condition ('If the verdict is DANGER or BLOCK this tool refuses (do not trade)'). It falls short of explicitly contrasting with the sibling pre_trade_safety_check, leaving the agent to infer which gate to use.

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Two compact sentences, front-loaded with the operation and scope, with no filler. Every sentence earns its place.

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

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

With no output schema and no annotations, the description should convey more about the return value (e.g. a provider-pair matrix) and any constraints. It covers what is computed but leaves the result shape and safety profile implicit.

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

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

Schema description coverage is 100%, so symbol/from/to are already documented with formats and examples. The description only restates that the computation is per-asset over a date range, adding no syntax or default details beyond the schema. Baseline 3 applies.

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

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

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

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

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

The clause 'Helps identify independent vs correlated providers' implies the use case but does not say when to reach for this tool versus alternatives such as compare_oracle_deviation or get_provider_reputation. Usage is inferable but not explicit.

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

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

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

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

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

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

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

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

With no output schema and no annotations, the description supplies the essential missing context: what is returned and when to call it versus get_metrics. It stops short of describing the concrete response fields or ordering, but nothing critical for correct invocation is absent.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies there is nothing to configure and adds no misleading parameter hints.

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

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

States a specific verb+resource ('Identify oracle coverage gaps and single-provider-risk symbols'), defines the key concept inline (assets served by only one oracle = concentration risk), and tells the agent what it returns (breakdowns by provider, chain, symbol). It explicitly contrasts itself with get_metrics, so an agent can pick it without opening sibling schemas.

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

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

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

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

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

No annotations are supplied, so the description carries the full behavioral burden. It does not disclose the return shape (pair matrix vs list), data freshness, or that baseChain is optional and acts as the reference chain for spreads — all material for a market-data 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 short sentences, front-loaded with the core operation and with no redundant restatement of the name. The trailing benefit clause is the only mild 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?

There is no output schema and no annotations, so the description is the only behavioral source; it is adequate on inputs but silent on return format, freshness, and baseChain semantics. For a 3-parameter cross-chain query this leaves 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?

Schema description coverage is 100%, so each parameter is already documented in the schema. The description names provider and symbol but adds no extra meaning, and it never clarifies baseChain's role beyond implying 'across chains'. Baseline 3 applies.

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

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

States a specific verb and resource ('Get pairwise price spreads across chains') scoped by provider and symbol. It is distinguishable from most siblings, though it doesn't explicitly differentiate itself from near-neighbors like compare_oracle_deviation or get_correlation.

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

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

The second sentence ('Useful for cross-chain arbitrage and risk tracking') implies a usage context but never states when to choose this over alternatives or any preconditions. It is implied usage rather than explicit guidance.

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

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

No annotations are provided, so the description carries the full burden. It 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 and delivers very little. It omits whether results are cached (the forceRefresh parameter implies a cache but nothing explains it), what happens when a provider does not cover an asset, and what the returned price payload contains.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though its brevity is partly the same under-specification penalized elsewhere rather than pure conciseness.

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

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

The input schema is rich (enums, per-parameter descriptions), which covers the arguments, but there is no output schema and the description says nothing about the returned price shape or timestamp. For a pricing tool in a crowded sibling set, a short return-value note would close the remaining gap.

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

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

Schema description coverage is 100%, and the schema itself documents all four parameters including the chain and provider enums. The description adds no syntax or format detail beyond the schema, so the baseline 3 is appropriate.

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

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

The description gives a specific verb and resource ("Fetch the latest price") and scopes it to a single provider via "from a specific oracle provider for an asset." That scope distinguishes it from consensus-oriented siblings like get_consensus_price, though it never names an alternative explicitly.

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

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

There is no when-to-use guidance at all. With close siblings such as get_consensus_price, get_oracle_prices_batch, and compare_oracle_deviation, the agent gets no signal about when a single-provider fetch is preferred over a consensus or batch call.

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 yet discloses nothing about caching behavior, rate limits, partial-failure handling (e.g., what happens if one of the 20 queries is invalid), or return shape. The caching hint ('force refresh instead of cache') lives only in the schema, not the description.

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 batch scope front-loaded and zero filler. 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?

No annotations and no output schema, so the description should compensate by explaining batch return behavior and error/partial-failure semantics, which it omits. Adequate to identify the tool but incomplete for a batch endpoint where partial-failure handling matters.

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

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

Schema description coverage is 100%, so the schema already documents queries and forceRefresh. The description's 'Up to 20 queries' merely restates the schema's maxItems: 20 and adds no new meaning, so the baseline 3 applies.

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

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

States a clear verb and resource ('Fetch prices') and scopes it as a batch operation for 'multiple assets/providers in a single request.' This inherently distinguishes it from the singular get_oracle_price sibling, though it does not name that sibling explicitly.

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

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

The description gives no when-to-use guidance, no mention of when to prefer this over calling get_oracle_price repeatedly or over other batch/aggregate siblings. The only constraint offered is 'Up to 20 queries,' which is a limit rather than usage direction.

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 implies a read operation but says nothing about caching (despite a forceRefresh parameter existing), rate limits, the 8760-hour cap, or what happens when chain is omitted. For a 5-parameter 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 no filler; every clause (asset, provider, period, unit) carries information.

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

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

With no output schema and no annotations, the description should say more: the shape/granularity of the returned series, the effect of omitting the optional chain, and the cache-versus-forceRefresh behavior are all unaddressed. The rich schema covers parameters, but behavior remains under-specified.

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 adds only the parenthetical '(in hours)' for period, which the schema already states, so it earns the baseline 3 without adding meaning.

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

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

The description states a specific verb (Get) plus resource (historical price data) and narrows scope to a single oracle provider over an hourly period. This implicitly separates it from siblings like get_oracle_price (current) and get_consensus_price, though no sibling is named explicitly.

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

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

There is no guidance on when to use this versus get_oracle_price, oracle_watch_history, or get_consensus_price. The only hint is the word 'historical', which the agent must infer as the selection criterion.

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?

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

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

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

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

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

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

For a read-only signal tool with no output schema, the description covers purpose, output composition, usage context and the sibling relationship, which is close to complete. It leaves minor gaps around how the optional chain filter changes results and whether the signal is cached or computed per call.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

There is no output schema, so the description correctly enumerates what comes back (verdict stability, degraded-time ratio, worst deviation, mean credibility, recent series), which is the right substitute. Combined with the coverage limitation and the oracle_watch fallback, an agent has enough to call it correctly, though error/empty-history behavior is unstated.

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

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

Schema description coverage is 100%, so the baseline is 3: days, chain, symbol and interval (including the 8-30d hourly and >30d daily rollup rules) are all documented in the schema. The description only restates the window as "last N days" and "recent series," adding no syntax or format detail beyond what the schema already carries.

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

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

The description names a specific verb (retrospective trend) and resource (Oracle Watch for an asset) and enumerates the exact outputs: verdict stability, degraded-time ratio, worst deviation, mean credibility, plus the recent series. It explicitly distinguishes itself from the live sibling (oracle_watch) by framing itself as historical judgment rather than an instantaneous health check.

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

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

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

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the verdict vocabulary (PASS/CAUTION/DANGER/BLOCK), that a recommended maximum position size is returned, that the optional decisionInput is independent and never alters the verdict, and that an EIP-712 signature is produced when signing is enabled. It omits auth/rate-limit behavior and execution model, but the behavioral surface is otherwise richly described.

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-loads purpose in the first sentence and orders information sensibly (use case, verdicts, optional input, verdict semantics, caveat). Dense but largely earns its length; a few clauses (signature mechanics, reputation aggregation) could be tightened without loss.

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

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

No output schema and no annotations, so the description is the sole source of behavioral and return information, and it covers the verdict enum, recommended position size, and the optional signed assessment. It is complete enough to invoke correctly; the main gap is the unreferenced decisionInput parameter and unstated auth/rate-limit posture.

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 80%, so the baseline is 3; the schema already documents asset, chainId, tradeAmountUsd, and targetProviders. The description adds domain framing around oracle aggregation and per-provider deviation but references an optional 'decisionInput object' with 'explicit limits' that does not appear in the input schema, which adds confusion rather than compensating value.

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 ('pre-trade decision-input integrity checkpoint') and the exact decision it supports: verifying the price an on-chain action relies on can be trusted. Distinguishes itself from read-oriented siblings like check_position_safety or compare_oracle_deviation by framing itself as a pre-execution gate, and explicitly limits its own scope with 'A PASS is not principal authorization.'

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 clear when-to-use ('Call this BEFORE executing any on-chain swap/borrow/lend/liquidation/repay') and a when-not-to-proceed rule ('MUST NOT execute trades when the verdict is DANGER or BLOCK'). It does not name sibling alternatives (e.g., check_position_safety) or explain how those compose with this gate, so it stops short of full alternative 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 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.