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

Annotations already carry readOnlyHint=true and idempotentHint=true, and the description adds meaningful behavior beyond them: it explains that the entitlement tier is 'checked fresh, never trusted from the token' and that a tool-call meter is included. This gives an agent useful expectations about safety and freshness without contradicting 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 two dense sentences with no filler. It front-loads the core status information and then gives a concrete diagnostic trigger. Every clause serves a purpose.

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 diagnostic tool, the description covers the key output areas: token verification, entitlement tier, usage meter, and access escalation. The only minor ambiguity is the exact meaning of 'meter' (used calls vs. remaining allowance), but the overall picture is complete enough for an agent to call the tool appropriately.

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 no parameters, so the schema fully covers the input surface. The description therefore does not need to compensate for missing parameter documentation. This matches the baseline for zero-parameter tools.

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 this as a status/access tool: it reports whether the bearer token verified, the entitlement tier, today's tool-call meter, and how to gain full access. Although it lacks an explicit imperative verb like 'returns' or 'reports', the content is specific enough that an agent can determine the tool's purpose. It also implicitly stands apart from the sibling data tools such as latest_article and venue_concentration.

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 concrete trigger: 'Call this first when a subscriber tool is missing from tools/list or a call is refused.' This is clear contextual guidance for when to use the tool. It does not name alternatives or list when not to use it, but for a diagnostic status tool this is a solid and actionable usage cue.

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, openWorldHint=false, and idempotentHint, covering safety and world assumptions. The description adds valuable methodological transparency: detection rules were 'declared before any episode accrued' and episodes 'crossed the pre-registered threshold,' which signals that results are pre-committed rather than ad hoc. No conflict with annotations exists.

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 and front-loads the core subject and output fields in the first sentence. The usage cue is clear and efficient. The final sentence about 'subscriber exit_desk_full' is somewhat cryptic and references a tool not present in the sibling list, slightly reducing clarity, but it does not make the description bloated.

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 carries the burden of explaining what the agent will receive, and it does list the key fields: onset, trough, drawdown fraction, and recovery time. It also gives the scope (BTC ±1% aggregate depth) and the intended use case. It stops short of explaining units, date ranges, or how the threshold is defined, but it is adequate for a zero-parameter historical data 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 input schema is empty with zero parameters, so there are no parameter semantics to clarify. Per the baseline for zero-parameter tools, the description doesn't need to compensate for missing parameter docs. The description instead focuses on the output fields, which is appropriate here.

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: 'Realized depth-collapse episodes in BTC ±1% aggregate depth,' and enumerates the concrete outputs (onset, trough, drawdown fraction, recovery time). It clearly separates this tool from current-state liquidity views by framing it as historical 'actually broken lately' rather than 'how it looks right now.' This is specific enough to distinguish it from siblings.

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

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

The description gives an explicit trigger condition: 'Use when asked whether crypto liquidity has actually broken lately, as opposed to how it looks right now.' This tells an agent when to select it, though it does not name a specific alternative tool to use instead, relying on the contrast with current-snapshot views. The reference to exit_desk_full for the ETH desk adds scope context but is not a full when-not-to-use statement.

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 readOnly/idempotent annotations, the description discloses that values are interpolated from published quote depth, are never a book walk, and refresh only roughly hourly. It also includes a non-advice caveat, giving the agent an accurate picture of staleness and precision 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?

Three sentences lead with the core function, then the returned data, then the estimation methodology and disclaimer. Every sentence earns its place and no wording is redundant with the title or 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, the description compensates by enumerating the key return elements (per-venue bps cost, cheapest/dearest venue, approximate dollar cost, venue spread) and the operational constraints (six BTC venues, hourly refresh, nearest rung). An agent has enough to invoke the tool and interpret its result 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 schema already documents size_usd and its rung behavior completely, so the description adds little parameter-level detail beyond repeating that the size is in USD. This meets the baseline for full schema coverage but does not exceed it.

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 exactly what the tool computes: the current cost of selling a position of a given USD size, per venue, from live public order books for BTC across six venues. This clear resource-and-operation framing separates it from sibling tools such as liquidity_tiers or venue_concentration, even without naming 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?

