Undertow market liquidity and exit-cost tools

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

The annotations already establish that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds useful context by indicating that the tool reports subscriber tool availability, including missing or refused tools, but it remains too compressed to explain how that diagnostic behavior works in practice.

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 extremely compact and front-loads the key categories of information. It contains no filler, though the fragmentary semicolon-separated style makes the structure slightly less clear than a complete sentence would.

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 status tool with rich annotations, the description covers the main content areas. Still, the absence of an output schema means the description should more clearly explain what the returned identity, entitlement, usage, and missing/refused-tool information looks like or how it should be interpreted.

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 no parameters, so the parameter semantics baseline is 4. The absence of parameters is consistent with the description's status/reporting role.

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 lists the data categories the tool exposes (identity, entitlement, daily usage, access instructions, missing/refused subscriber tools), which is enough to infer it is an access/status tool. However, it does not use a clear verb+resource construction, so the purpose remains only vaguely implied rather than explicitly stated.

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, when not to use it, or how it relates to any of the sibling tools. The agent must infer the use case from the terse noun list.

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 the safety profile (read-only, idempotent, non-destructive, closed-world). The description adds useful behavioral context beyond that: it withholds stale/future data, excludes uncovered or unconverted venues, excludes fees, and clarifies no trade clearance.

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 the core purpose front-loaded and no filler. Its brevity contributes to ambiguity, but it is structurally 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 two-parameter read-only tool with no output schema and no parameter descriptions, the description gives useful caveats but remains incomplete. It does not explain return semantics, what 'rung/bracket' means, or how max_age_seconds affects results.

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

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

Schema description coverage is 0%, so the description must explain the parameters, but it does not. It hints at four sell sizes (matching the default) but never explains sizes_usd bounds/meaning or max_age_seconds at all.

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 says it produces 'Four BTC sell sizes by rung/bracket' and mentions freshness/caveats, so the general domain is clear. But 'rung/bracket' is unexplained, and the description does not explicitly distinguish this from 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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named. 'Fees excluded; no trade clearance' implies it is not an execution tool but does not route the agent between this and 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?

Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the description is free to add modeling semantics — and it does, disclosing the constant-rate assumption and the direction of funding flow. What it does not disclose is whether fees are charged per side or round trip, or how break-even is derived.

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, front-loaded fragments with no filler; the funding-direction rule and the scenario caveat appear immediately. The telegraphic style is efficient but borders on cryptic.

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 at least hints at returns (net carry, linear break-even), but it never states units or shape, and 'linear break-even' is unexplained. Combined with four undocumented inputs, an agent can call it but cannot fully predict or 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 coverage is only 20%, so the description has to carry the load for four of five parameters, and it does not. notional_usd, side, settlements and round_trip_fee_bps are left undefined in both places, and the one helpful clarification (positive rate means longs pay shorts) merely restates the schema description.

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

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

Names a specific computation (perpetual funding/fees, net carry, break-even) over explicit inputs (notional, side, rate, settlements). It is clearly distinct from siblings like exit_cost or crypto_exit_check, though it never names an alternative directly.

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?

"Constant-rate scenario, not forecast" gives one real usage boundary — this is an approximation, not a projection. Beyond that, there is no stated when-to-use/when-not relative to siblings such as crypto_exit_check or exit_cost, so the agent must infer.

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 readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuine model context beyond that: shocks are linear, exposure count is capped at 20, and liquidation and probability modeling are explicitly out of scope — material for interpreting 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 short, front-loaded fragment sentences with no filler. It is efficient, though the telegraphic style ('Linear input shocks, 20 exposures') borders on cryptic.

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

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

With no output schema, the description does name the outputs (P&L/equity, asset/venue concentration), which is helpful. But the return shape and the role of equity_usd in normalizing P&L are unstated, and no usage routing is provided for a compute tool sitting among many overlapping 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 description coverage is 0%, so the description must compensate. It clarifies two key semantics: 'linear input shocks' frames price_change_pct as a shock input, and 'Symbols label scenarios' explains that asset values are labels rather than live lookups. It says nothing about equity_usd's role as the denominator, venue, cost_usd, or side.

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 operation on a specific resource: shocks applied to a portfolio, computing P&L/equity and asset/venue concentration. The phrase 'no liquidation/probability model' carves out scope against siblings like crypto_exit_check and exit_cost, though the telegraphic phrasing requires some interpretation.

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

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

