Undertow market liquidity and exit-cost tools

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, non-mutating operation. The description adds context about what the tool returns (identity, entitlement, usage meter, access instructions) and the freshness of the check ('freshly checked entitlement'), which goes beyond the annotations. No contradiction.

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, information-dense sentence that front-loads the key outputs (identity, entitlement, meter, instructions) and ends with a clear usage trigger. Every word earns its place.

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

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

For a zero-parameter, read-only, idempotent tool with no output schema, the description fully covers what an agent needs: what it returns, when to call it, and the safety profile from annotations. Nothing 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?

The tool has zero parameters, so the schema is trivially complete (100% coverage). The description doesn't need to explain parameters, and it doesn't. Baseline 4 for zero-param tools 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 clearly states the tool's purpose: it provides current identity, freshly checked entitlement, daily usage meter, and access instructions. The verb 'Use when' further clarifies its role. It distinguishes itself from siblings by focusing on access status rather than trading or research functions.

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 explicitly states when to use this tool: 'Use when a subscriber tool is missing or refused.' This provides clear context and a specific trigger condition, which is strong guidance for an agent deciding between 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?

Annotations already provide readOnlyHint=true, idempotentHint=true, and openWorldHint=false, but the description adds valuable details: it withholds 'stale, future, uncovered or unconverted venue estimates' and 'Fees excluded'. These specifics about data filtering and fee handling go beyond the annotations and inform the agent about the tool's behavior.

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

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

The description is two sentences, front-loaded with the core action and then conditions/caveats. Every phrase adds value: the compare scope, the filtering behavior, the fee exclusion, and the research-only caveat. No wasted words, highly efficient.

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

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

For a simple tool with 2 optional parameters and no output schema, the description covers the purpose and key behavioral constraints. However, it does not describe the response format (e.g., what the comparison result looks like) or how the rungs/brackets classification appears in output, leaving some uncertainty for an agent expecting a concrete return value.

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

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

With 0% schema description coverage, the description must explain the parameters. It maps sizes_usd to 'up to four BTC sell sizes' and implies max_age_seconds through 'freshness' and 'stale' references. However, it doesn't explicitly name the parameters, explain units, or clarify how 'brackets' vs 'exact rungs' relate to input values. It partially compensates but leaves ambiguity.

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 the tool compares up to four BTC sell sizes, with specific comparison modes ('exact rungs, brackets or out-of-range') and explicitly excludes certain data ('stale, future, uncovered or unconverted venue estimates'). It also clarifies it is 'research only, no trade clearance', distinguishing it from execution tools and siblings like exit_cost or trade_safety_exit_context.

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 says 'research only, no trade clearance', which tells the agent not to use it for trade execution, and implies it is for analyzing exit sizes. However, it does not explicitly compare with sibling tools (e.g., exit_cost for cost analysis, trade_safety_exit_context for safety), nor does it give clear 'use this when...' guidance. Usage context is inferred rather than stated.

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

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

Annotations already mark it read-only and idempotent, and the description adds useful behavioral context: it uses a constant-rate scenario rather than live data, and it defines the funding sign convention ('Positive funding: longs pay shorts'). This goes beyond what the annotations alone 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?

The description is three short sentences with no filler, front-loads the outputs, and adds two high-value caveats: the funding sign convention and the constant-rate scenario. 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?

The tool has no output schema and a high parameter count with sparse schema descriptions, so the description should clarify output meaning and units. It lists the outputs but does not specify units or the precise meaning of 'linear break-even move,' leaving some ambiguity for an agent deciding how to interpret the result.

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

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

Schema description coverage is only 20%, so the description should compensate for missing parameter documentation. It does add meaning by clarifying the funding sign convention and the constant-rate nature of the rate parameter, but it does not explain the role of notional_usd, side, settlements, or round_trip_fee_bps in any 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?

