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

Annotations already cover readOnly, idempotent and closed-world, so the safety profile is handled. The description adds genuinely new behavioral context by disclosing what the response contains (identity, entitlement, daily usage, access instructions) and that it acts as the explainer for refused/missing tools — valuable given there is no output schema.

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 tightly packed sentence with the highest-value content (identity/entitlement/usage) front-loaded before the diagnostic clause. No filler, though the telegraphic noun-phrase style slightly reduces readability.

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, annotation-covered tool with no output schema, the description compensates by enumerating the returned fields and the diagnostic role. Missing only an explicit statement of when to invoke it and whether authentication is required.

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, which is the baseline-4 case. There is nothing for the description to disambiguate beyond what the empty schema already conveys.

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 exact payload — identity, entitlement, daily usage, access instructions — which is a specific and distinguishable purpose for a meta/introspection tool sitting among market-data siblings. It lacks a verb (all noun phrases), but the resource is unambiguous and no sibling overlaps it.

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

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

'Explains missing/refused subscriber tools' implies when this is useful — as a diagnostic after another tool is denied or absent — but it never states that explicitly, nor says whether to call it first, or that it is the only tool that works without subscriber entitlement. Usage is inferable, not 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?

With readOnlyHint/idempotentHint already declaring a safe, repeatable read, the description earns extra credit by disclosing what the output deliberately omits: stale/future, uncovered and unconverted venues are withheld, and fees/trade clearance are out of scope. That is real behavioral context about result filtering rather than a restatement of 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 tight clauses with the core comparison action front-loaded and no filler. Dense jargon ('rung/bracket') costs a little clarity without adding length.

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 comparison tool with annotations, it covers the scope and exclusions well. Without an output schema it should still say what the comparison returns (spread, venue list, failure reasons), and it never explains rung/bracket, leaving the agent partially equipped.

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 the parameter burden. It loosely hints at max_age_seconds via 'withholds stale/future' and at sizes_usd via 'four BTC sell sizes', but the schema permits 1-4 sizes, contradicting the word 'four', and no units, format, or meaning of rung/bracket is given.

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

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

States a specific verb (compare) and resource (BTC sell sizes by rung/bracket), which is more than a restatement of the name. It does not, however, distinguish itself from the closely named sibling exit_cost, so the agent must infer the boundary.

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

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

No explicit when-to-use, prerequisites, or named alternative. The caveats 'fees excluded; no trade clearance' faintly imply that a fee-inclusive or trade-clearing analysis belongs elsewhere, but the agent is never routed to exit_cost or told which conditions select this tool.

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

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint=false, so the safe-pure-function profile is established. The description adds the modeling assumption ('constant-rate scenario, not forecast'), which is genuine value, but the funding sign convention it states duplicates the schema's parameter description, so the incremental disclosure is modest.

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

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

Two short sentences, front-loaded with the computed outputs before the assumption caveat. No filler, though the telegraphic style ('Caller-input perpetual funding, fees, net carry and linear break-even') reads as a fragment rather than a sentence.

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 while the description names the outputs (net carry, break-even) it never explains their shape, units, or sign conventions. For a calculator with 5 inputs at 20% schema coverage, a caller still lacks enough to interpret the result with confidence.

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% — only rate_bps_per_settlement is documented — so the description carries an extra burden. It loosely maps to some inputs (funding/rate, round-trip fees) and clarifies side via the sign convention, but notional_usd, settlements, and the fee default/units are left unaddressed.

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 concrete computed quantities (perpetual funding, fees, net carry, linear break-even), which is specific enough to distinguish it from siblings like exit_cost or crypto_portfolio_stress. It lacks an explicit verb ('calculate' only lives in the title) and the phrase 'Caller-input' is jargon, but the resource and scope are unambiguous.

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' and 'Caller-input' imply when the tool applies (you supply the rate; no live-data fetch, no forecasting), which is a usable boundary. However, no alternative sibling is named and there is no explicit when-not-to-use statement or prerequisite list, so routing relies on 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 readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safe deterministic nature is covered. The description adds useful behavioral boundaries beyond the annotations: 'Symbols are scenario labels' and 'No liquidation/probability model', clarifying what the tool does not compute. However, it says nothing about output shape, precision, or error behavior for a tool with no output schema.

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 very short sentences with no waste, front-loading the core mechanism and following with scope and exclusions. It is perhaps too terse for the parameter burden, but structure is 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 tool with 2 required parameters, a nested positions array with 6 fields, and 0% schema coverage, the description is far too thin. An agent would not know how equity_usd interacts with positions, how cost_usd affects P&L, whether price_change_pct is per-asset, or what the response contains, and no output schema fills these gaps.

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

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