The negative scope statement ('No liquidation/probability model') hints at when not to use it, and '20 exposures' implies the sizing limit. But no sibling is named and no positive when-to-use condition or prerequisite is given, leaving routing largely 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description still adds real behavioral content: 'under preregistered rules' signals a fixed, non-discretionary methodology, and 'Zero differs from missing' warns that zero values are observations rather than absent data. What remains unstated is the coverage universe (BTC only? ETH per the subscriber line?) and the temporal extent of an episode.

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 fragments with no filler and the substantive scope statement is front-loaded. But the final fragment 'Subscriber exit_desk_full: ETH.' is telegraphic to the point of being unparseable without insider context, so terseness here costs comprehension rather than earning efficiency.

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 this is close to adequate, and the zero-vs-missing rule is exactly the kind of caveat that matters. With no output schema present, however, the description should say more about what an 'episode' record contains beyond naming onset/trough/recovery, and the ambiguous ETH/subscriber clause leaves the asset universe genuinely unclear.

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

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

The tool takes zero parameters, so there is no parameter semantics for the description to carry and the baseline of 4 applies. The only semantic clarification offered ('Zero differs from missing') concerns output interpretation rather than inputs, which is appropriate for a parameterless call.

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 core phrase 'BTC depth-collapse onset/trough/recovery under preregistered rules' does name a specific resource and its phases, so an agent can infer it returns realized market-depth collapse episodes. However, the trailing fragment 'Subscriber exit_desk_full: ETH.' introduces an unexplained ETH reference that blurs whether the tool covers BTC, ETH, or both, and nothing distinguishes it from siblings like unwind_watch, liquidity_tiers, or 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?

There is no statement of when to use this tool versus the many adjacent sibling tools (unwind_watch, exit_cost, venue_concentration all concern exits/liquidity). The 'Subscriber exit_desk_full' fragment hints at an access tier but never states a condition, prerequisite, or exclusion an agent could act on.

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 readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds substantive context beyond that: results are estimates, fees are excluded, and the values are 'not executable' — a critical caveat that changes how an agent should present them.

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?

Zero filler: three fragments, caveats front-loaded before the handoff pointer. It is dense to the point of being telegraphic, but every clause carries information and nothing is redundant.

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

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

For a single-parameter read-only tool with full annotation and schema coverage, most requirements are met. Still missing: the return shape implied by the title ('per venue' — how many venues, what fields, spread vs mid reference), which the absent output schema leaves entirely undocumented.

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%; size_usd already documents the $1,000–$1,000,000 rung range and nearest-rung snapping. The description restates 'nearest-rung' but adds no new syntax, unit, or edge-case 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 resource and computation: BTC sell-side cost estimates derived from interpolated bid-depth bands at the nearest published rung. The verb is implicit ('estimates') but the resource and method are concrete, and the pointer to crypto_exit_check for sizes/freshness distinguishes it from that sibling.

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 routes one specific need (sizes/freshness) to crypto_exit_check, which is a genuine alternative-handoff. However, it never states the general when-to-use condition or excludes other plausible siblings like liquidity_tiers, unwind_watch, or trade_safety_exit_context, leaving selection partly to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower. The description still adds real behavioral context beyond them: it declares the tool is arithmetic-only, will not fetch or store anything, does not verify balances, and returns withheld-cash reasons — exactly the information an agent needs to avoid treating the output as authoritative settlement state.

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 dense sentences with no filler; the input enumeration is front-loaded and the scope disclaimer closes it. The telegraphic style is efficient, though a few fragments ('aware ISO clocks') cost parseability for little gain.

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 17-parameter, 16-required tool with no output schema, no parameter descriptions and no worked output shape, the definition is thinner than ideal. It signals withheld-cash reasons exist but never explains what a 'gate' outcome is or how cleared/access_restricted/pledged interact with cutoff and validity windows, leaving the agent to guess at the core logic.

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% with 17 parameters, so the description must compensate. It does add genuine semantics — fineness bounded to (0,1], FX expressed per USD with USD=1, bid in USD per troy ounce, clocks as timezone-aware ISO — but leaves fx_fee_bps, quote_currency, max_quote_age_seconds and the three gating booleans (cleared, access_restricted, pledged) unexplained despite 'gates' being the tool's central concept.

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

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