The description names the specific computation: perpetual funding cashflow, fees, net carry, and linear break-even move, and the title adds the verb 'Calculate.' It clearly identifies a financial calculation tool rather than a data-retrieval or monitoring tool, though it does not explicitly distinguish itself from sibling tools like exit_cost.

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

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

The description gives clear context: this is for caller-provided parameters under a constant-rate scenario, explicitly not live rates or a forecast. This is enough for an agent to know when to use it, though it does not name specific alternatives or state explicit 'use this instead of X' 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?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value beyond that by disclosing the simulation nature: user-supplied linear shocks, no live data, and no liquidation/probability modeling. This gives the agent an accurate mental model of the tool's behavior without contradicting annotations.

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

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

The description is two sentences with zero fluff. The main purpose is front-loaded, followed by two clarifying constraints. Every sentence earns its place and adds distinct information.

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

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

The tool has no output schema, so the description should ideally describe the return structure. It lists output categories ('P&L, equity and gross asset/venue concentration') but not their formatting or how they are organized. It also gives no guidance on parameter construction beyond what the schema field names imply. For a computation tool with nested inputs, the description is adequate but not 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?

With 0% schema description coverage, the description must carry the parameter-meaning burden. It clarifies that 'price_change_pct' represents a linear shock, 'up to twenty exposures' bounds the positions array, and the computed outputs are P&L, equity, and concentration. However, it does not explain optional fields like 'venue' or 'cost_usd', nor how they interact with the core calculation, so it only partially compensates.

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

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

The description states a specific action ('Caller-input linear price shocks') and resource ('crypto portfolio'), with explicit scope ('up to twenty exposures') and output categories ('P&L, equity and gross asset/venue concentration'). It also differentiates from siblings by clarifying that symbols are scenario labels, not live coverage, and that no liquidation or probability model is included.

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

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

The description gives clear contextual boundaries: it is a scenario-based stress test, not a live market tool ('Symbols are scenario labels, not live coverage') and not a risk model ('No liquidation or probability model'). It implies when to use this tool (for hypothetical linear shocks) and when not to, though it does not explicitly name sibling alternatives.

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

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

Annotations already declare the tool read-only and idempotent, so the safety profile is covered. The description adds non-obvious meaning beyond that: 'Zero episodes is distinct from missing observations' clarifies a potentially misleading data-absence case, and 'Subscriber exit_desk_full adds ETH' discloses subscription-dependent output. It does not describe exact output fields or time bounds, but for a zero-parameter read-only tool this is meaningful disclosure.

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

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

The description is three short sentences, each carrying distinct information: the core output, the zero-vs-missing data interpretation, and the subscriber-dependent ETH coverage. It is front-loaded with the main subject and contains 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 zero-parameter, read-only, idempotent tool with no output schema, the description covers the main return concept (collapse episodes with phases), the critical zero-vs-missing distinction, and the ETH variant. It is slightly underspecified about what 'pre-registered rules' precisely are and the exact output shape, but the tool's simplicity makes the description largely sufficient.

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

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

The input schema has zero properties, so there are no parameter semantics to document. With 0 params, the baseline is 4, and the description's scope statement is sufficient; no parameter-level elaboration is needed or possible.

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

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

The description names a concrete resource: 'Realized BTC depth-collapse episodes, onset, trough and recovery under pre-registered rules.' This is specific enough for an agent to know what data is being exposed. It lacks an explicit verb like 'lists' or 'returns,' and it does not actively differentiate from sibling tools by name, which keeps it below the top score.

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 guidance or alternative tool comparison, but the description implies this is for querying realized depth-collapse episodes and offers a relevant eligibility condition: 'Subscriber exit_desk_full adds ETH.' This helps an agent understand scope and output variation, though it does not say what to use instead for related liquidity, exit, or venue metrics.

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

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

The description adds important behavioral caveats beyond the readOnlyHint and idempotentHint annotations: estimates are interpolated, roughly hourly, exclude fees, and are not executable quotes. This helps the agent avoid misusing the results.

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

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