Schema coverage is 0% and the description adds almost nothing about the two parameters. It notes '20 exposures' (matching positions.maxItems) and 'Symbols are scenario labels', implying price_change_pct semantics and that asset is a label, but it never explains equity_usd, side, notional_usd, venue, cost_usd, or the units of price_change_pct. With zero schema descriptions, the description should compensate and largely does not.

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 action (caller-input linear shocks) applied to a crypto portfolio with explicit scope (20 exposures) and listed outputs (P&L, equity, asset/venue concentration). Distinguishes itself from siblings like venue_concentration and exit_cost by being a multi-exposure shock simulator, though it does not name alternatives 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?

Implies usage by naming inputs (caller-input shocks, symbols as scenario labels) and outputs, so an agent can infer when this is the right tool, but it never explicitly says when to use this versus exit_cost, venue_concentration, or crypto_exit_check. The disclaimer 'No liquidation/probability model' rules out one use case but does not route to 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 cover read-only, idempotent and closed-world, so the bar is lower. The description adds genuinely useful behavioral context: results follow preregistered (non-arbitrary) rules, zero readings must not be read as missing data, and coverage is subscription-gated (exit_desk_full extends it to ETH). That gives the agent data-interpretation and scoping knowledge not present in 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?

Three short, front-loaded sentences with no filler. It is efficient, though the telegraphic phrasing ('under preregistered rules', 'Subscriber exit_desk_full adds ETH') pushes toward under-specification rather than clean concision.

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 conveying the return content, and it only gestures at it via onset/trough/recovery and the zero-vs-missing rule; the shape and meaning of each episode are unspecified. Subscription-tier scoping is disclosed, but an agent still lacks enough to interpret the response 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?

The tool takes zero parameters, which per the rubric sets a baseline of 4. The schema is empty and the description correctly introduces no parameter concepts, so nothing is missing or contradicted.

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 title and description name the resource clearly – realized BTC depth-collapse episodes decomposed into onset, trough and recovery – which no sibling covers. However it is a bare noun phrase with no verb (list/measure/compute), so the agent must infer whether this returns stored episodes or calculates them. Specific but not fully self-declaring.

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 versus siblings like crypto_exit_check or unwind_watch, nor any precondition for calling it. 'Preregistered rules' hints at a fixed methodology but does not say when an agent should reach for this tool over the 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 cover read-only/idempotent safety, and the description adds behavior beyond them: fees are excluded, the result is not executable (an estimate only), and values are interpolated from published rungs. These are exactly the caveats an agent needs before treating the number as actionable.

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 clauses, zero filler, with the operative constraint (fees excluded, not executable) placed before the sibling pointer. Front-loaded and efficient despite the compressed style.

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

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

For a one-parameter estimator with no output schema, the description conveys what is returned (an exit-cost estimate), its units context (USD size in), and its limitations. It stops short of describing the returned field's shape or units, which is the only remaining gap.

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

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

Schema coverage is 100% and the single parameter already documents the $1,000-$1,000,000 rung range and nearest-rung snapping. The description's 'nearest-rung' and 'interpolated' wording reinforces but does not extend 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 concrete verb+resource: BTC sell-side exit cost estimates using interpolated bid-depth bands. It names the sibling crypto_exit_check, which sharpens the boundary, though the telegraphic phrasing ('BTC nearest-rung sell estimates') takes a moment to parse.

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 at crypto_exit_check as the alternative 'compares sizes/freshness,' implying this tool is for a single-size estimate, but never states the selection condition explicitly or when not to use it. Usage is inferable rather than 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, idempotentHint and openWorldHint=false consistent with a calculator. The description adds real value: it discloses what the tool returns ('arithmetic and withheld-cash reasons') and reasserts 'no fetch, storage, execution or verified balance', plus a behavioral requirement to 'Use aware ISO clocks'.

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?