States a specific resource and computation: gold sale cash gates computed from decimal kg, fineness, USD/oz bid, fees and FX. The 'gates' framing plus the closing 'Arithmetic and withheld-cash reasons only' makes the tool's nature (pure calculation, not a data source) unambiguous, and the gold domain clearly separates it from the crypto/venue siblings.

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

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

Usage is implied rather than stated: an agent infers it should call this when it needs gold sale proceeds or cash-gating outcomes from supplied inputs. The negative scoping ('no fetch, storage, execution or verified balance') is helpful, but no sibling alternative is named and no precondition or when-not condition 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 readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real value beyond that by naming two failure modes ('missing text/failed receipt errors') and clarifying that no prose is generated, but it leaves 'clock' and 'quality receipt' unexplained and says nothing about freshness or caching.

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?

Extremely short with the resource front-loaded, and no sentence is wasted in the sense of padding. However the fragment style ('clock/quality receipt', 'Board: liquidity_tiers') trades brevity for ambiguity, so the compactness comes at a comprehension 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?

With no output schema, the description carries the full burden of describing the return value; it lists five fields but defines none of the jargon fields, and the error conditions are asserted without saying what the agent should do. Adequate to attempt a call, thin for interpreting the response.

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

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

Zero parameters, so the baseline is 4, and the description reinforces it explicitly with 'No args,' removing any doubt about needing input. Nothing further can reasonably be demanded.

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 the resource precisely ('Latest published editorial') and enumerates what it returns (title, full text, URL, clock, quality receipt), which is specific enough to distinguish it from every sibling (all of which are crypto/liquidity analytics). It stops short of 5 because 'editorial' and 'quality receipt' are never grounded, so the agent knows the shape of the payload but not really what the resource is.

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 args or generated prose' tells the agent how to call it, not when to prefer it over an alternative. The trailing 'Board: liquidity_tiers' implies a relationship to that sibling but is an unlabeled fragment rather than a stated condition.

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 read-only, idempotent, non-destructive, closed-world behavior, so safety is covered. The description adds a partial-coverage caveat (missing history/unpassed replay, never calm), which is useful behavioral context, but its meaning is cryptic and it gives no return-format or freshness details.

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?

It is short and front-loads the content list, but the fragmentary phrasing is under-specified rather than efficient. Phrases like 'never calm' are packed in without enough context to earn their 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 parameters and no output schema, the description must carry most of the explanatory burden. It enumerates the board's components and notes partial coverage, but the jargon and incomplete sentences leave an agent unsure what exactly is returned and how to interpret the caveats.

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 has no parameters to explain, and the empty schema is consistent with the description's implicit no-input nature.

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 lists the data the tool surfaces (nine segment tiers, Seiche funding, measure counts, replay/withholding reasons), which gives some concrete content beyond the opaque name. However, terms like 'Seiche' and 'replay/withholding reasons' are unexplained, and it does not distinguish this 'full board' from sibling tools such as depth_episodes 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?

There is no explicit guidance on when to call this tool versus the many sibling liquidity/venue tools. The fragment 'PARTIAL: missing history/unpassed replay, never calm' hints at limitations but does not tell an agent when this board is the right choice or when another tool is preferable.

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 declare read-only, idempotent, closed-world, and non-destructive behavior. The description adds some valuable caveats, notably "No summary pagination" and "Retrieval age is not observation freshness," but it does not explain what rights/clocks data means or how results are shaped.

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

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

The description is short and has no obvious filler, but it is telegraphic and fragmented rather than clearly structured. The information is compact yet under-explained, which hurts usability more than length does.

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, zero schema description coverage, and the description leaves view semantics and return fields largely unexplained. For a metadata/context tool with three parameters, this is not enough for an agent to invoke it confidently.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, but it only vaguely connects pagination to summary views and mentions records/total/next_offset. It does not explain the view enum values or the limit/offset behavior for non-summary views.

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 is a noun-phrase fragment, "Corpus coverage/rights/clocks," and does not state a clear operation or what an agent should expect back. It is not pure tautology, but it is too vague to confidently distinguish the tool 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?