The description makes the intended use evident ('what selling ... costs RIGHT NOW, venue by venue') and notes the data is refreshed roughly hourly, so an agent can decide it is appropriate for current exit-cost estimates. It does not explicitly state when not to use it or name alternatives, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds useful behavioral guarantees: return the canonical revision verbatim and never rewrite facts. This goes beyond the structured hints and is consistent with them; 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?

Two compact sentences front-load the key result ('exact full-text Undertow editorial published today') and then reinforce the canonical/verbatim guarantee. There is no filler, and every clause adds substantive meaning.

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 still explains what the agent will receive: full text, evidence clock, generation mode, passing quality receipt, and canonical revision. Minor gaps exist around exact formatting or availability timing, but for a zero-parameter read operation the definition is 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 tool has zero parameters, so no parameter documentation is needed. The schema coverage baseline for zero-parameter tools is 4, and the description appropriately focuses on return behavior rather than 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 a specific resource ('Undertow editorial published today'), a clear retrieval verb ('returns'), and precise scope ('exact full-text', 'canonical revision verbatim'). It clearly stands apart from the sibling tools, which appear to be access-status, liquidity, and exit-context 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 implies when to use it: when the agent needs the authoritative, unmodified full text of today's Undertow editorial, along with its evidence clock, generation mode, and quality receipt. It does not explicitly name alternatives or say when not to use it, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds behavioral value by disclosing that PARTIAL means insufficient scoring history and is reported honestly rather than guessed, and it clarifies the funding-stress overlay regime.

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

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