Purpose is front-loaded in the first sentence and the rest is dense with unit/format facts. No filler, though the telegraphic style demands careful reading.

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 computation with no output schema and 0% schema descriptions, the definition covers the arithmetic inputs and return nature but omits the meaning of the boolean/gating parameters that determine when cash is withheld. An agent can call it but may not understand how cleared/pledged/access_restricted affect 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 0%, so the description must carry the load. It supplies units and meaning for most inputs (kg, fineness range (0,1], USD/troy-oz bid, USD fees, FX with USD=1, ISO clocks), which is genuinely useful. But it leaves fx_fee_bps, cleared, access_restricted, pledged and max_quote_age_seconds undocumented, and those drive the 'withheld-cash' gating the tool advertises.

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

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

States a specific verb and resource: 'Calculate gold sale proceeds and cash gates from caller inputs.' The telemetry (pure arithmetic, no fetch) implicitly separates it from sibling tools like crypto_exit_check or venue_price_reconciliation, though no sibling is named.

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?

Boundaries are stated in the negative ('no fetch, storage, execution or verified balance'), which tells the agent this is a pure calculator rather than a data-retrieval or execution tool. However, no positive when-to-use condition or alternative sibling is named for routing.

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

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

Annotations already declare readOnly, idempotent, and closed-world, so the safety profile is covered. The description adds genuinely new behavior: no arguments, errors on missing text or failed quality receipt, and "no generated prose," which tells the agent the content is verbatim published material rather than synthesized output.

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 with the core action front-loaded, followed by input/error behavior and the sibling pointer. No filler or repetition 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 output schema, the description carries the return-value burden and does so by listing title, full text, URL, clock, and quality receipt, plus failure modes. It stops just short of describing receipt format or freshness semantics, but an agent has enough to 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, so the schema needs no elaboration and the baseline is 4. The description's "No arguments" is consistent with the empty schema and confirms the tool takes no input.

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

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

States a specific verb and resource ("Read the latest published editorial") and enumerates the returned fields, so the agent knows exactly what it gets. It also names the sibling it is not ("Use liquidity_tiers for board data"), cleanly separating it from the finance-oriented tools in the sibling list.

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?

Provides a clear selection rule by routing board-data needs to liquidity_tiers, and "No arguments" tells the agent there is nothing to configure. It stops short of stating when this tool itself is the right choice (e.g., only for editorials, once per publish cycle), so it falls short of full when/when-not coverage.

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 (readOnlyHint, idempotentHint, closed world), so the bar is lower. The description adds real value beyond that by defining the PARTIAL status semantics ('missing history or unpassed replay, never calm'), which is non-obvious domain behavior an agent could easily misread.

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 very short, which is appropriate, but the first sentence is a verbless noun fragment that sacrifices clarity for compression. The status-definition sentence that follows is the strongest part and is well placed, though the overall structure is not front-loaded around what the tool 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?

With no output schema, the description carries the burden of explaining return content. It names the major components (tiers, funding, counts, reasons) and clarifies the PARTIAL value, but never explains what the tiers measure or why an agent would need the board, leaving the picture partial for a zero-param reporting 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 takes zero parameters, so there is nothing for the description to disambiguate. Baseline for a no-param tool 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 enumerates what the tool surfaces ('nine segment tiers, Seiche funding, measure counts and replay/withholding reasons'), which gives a rough sense of scope, but never states a verb or a clear action (return? compute? assemble?). It also does nothing to distinguish itself from siblings like depth_episodes or unwind_watch that plausibly touch similar liquidity concepts.

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, what conditions make it appropriate, or what sibling to use instead. The only conditional guidance is about interpreting a PARTIAL result, not about selecting the tool.

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

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

The description usefully explains that summary takes no pagination while other views return records/total/next_offset, which annotations do not cover. It adds conceptual caveats (retrieval age vs observation freshness) but omits details like whether results are cached or the difference between views. Annotations already declare readOnly/idempotent/openWorld, so the bar is somewhat lower, but the extra context is thin.

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

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

Three short sentences, front-loaded with the resource and immediately followed by the pagination contrast and a sibling pointer. Dense but no wasted filler; could be slightly clearer about what 'corpus coverage, rights and clocks' means.

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, idempotent listing tool with an enum parameter and no output schema, the description is incomplete: it names the views only indirectly, provides no per-view semantics beyond pagination, no guidance on limit/offset behavior, and no return shape for other views. The core operational knowledge an agent needs 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?