It hints that summary views do not paginate and mentions other views, but gives no explicit when-to-use guidance, prerequisites, or alternatives among the many sibling tools. The "Readings: liquidity_tiers" fragment is especially opaque as 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds pagination behavior and mentions unavailable failure cases, plus 'No shared score or authority', but these points are terse and only partially explained.

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 definition is very short and front-loaded with no filler. However, the fragmentary phrasing and undefined terms make it less structurally clear than a concise but complete sentence would be.

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 the description does not explain what 'clocks', 'rights', 'next steps', 'next_offset', or the failure modes mean in the returned data. For a read-only listing tool with important output expectations, this leaves the agent with significant ambiguity.

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 parameters are documented in the input schema. The description's 'Follow next_offset' merely echoes the offset schema description and adds no new meaning for limit or topic, 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?

The description does not state a clear verb or resource; 'Cross-product metadata, clocks, rights, next steps' is an opaque noun list. It gives some output-related concepts but does not distinguish this tool from its many siblings in a usable way.

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 only concrete routing hint is 'Local counts: market_corpus_context', which points to a sibling for one case. It never says when to call research_network versus alternatives, and 'Follow next_offset' is pagination mechanics rather than usage 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 readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds that records were sealed/signed before outcomes and that misses are retained, which is useful context beyond annotations, but it does not explain verification, ordering, or whether the ledger root is intended for external audit.

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?

It is brief and avoids bloat, but the two fragments are cryptic rather than front-loaded and precise. 'Calls sealed/signed before outcomes' reads like internal shorthand and leaves the primary return concept unclear.

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 should carry the burden of explaining what the returned record contains. It lists key fields (hits/misses, decided counts, ledger root) but does not define them or describe the record's structure, completeness, or verification purpose.

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

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

The tool takes zero parameters, so there is no parameter semantics burden and the baseline of 4 applies. The description does not need to explain input arguments.

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 indicates this returns a sealed record of calls made before outcomes, including hits/misses, decided counts, and a ledger root. However, 'Calls sealed/signed before outcomes' is compressed and ambiguous, and it does not distinguish this tool from siblings such as depth_episodes or market_corpus_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?

The only usage-like instruction is 'Report hits and misses together,' which is vague and does not state when to use this tool versus alternatives. There is no exclusion or prerequisite guidance despite many sibling tools that may overlap in domain.

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 read-only, idempotent, closed-world, non-destructive behavior, so the baseline is low. The description adds real value beyond that: it discloses provenance/audit content (PIT source/rights, six venue clocks, startup SHA) and reiterates the live-mode exclusion, telling the agent this is a frozen, license-aware snapshot rather than a live check.

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?

Dense but compact: the scope is front-loaded and the exclusion closes the sentence with no wasted filler. The fragment-list style occasionally hurts readability, but the size is appropriate for a low-complexity read 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 no output schema, the enumeration of hash/PIT/rights/conversion/clock/SHA effectively doubles as a return-value summary, which is helpful. Yet the null-typed venue parameter and the exact meaning of "clearance" are never resolved, leaving gaps for a 6-required-param 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 only 33%, so the description should compensate more than it does. It reinforces the request-hash and exact-rung semantics that the schema already documents, but says nothing about mode, side, instrument, or the puzzling null-typed venue parameter, which the schema leaves unexplained.

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 scope ("exact-rung BTC/USD observe/paper") and enumerates the context elements produced (request hash, PIT source/rights, conversion, bid bands, venue clocks, startup SHA), so the agent can tell roughly what it returns. However "exit context" is jargon and the phrasing is telegraphic, so the actual verb/action is never plainly stated. It does not distinguish itself from siblings like crypto_exit_check or 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?

"No live mode/clearance" provides an explicit when-not constraint, and the observe/paper scope implies when it applies. But no named alternative (crypto_exit_check, exit_cost, unwind_watch) or positive selection criteria are given, so the agent must infer which exit-related sibling to choose.

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 readOnly, idempotent, non-destructive and closed-world behavior, so safety is covered. The description adds only the 'No live execution model' caveat and the free-vs-full split; it does not disclose data freshness, coverage scope, or what 'blind spots' means behaviorally. That is useful but thin context beyond 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?