Three sentences with no filler: the core function is front-loaded, followed by caveats, then a pointer to the alternative tool. 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 single-parameter, read-only tool with no output schema, the description is complete: it explains the output type, the estimation limitations, and how to get comparison/freshness information from a 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?

The schema already documents size_usd and the nearest-rung behavior with 100% coverage. The description repeats the 'nearest published USD rung' concept but adds no new parameter-level meaning, so the baseline of 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 names a specific resource and operation: 'BTC sell-cost estimates by venue at the nearest published USD rung.' It clearly distinguishes itself from the sibling crypto_exit_check by positioning that tool as the comparison/freshness alternative.

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

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

The final sentence explicitly routes the agent to crypto_exit_check when comparing sizes and freshness, giving a clear alternative and trigger condition. It implies this tool is for single-size, current-rung sell-cost estimates.

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

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

Annotations already mark the tool read-only and idempotent, and the description adds useful output-context guarantees: the article is returned with its evidence clock and passing quality receipt, and the content is not rewritten. This is consistent with readOnlyHint=true.

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

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

A single sentence that front-loads the action and resource, with every clause adding meaningful detail: 'canonical', 'evidence clock', 'passing quality receipt', and 'no rewritten facts'. There is no filler or repetition of schema content.

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

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

For a zero-parameter read tool, this is complete: it identifies the target article, what is included in the result, and the integrity guarantee. Although there is no output schema, the description gives enough to know what a successful call returns.

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 are no parameters, so the input schema is trivially complete and the description does not need to document arguments. The baseline of 4 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?

Clearly names the operation 'Read' and the resource ('canonical full-text Undertow editorial'), with qualifiers like 'evidence clock' and 'passing quality receipt' that explain what the output contains. It is unambiguous and easily distinguishable from the unrelated sibling 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?

The description signals use for retrieving the authoritative Undertow editorial, and the 'no rewritten facts' phrase indicates this is the original rather than a summary or rework. It does not name explicit alternatives or exclusion cases, but the zero-parameter schema and unique resource make the intended use clear.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds non-obvious semantic context—'PARTIAL may mean missing qualifying history or unpassed replay; it never means calm'—and asserts that measure counts are exact, which is valuable beyond the structured metadata.

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

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

The description is compact at two sentences and front-loads the main content before clarifying a likely misinterpretation. It stays efficient, though it relies on domain-specific terms like 'Seiche', 'replay', and 'calm' that are not expanded.

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

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

For a zero-parameter, read-only tool with no output schema, the description covers what the tool provides and explains the ambiguous PARTIAL value. It does not detail the output layout, but with no inputs and strong annotations, nothing essential for selecting or invoking it 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?

The input schema is empty with zero parameters, which is the baseline 4 case. There are no parameter semantics needed because there is nothing to configure or clarify.

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

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

The description identifies the tool's content—nine market-segment tiers, Seiche funding overlay, exact measure counts, replay eligibility, and withholding reasons—which makes its role clear and distinguishes it from funding-only siblings like crypto_funding_cost. However, it lacks an explicit action verb like 'returns' or 'shows', so it reads as a content inventory rather than a precise operation statement.

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 'Full board' framing and mention of exact counts imply a comprehensive overview role, but the description gives no explicit when-to-use guidance or routing to alternative siblings. The PARTIAL clarification is useful output interpretation, but it does not address tool selection.

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

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds meaningful behavioral context: it returns 'metadata, dates and rights only' and explicitly excludes 'shared score or execution authority'. This goes beyond the structured hints and clarifies what the tool does not do.

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

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

The description is two sentences with no filler. The core purpose is front-loaded, and the constraint about metadata-only follows immediately. Every word earns its place.

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

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

For a read-only tool with no output schema and three optional parameters, the description gives a high-level outcome (metadata/dates/rights) but omits parameter semantics and return shape (e.g., list vs. object, pagination behavior). It is adequate for basic understanding but not fully complete for an agent to call it without further schema details.

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

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