With 0% schema description coverage, the description should explain the three parameters. It only alludes to pagination via 'summary takes no pagination' and says nothing about the view enum values (summary/datasets/flows/exports), the limit/offset bounds, or defaults. A user or agent lacks guidance on what each view returns.

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 telegraphic phrase ('Inspect corpus coverage, rights and clocks') that gestures at a specific resource but does not cleanly state what the tool actually does or that it returns a paginated listing of corpus metadata. It also fails to differentiate the tool from its many siblings beyond the single mention of 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?

Offers a targeted recommendation to use liquidity_tiers for market readings, giving a concrete when-to-use-else guidance. It does not, however, describe when to pick this tool versus other corpus/system-status siblings or when each view should be selected, leaving gaps.

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 and non-open-world behavior, so the safety profile is covered. The description adds pagination behavior and an error signal ('unavailable flags retrieval, contract or size failure'), which is genuine value beyond annotations, but the phrasing is cryptic and omits what partial failures return.

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, no padding, and the core capability is front-loaded. The telegraphic, article-dropped style ('unavailable flags retrieval, contract or size failure') sacrifices parseability for brevity, so it is compact but not clean.

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 annotations present, 100% schema coverage and no output schema, the structured fields carry most of the load. The description supplies pagination and failure semantics but never explains the shape or meaning of the returned cross-product metadata, leaving the tool's actual contract under-specified.

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

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

Schema description coverage is 100% and all three parameters (limit, topic, offset) are documented in the schema, including the enum constraint and max of 25. The description adds no parameter detail beyond echoing offset progression, 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 verb 'Find' plus the resource ('cross-product source metadata, clocks, rights and next steps') gives a rough idea, but the domain language is opaque enough that an agent cannot confidently say what this tool returns. It does partially differentiate itself by naming the sibling market_corpus_context for local corpus counts.

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?

One explicit routing rule is given ('Use market_corpus_context for local corpus counts') and pagination guidance ('Follow next_offset'), which is more than nothing. However, there is no statement of when this tool itself is the right choice, nor any exclusions against the other 14 siblings.

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, and openWorldHint=false, so the safety profile is covered. With no output schema, the description's enumeration of returned fields (hits, misses, decided counts, ledger root) is genuinely useful added context, but it says nothing about scope, freshness, or whether the record is per-account or global.

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

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

Two short sentences with no filler, and the content fields are front-loaded. The wording is dense to the point of being cryptic ('Forward calls sealed/signed before outcomes'), which costs a little clarity but not length.

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-param read tool with no output schema, the description partially compensates by naming the returned fields. However, it leaves unresolved what a 'forward call' is, the scope of the ledger root, and when the sealed snapshot is valid, which an agent needs in order to use the 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 tool takes zero parameters, so the baseline is 4. The description has no parameters to explain and correctly does not fabricate any.

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 (a sealed record of forward calls signed before outcomes) and its contents (hits, misses, decided counts, ledger root), but the phrasing 'Forward calls sealed/signed before outcomes' is a fragment with no clean verb+object, so an agent cannot state in one sentence what the tool returns. It is distinguishable from the finance-oriented siblings, but only vaguely.

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 directive is 'Report hits and misses together,' which is an output-presentation note rather than a when-to-use rule. No alternative tool is named, no precondition (e.g., after sealing, before settlement) is given, and no exclusion is 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 declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety and idempotency are covered. The description adds the meaningful constraint that there is no live mode or clearance, plus an inventory of returned data, but says nothing about auth requirements, rate limits, or failure behavior.

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

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

A single dense sentence, front-loaded with the tool's scope before the payload inventory. It is a fragment rather than prose, but every clause carries information and there is no filler.

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

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

With six required parameters, no output schema, and low schema coverage, the description needs to carry more weight than it does. Listing return contents is helpful, but the absence of any parameter or invocation guidance for a strictly-typed request object leaves the definition incomplete.

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 33% (two of six parameters documented), so the description should compensate. It obliquely maps 'request hash' to request_hash and 'exact-rung' to requested_size_usd, but mode, instrument, side, and venue are entirely unaddressed, leaving half the contract 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?

The description names a specific scope (BTC/USD observe/paper, exact-rung, PIT-bound) and enumerates the returned context, so an agent can tell it is a read-only context-fetch tool. It does not, however, explicitly differentiate itself from siblings like exit_cost, crypto_exit_check, or unwind_watch, which also sound exit-related.

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

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