Three sentences, each earning its place: the first defines the content, the second clarifies a data-quality convention, and the third gives usage direction and names the alternative. Information is dense but well-structured and 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 zero-parameter read-only tool with annotations covering idempotency and read-only behavior, the description is complete. It communicates the scope, the meaning of a status value, and how to navigate to more detailed alternatives.

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 is empty, so the description carries no parameter burden. The baseline of 4 applies because there are no parameters to explain.

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 resource (Undertow board's TIER ROW), enumerates the market segments covered, and explains the funding-stress overlay. It also distinguishes itself from the subscriber board_full tool, so an agent can tell exactly what this tool 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?

It explicitly states when to use the tool ('how liquid are markets today' at one glance) and points to board_full as the fuller alternative. It mentions drilling into crypto with 'the other tools' without naming them, which is slightly vague, but overall usage context is 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, idempotentHint, and openWorldHint=false, so the description's job is to add trust-relevant behavior. It does, stating that calls are hash-chained and signed before outcomes, scored against an immutable point-in-time board, and that misses remain published. No contradiction with 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?

Three compact sentences: definition/provenance, return value, and usage guidance. The most revealing trait ('signed BEFORE outcome') is front-loaded, and no words are 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 parameterless tool with no output schema, the description provides enough context: what the record is, why it is trustworthy, what is returned, and when to use it. Nothing essential is missing for an agent to select and call it correctly.

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

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

There are zero parameters and schema coverage is 100%, so the description cannot add parameter-level meaning. The baseline for a parameterless tool is met, and the description instead clarifies what the returned record will contain.

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 resource (Undertow's sealed forward-calls record) and states that the tool returns the full record with outcomes and ledger root. It also differentiates itself by emphasizing provenance features—hash-chained, signed before outcome, misses kept—which no sibling description hints at.

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 explicitly provides a trigger condition: 'Use when asked whether Undertow's judgements can be trusted...'. There are no named alternatives or when-not conditions, but among the listed siblings none is an obvious substitute, so the usage context is 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?

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, openWorldHint, and idempotentHint, and the description strengthens these by explaining that the measure is display-only on frozen grids, that 13F filings exclude shorts/options, and that all numbers are floors. It also discloses non-obvious output behavior such as reporting counts as bands rather than points and returning one of NO_CALL / CALL / EQUITY_EXHAUSTED.

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 dense and information-rich but not especially concise or scannable. Important 'when to use' guidance appears near the end, and the parenthetical explanation about why counts are bands adds interpretive detail beyond what is needed for tool selection/invocation. The 'Not investment advice' tag is also non-essential.

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 there is no output schema, the description does a good job compensating by enumerating the main output components: effective position count, whole-book days-to-exit, the margin grid states, and the default versus per-filer row behavior. It also conveys the tool's limitations. A structured field-by-field output contract would make it 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?

The input schema has 100% coverage of its single optional cik parameter, including the meaning of omitting it versus passing it. The description's 'Default is the per-filer headline; pass cik for one filer's full free row' mostly restates the schema rather than adding new parameter-level 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?

The description clearly identifies a specific verb and resource: it measures whether a watched 13F filer's book can exit by reporting position counts, days-to-exit bands, and a leverage/shock/maintenance-margin grid. It also explicitly ties the tool to a concrete question ('whether a fund's book could exit'), which distinguishes it from generic exit-cost or liquidity 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 gives an explicit use case: 'Use when asked whether a fund's book could exit, or what the Aschenbrenner failure mode looks like in a current filing.' It also notes important exclusions via 'Display-only measure on frozen grids' and '13F sees no shorts or options, so every number is a floor.' It does not name sibling tools as alternatives, so it stops just short of the top score.

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, so the safety profile is covered. The description adds useful interpretive context about what low effective venue count implies, without contradicting the annotations or introducing hidden 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?

Two tight sentences front-load the core question, immediately enumerate the output fields, define HHI inline, and add a meaningful interpretation. No filler or redundant restating of the 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?

With no input schema and no output schema, the description carries the full burden of explaining what the agent will receive. It lists every major output component and the practical significance of the result, making the tool complete for correct invocation and interpretation.

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 there is no parameter documentation burden. The description instead focuses on the output metrics, which is appropriate. Baseline for zero-parameter tools is 4.

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 tool as a daily readout of BTC depth concentration, specifying the exact metrics: largest venue share, HHI, effective venue count, and per-venue depth in USD. It also contrasts itself with 'exit_desk_full' by noting what that alternative adds, helping an agent distinguish it from related 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 gives context for when the readout matters ('Low effective venue count means an exit depends on one venue staying open') and explicitly mentions an alternative for ETH or venue-failure scenarios. It could more directly name which sibling tools to use instead, but the guidance is sufficient.

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 goes further by revealing the weighting methodology, the blindness gap concept, depth concentration metrics, dislocated venue names, and the experimental status with payload notification. This is valuable behavioral context beyond any structured field.

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 dense but every sentence earns its place: definition, formula, exclusions, key outputs, use cases, experimental caveat, and disclaimer. It front-loads the core meaning and then layers supporting details without 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?

Despite having no output schema, the description enumerates the key return elements: consensus mark, blindness gap, depth concentration, dislocated venues, and experimental payload flag. For a zero-parameter tool, this provides a complete picture of what to expect and 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?

The tool has zero parameters, so there is no parameter ambiguity to resolve. The schema is empty with 100% coverage, so the description does not need to compensate for undocumented inputs. The baseline for zero-parameter tools is 4, and the description adds no conflicting or confusing parameter-related information.

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: computing a cross-venue consensus mark for BTC and ETH. It clearly distinguishes itself from a simple median or single-venue price by specifying the exact weighting formula and explicitly saying what it is NOT. This makes the tool's purpose unmistakable even among 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 gives concrete use cases: 'what is BTC/ETH actually worth right now', 'is an exchange dislocated', and 'before trusting any single venue's price'. It also warns that the tool is experimental until accrual gates pass. However, it does not explicitly name when to avoid this tool or point to a sibling alternative, though the use cases are clear enough.

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