Schema description coverage is 0%, and the description provides no information about the three parameters (limit, topic, offset). It does not explain what 'topic' enum values mean, how pagination via limit/offset behaves, or any parameter constraints. The description completely fails to compensate for the schema gap.

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

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

The description uses a specific verb ('discovery') and names distinct resources ('Seiche funding, LiquiLens institutions, Palimpsest evidence'), and it explicitly limits scope to 'metadata, dates and rights only'. This clearly distinguishes it from sibling tools that likely provide scores or execution authority.

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 usage through its scoped purpose and the 'metadata only' caveat, but it does not explicitly state when to use this tool over alternatives or name any sibling alternatives. The boundary is present but no direct when-to-use guidance is 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds that it 'Report hits and misses together' and mentions 'ledger root' and 'decided counts', which gives some sense of output content, but the meaning is obscured. It does not contradict annotations.

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 brief (two sentences) but lacks clarity and structure. It front-loads cryptic terminology instead of a clear purpose, and the second sentence is redundant with the first. It is concise but not well-organized for comprehension.

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 parameters, the description must explain what the tool returns, but it leaves key terms undefined. It does not clarify what a 'call' is, what 'misses' represent, or how the data could be used. This is insufficient for an agent to decide when to call this tool.

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

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

The tool has zero parameters, so the schema covers everything. The description does not need to explain parameters, and it does not miss anything. Baseline for 0 params is 4, and there is no negative contribution.

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 'Forward calls sealed and signed before outcomes, including misses, decided counts and ledger root' is cryptic and does not clearly state what the tool does. It uses the vague verb 'Forward' and refers to undefined concepts like 'calls', 'misses', and 'decided counts' without context. It also does not differentiate from sibling tools, which appear to be about trading and analytics.

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 offers no guidance on when to use this tool versus siblings. It does not mention any context, prerequisites, or alternatives. An agent would have no way to know if this tool is appropriate for a given task.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description exposes meaningful internal behavior: it binds the request to PIT and rechecks USD/USDT conversion, required bid bands, six venue clocks, and startup SHA. It also disclaims nearest-rung, live, execution, and clearance behavior. No contradiction exists between the description and the annotations.

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 compact, front-loads the primary purpose, and each sentence earns its place: the first states what the tool returns, the second what it verifies, and the third what it explicitly does not do. The dense acronyms are acceptable given the tightly scoped domain and the absence of redundant filler.

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

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

The description makes the read-only, idempotent, context-only nature clear, and it enumerates the internal checks the tool performs. But there is no output schema, and the description never specifies the shape or concrete contents of the returned 'evidence.' An agent knows when to call it and what it will not do, yet lacks a clear picture of what it will receive.

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

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

With only 33% schema description coverage, the description partially compensates: 'sell' maps to side, 'BTC/USD' to instrument, 'observe/paper' to mode, and 'exact-rung' to requested_size_usd. However, it does not clarify the venue null constraint or explain terms like 'source pack' and 'reviewed rights' in relation to the parameters, leaving the parameter story incomplete.

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

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

The first sentence states a specific verb and resource: it returns 'Exact-rung BTC/USD sell evidence for observe/paper Trade Safety.' The description further distinguishes the tool by explicitly saying it is 'Context only' and that it provides 'no nearest rung, live mode, execution or clearance authority,' which separates it from execution-oriented siblings like exit_cost or unwind_watch.

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 clearly identifies the intended use case: observe/paper Trade Safety. It also gives explicit exclusions, noting the tool is not for live mode, execution, or clearance authority. However, it does not name an alternative sibling to use when those exclusions apply.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description only needs to add non-obvious behavioral context. It adds 'no live execution model' and 'declared blind spots', which meaningfully warn agents about the tool's limitations beyond the structured hints.

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

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