The clause 'No live mode or clearance' is a useful negative constraint that rules out live execution, implying usage is limited to observe/paper scenarios. However, no alternative tool is named and there is no positive 'use this when...' guidance, so usage is only implied.

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

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

Annotations already declare readOnly/idempotent/no open world, and the description adds value beyond them: it discloses that it is headline-only, has 'blind spots', and carries no live execution model. That tells the agent what it cannot rely on, though it doesn't cover freshness or pagination.

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

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

Three short fragments, front-loaded with the resource and its outputs, and the alternative is stated last. It is efficient, though the telegraphic jargon ('effective positions', 'days-to-exit brackets') trades some clarity for 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?

There is no output schema, and the description compensates by naming the fields returned. Combined with the disclosed blind-spot and no-execution-model caveats, an agent has enough to call it correctly, though return format details remain unstated.

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

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

With a single parameter at 100% schema description coverage, the schema fully documents the optional cik filter and the all-filer default. The description adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

The description names the resource (watched-filer headlines) and enumerates the payload (effective positions, days-to-exit brackets, blind spots), which lets an agent distinguish it from unwind_stress. It lacks an explicit verb, but the name 'unwind_watch' plus the field list makes the function inferable.

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

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

It states a scope limitation ('No live execution model') and points to an alternative ('unwind_stress has full scenario grids'), implying this is the lightweight/headline tier. There is no explicit 'use this when' clause, so it falls short of full when/when-not 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, idempotentHint and a closed world, so the safety profile is covered. The description adds genuinely non-structured behavior: the output is BTC-only and two-sided, and subscriber tier changes both coverage (ETH) and content (venue failure). It does not state freshness or timeframe, which the title ('today') hints at but the description omits.

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, front-loaded sentences with no filler — the metric list leads and the tier caveat follows. The dense jargon ('effective/top venue', 'exit_desk_full') is compact but requires domain familiarity to parse.

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, single-purpose metric tool with no output schema, the description names the returned measures and the tier-gated extension, which is close to sufficient. It stops short of describing the metric units/definitions or the evaluation window, so an agent cannot fully predict the response shape.

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 schema semantics carry no burden and the baseline is 4. The description reinforces the fixed scope ('BTC two-sided depth'), implying no filtering arguments are expected.

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 metric set: 'BTC two-sided depth: HHI, effective/top venue and venue depth', which tells an agent exactly what is computed. It does not name or contrast any sibling (e.g. liquidity_tiers or venue_price_reconciliation), so differentiation is left to inference.

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

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

The second sentence implies a usage condition — the exit_desk_full subscription unlocks ETH and venue-failure data — but there is no explicit when-to-use or when-not-to-use guidance versus the many other liquidity/venue siblings. The tier note is a helpful access precondition rather than selection 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 this a safe, idempotent, closed-world read, so the safety profile is covered. The description does add real value beyond that by flagging the tool as 'Experimental' and stating it holds 'no execution authority', and the 'deepest-venue blindness' phrase hints at a known bias. What is missing is what the consensus actually returns or how disagreement is surfaced.

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

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

One dense sentence plus a caveat clause, with the subject (BTC/ETH consensus) front-loaded and nothing padded. It loses a point because 'deepest-venue blindness' is too compressed to decode without domain background, so brevity tips into opacity.

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-argument, read-only calculation the description is nearly sufficient, and the listed terms (concentration, dislocations) hint at what the output may contain. But there is no output schema, and the description never states the return shape or that a consensus price is the primary output, leaving that to inference.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the schema is trivially complete at 100% coverage. The baseline of 4 applies for a no-parameter tool.

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 fragment 'BTC/ETH consensus' names the resource, and the title 'Consensus price when venues disagree' clarifies it is a cross-venue price aggregation. However, the description itself is a verbless keyword list ('depth/squared-half-spread weights, deepest-venue blindness, concentration, dislocations') rather than a stated function, and it never distinguishes itself from the sibling venue_concentration, whose concept it also lists as a component.

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 closing phrase 'Experimental; no execution authority' tells the agent not to rely on this for trade execution, which is a genuine usage caveat. But it names no alternative tool and gives no positive condition for when to reach for this over venue_concentration, liquidity_tiers, or depth_episodes.

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