It is short with no filler, but the structure is three telegraphic fragments rather than a front-loaded statement of action and return. Being terse at the cost of comprehension lands it at minimum-viable rather than strong.

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 is a simple read-only fetch with one optional parameter and no output schema. The description lists contents but never explains the shape of the return or what the headline row contains, leaving an agent to infer meaning from jargon. Adequate but with clear gaps for a tool that will be called blind.

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 itself clearly explains that passing cik returns one filer's full FREE row instead of the all-filer headline. The description adds nothing about the parameter, so the schema does all the work — the correct baseline when coverage is complete.

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 headline outputs ('effective positions, days-to-exit brackets, blind spots') for 'watched filers', which hints at an exit-feasibility screen, but it never states a plain verb/resource and relies on jargon ('watched-filer', 'blind spots'). It distinguishes itself from unwind_stress only by scope ('Full grids'), not by a clear purpose 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?

It points to unwind_stress for full grids, giving one alternative, and notes 'No live execution model', which implies a lighter-weight screen. However, it never says when to choose this over other exit-related siblings such as exit_cost or trade_safety_exit_context, and there are no explicit exclusions.

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 read-only, idempotent, closed-world and non-destructive, so safety is covered. The description adds real behavioral context the annotations do not: output is tiered, with the base response covering BTC and the exit_desk_full tier adding ETH and venue-failure data. That is valuable, but it is delivered as a cryptic fragment with no explanation of what happens to a non-subscriber call.

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

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

Two short fragments with no filler, and the metric list is front-loaded. However, telegraphic phrasing like 'effective/top venue' and 'Subscriber exit_desk_full' is compressed past the point of clarity rather than earning its brevity.

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 carries the burden of explaining return values, and it only lists metric names without format, time window, or ordering. The tier-gating note is a useful addition, but an agent still cannot predict the response shape or confirm whether 'today' (from the title) fixes the lookback window.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies.

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 metrics returned (HHI, effective/top venue, venue depth) and the asset scope (BTC two-sided depth), which tells an agent roughly what the tool computes. But there is no verb and no differentiation from siblings like liquidity_tiers, depth_episodes, or unwind_watch, so the agent must infer that this is a concentration-measurement read rather than tier classification or episode detection.

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 of when to call this tool, when not to, or which sibling to prefer for related questions. The 'Subscriber exit_desk_full' fragment hints at a tier gate but does not tell the agent how to proceed if it lacks that tier.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine method-level caveats — 'deepest-venue blindness', 'concentration', 'dislocations', and the experimental status — which are useful disclosure beyond structured fields. It still says nothing about the timeframe, snapshot freshness, or shape of the result.

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?

It is one short line with no filler, which is good, but it is a comma-spliced jargon list rather than a front-loaded statement of purpose. 'Depth/squared-half-spread weights' and 'deepest-venue blindness' cost the reader more parsing effort than the length saves.

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 parameters and no output schema, the description carries the full burden of explaining what comes back, and it does not — no return shape, no asset granularity beyond BTC/ETH, no timeframe or refresh cadence. For a zero-param analytical tool whose only contract is its output, this leaves the agent guessing.

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 and the schema is closed (additionalProperties: false), so there is no parameter semantics for the description to explain. Baseline 4 applies; the description cannot add parameter value because none exist.

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 assets (BTC/ETH) and the concept (consensus price) plus the weighting methodology, so an agent can infer this reconciles prices across venues. But it is a noun-phrase fragment list with no verb, and the name ('reconciliation') versus the description ('consensus') leave it unclear whether the tool returns a price, a divergence report, or a diagnostic. It also doesn't distinguish itself from siblings like venue_concentration or liquidity_tiers.

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?

'Experimental; no execution authority' is a constraint, not usage guidance — it says what not to do with the output, not when to call the tool. There is no stated trigger, no timeframe, and no pointer to the closely related siblings (venue_concentration, depth_episodes, liquidity_tiers) that an agent would need to choose between.

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