Three short sentences deliver the core output, the access/limitation context, and the alternative tool. There is no filler and the most important information is front-loaded.

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

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

For a read-only tool with one optional parameter and no output schema, the description covers the key output components and limitations while the schema covers the cik behavior. An agent has enough to select and invoke the tool correctly.

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

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

The single optional cik parameter is already fully described in the schema, including the contrast between the all-filer headline and a specific filer's row. The description adds no extra parameter-level meaning, so the baseline of 3 is appropriate given 100% schema coverage.

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 identifies the output as published watched-filer unwind risk and names its components: effective positions, days-to-exit brackets, and declared blind spots. It distinguishes itself from the full scenario grid by pointing to unwind_stress, but it lacks an explicit imperative verb like 'returns' or 'calculates'.

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 explicitly frames this as a 'public headline only' view with 'no live execution model', making the tool's limited scope clear. It then directs users needing the full scenario grid to unwind_stress, providing a concrete alternative 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?

The annotations already mark this as read-only and idempotent, and the description adds useful behavioral scope: it is limited to BTC by default, is two-sided (bid/ask), and varies by subscription level (exit_desk_full adds ETH and a venue-failure scenario). It does not describe response format or interpretation, but for a read-only, zero-parameter metric tool this is acceptable contextual disclosure.

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

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

Two short sentences front-load the core product (BTC two-sided depth concentration) and its key metrics before adding the subscriber conditional. Every clause adds information and there is no filler, repetition, or unnecessary qualification.

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

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

For a zero-parameter read-only tool with no output schema, the description provides enough to invoke it: the asset (BTC), the side (two-sided), the metrics returned, and a subscription condition that changes scope. It does not define terms like 'effective venue count' or specify whether output is returned as a single snapshot, but these are secondary for a simple data retrieval 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?

The input schema is an empty object with 100% schema description coverage, so there are no parameters to document; the baseline for zero parameters is 4. The description contributes no parameter details because none are needed, and it does not introduce any undocumented inputs.

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

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

The description identifies the resource ('BTC two-sided depth concentration') and enumerates returned metrics (HHI, effective venue count, top venue, per-venue depth), so an agent can tell what the tool reports. It lacks an explicit verb such as 'returns' or 'calculates,' and it does not explicitly distinguish itself from siblings like liquidity_tiers or depth_episodes, 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 statement about when to use this tool instead of liquidity_tiers, depth_episodes, or crypto_exit_check. The subscriber note ('adds ETH and the venue-failure scenario') describes access-tier scope, not a decision rule for choosing between tools, so the agent is left without routing guidance. This is effectively no usage guidance beyond what the title implies.

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

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

Annotations already cover read-only and idempotent behavior, and the description adds valuable context by stating the tool is experimental until accrual gates pass and has no execution authority. It also discloses the weighted-by-depth computation logic and output components, going beyond the structured annotations.

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

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

The description is a single dense sentence with no filler. Every clause adds either the computation method, the output components, or an operational caveat, and the title reinforces the purpose without redundancy.

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

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

For a zero-parameter diagnostic tool, the description covers purpose, computation logic, output concepts, and trust/safety status. Since no output schema exists, more detail about return shape or units would help, but the essential context for an agent to call and interpret the tool is present.

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

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

The tool has zero parameters and the schema coverage is 100%, so there are no argument semantics the description needs to clarify. The description accurately focuses on the computation and output context instead.

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 the tool produces a BTC/ETH consensus mark weighted by depth and names additional diagnostics such as blindness gap, concentration, and dislocated venues. This distinguishes it from sibling tools like venue_concentration or depth_episodes, though it lacks an explicit verb such as 'calculates' or 'returns.'

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 context is implied by the title 'Consensus price when venues disagree' and by the consensus-mark focus, but the description never explicitly says when to use this tool versus alternatives like venue_concentration or depth_episodes. No exclusions or routing guidance is provided.

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