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

With no annotations, the description carries the full behavioral burden. It discloses that data comes from an external venue REST API and is written into the lake, but it omits important traits such as auth requirements, rate limits, idempotency, overwrite/append semantics, and failure handling.

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 single sentence is front-loaded and free of filler. However, it is arguably too terse for a tool with 11 parameters and no annotations, so it is not appropriately sized for the complexity.

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 no-annotation, no-output-schema tool with 11 parameters and low schema description coverage, the description is far too thin. It gives the high-level purpose but not enough context for an agent to call it correctly or understand its side effects.

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 9%, so the description must compensate for 11 parameters. It adds no meaning for source, channel, symbols, start_ns, end_ns, interval, market, category, inst_type, oi_period, or asset_class beyond what the parameter names weakly imply.

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: fetch a historical range from a venue's REST API into the lake. The direction of data flow is clear, but the description does not differentiate this from sibling tools such as collect, collect-market, or query_market_data.

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

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

The phrase 'historical range' implies backfill usage, but there is no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives like collect for live ingestion, query for lake reads, or replay for replaying recorded data.

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

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

No annotations are provided, so the description carries the full behavioral burden. It states the metrics and one-hour window, but does not explicitly confirm read-only behavior, freshness or latency, units, error behavior, or return format.

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 single sentence is front-loaded and free of filler. Its terseness reflects missing detail rather than wasted prose.

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 annotations, no output schema, and incomplete parameter documentation, the one-line description leaves too much unspecified for reliable invocation. It says what data is returned at a high level but not enough about parameters, behavior, or 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?

Schema description coverage is only 50%, and the description does not mention token_pair or asset_class at all. The schema documents asset_class somewhat, but the description adds no meaning about how the pool identifier is spelled or how asset_class affects the response.

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 clearly: one Base pool, returning price, reserves, and swap volume over the last hour. It is missing an explicit verb and does not distinguish this from siblings such as onchain-price, depth, liquidity-depth, or markets.

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

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

There is no when-to-use guidance, no exclusions, and no explicit alternative named. The 'last hour' scope implies a time window but does not tell the agent when this tool should be selected over the many related market-data 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?

With no annotations, the description carries the whole behavioral burden. It does disclose one genuinely useful trait, the ASOF join onto the nearest prior print, which tells the agent how the two legs are aligned in time. But it says nothing about the return shape, ordering, units, or cost, so the disclosure is partial rather than complete.

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 front-loaded sentence with zero filler, and the join semantics come first. It is arguably too terse for the tool's complexity, but there is no structural waste and no buried information.

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

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

This is a five-parameter tool with no annotations and no output schema, so the description must do the work. It does not say whether the result is a time series or a single value, what the basis unit is, how many rows come back, or what a missing prior print yields. Only the join rule is covered, leaving large gaps for the agent to fill.

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?

Per-property description coverage is low (only asset_class is described inline), so the description needs to compensate. The struct-level prose in the schema does explain that perp_symbol is the derivative leg (a future for equities) and that start_ns/end_ns are a required window, which covers the most error-prone fields. However, the description supplies nothing on the symbol or window parameters itself, and much of the struct prose is design rationale rather than caller-facing meaning.

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

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

The one-liner does say what is being computed: the spread of spot against the perpetual mark. But it never names a verb (compute/derive) or the output form, and it gives no signal for choosing between it and the near-identical sibling names perp-basis and spot-future-basis. An agent sees the resource but must open the schema and guess at the sibling distinction.

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

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

The description contains no when-to-use, no prerequisites, and no alternatives, even though perp-basis, spot-future-basis, and term-structure all overlap heavily. Nothing tells the caller whether this is the right tool or how it differs from those siblings. It is not misleading, but it provides no routing guidance at all.

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

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

No annotations are provided, so the description carries the full behavioral burden. It indicates the return content, but does not state whether the operation is read-only, whether it scans the whole lake, performance implications, or how row counts are computed.

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

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

The description is a single front-loaded sentence with no filler. Every word contributes to stating the tool's output.

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

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

For a simple one-parameter catalog tool, the description names the returned content (channels and row counts). However, with no annotations or output schema, it should say more about read-only behavior, scope, and result shape to be fully complete.

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

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

The single parameter, asset_class, has 100% schema description coverage and an enum, so the schema already documents it fully. The description adds no parameter-level detail beyond the schema, which is the baseline expectation when coverage is high.

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

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

The description clearly states the resource (every channel in the lake) and the included metric (row count). However, it does not differentiate this tool from closely named siblings such as catalog-channels, catalog-stats, or list_data_channels.

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

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

There is no guidance on when to use this tool versus alternatives, nor any exclusions. The description only states what it returns, leaving the agent to infer usage from the name and 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?

No annotations are provided, so the description carries the full disclosure burden and does almost none of it — no statement of read-only safety, cost/scan behavior, or whether the result reflects the on-disk lake or a live feed. The single phrase 'present in the lake' weakly implies a presence filter, which is the only behavioral signal offered.

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, but brevity here is under-specification rather than efficiency: a single noun phrase with no leading verb and no front-loaded scope. Nothing is wasted because almost nothing is said.

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?

A single-parameter tool with no annotations and no output schema needs the description to say what the return looks like (list of strings? sorted?) and what 'channel' means in this domain. Neither is covered, so an agent knows the topic but not the contract.

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

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

The schema fully documents the sole required parameter asset_class with an enum and explicit rationale, so schema coverage is 100% and the baseline of 3 applies. The description adds nothing about the parameter, including nothing about how asset_class changes the answer.

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 'Channel names present in the lake' names the resource but supplies no verb and no scope, so an agent must infer that this returns a list. It does not distinguish the tool from near-duplicate siblings such as catalog-exchanges, catalog-symbols, or list_data_channels.

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

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

There is no when-to-use, when-not-to-use, or alternative named anywhere in the description. With siblings like list_data_channels and catalog covering adjacent ground, an agent has zero basis for choosing between them.

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

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

With no annotations, the description carries the full behavioral burden and discloses almost nothing: not that it is a read-only partition listing, not what an unknown channel yields (the schema, not the description, notes the empty-list ambiguity), not ordering or size of the returned set. Only the trivial fact that results are 'distinct' is conveyed.

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

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

A single short, front-loaded sentence with no filler. It is terse rather than padded; the weakness is under-specification, not verbosity.

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-required-parameter tool with no annotations and no output schema, one fragment of a sentence is not enough: the agent gets no return shape, no empty-result semantics, no mention of asset_class, and no guidance against the near-identical 'list_dates'.

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 description mentions only the channel implicitly ('one channel') and never mentions the required 'asset_class' parameter at all, even though it is mandatory and gates which implementation answers. The schema documents both parameters, but the description actively leaves the agent unaware that a second required argument exists.

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 sentence names a resource (date partitions) and a scope (one channel), but 'catalog-dates' is not clearly distinguished from the sibling 'list_dates' or 'catalog-channels', which read as near-duplicates. An agent cannot tell from the description alone which of these to call.

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, when not to, or what alternatives exist — despite several catalog/list siblings that appear to overlap. Usage must be inferred entirely from the name.

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

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

No annotations are provided, so the description carries the full behavioral burden. It indicates the data reflects on-disk partitions rather than registered connectors, but does not disclose read-only behavior, permissions, return shape, pagination, or any other operational 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?

The description is a single front-loaded sentence with no wasted words. It immediately conveys the core distinction the agent needs.

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

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

For a simple one-parameter catalog listing, the description explains the tool's scope but not what the returned "partitions" contain. With no output schema and no annotations, it should say more about the result shape or whether it returns names, paths, or metadata.

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 only parameter, asset_class, is fully documented in the schema with an enum and explanation. The description adds no parameter-specific meaning, which is acceptable given the high schema coverage baseline.

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

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

The description identifies a specific resource — exchange partitions on disk — and distinguishes it from registered connectors. It lacks an explicit verb like "list" and does not name the exact sibling tool, so it falls short of a 5.

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

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

The phrase "as opposed to registered connectors" implies when this tool is appropriate, but it does not explicitly name alternatives or state when not to use it. Usage is inferable rather than clearly instructed.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only lists output columns. It never states that this is a non-destructive read, whether results are paginated or bounded, how large an unfiltered inventory can be, or what the caller gets when no data exists for a venue.

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

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

A single front-loaded fragment with no filler, but it is under-specified rather than concise — it reads like a field list lifted from a return type rather than a complete tool description.

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?

A filterable catalog query with three parameters, one required, no output schema and no annotations needs the description to explain filters, scope and result shape. Listing five columns is not enough to call the tool correctly or distinguish it from catalog-symbols/catalog-scan.

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%, and the one described parameter (asset_class) is documented in the schema, not the tool description. The description says nothing about source, channel, or how required asset_class constrains the answer, so it fails to compensate for the coverage gap.

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

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

"Per-symbol coverage rows: exchange, channel, symbol, timestamps, row count" conveys the shape of the payload but never states a verb or what the tool actually does — list, summarize, inspect coverage? Given siblings like catalog-symbols, catalog-dates, catalog-stats and catalog-summary, an agent cannot tell from this fragment which one to reach for.

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

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

There is no when-to-use guidance, no exclusions, and no reference to any of the many catalog-* siblings that overlap in scope. The agent is left to infer selection from the name alone.

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

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

No annotations are supplied, so the description carries the full behavioral burden, yet it says nothing about read-only semantics, ordering, default row limits, or the `row_limit` ceiling that the schema mentions. 'Stored rows' weakly implies a read, but no operational traits are disclosed.

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, but that brevity is under-specification rather than efficiency: a single fragment with no lead verb and no structured front-loading of the constraints the schema elsewhere argues for. Nothing an agent needs to act is established before the sentence ends.

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

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

For a 6-parameter tool with no annotations, no output schema, and 17% schema coverage, the description is far too thin — it should explain the nanosecond-unit trap, the multi-symbol merge, and the limit ceiling, all of which the schema privately documents but the description never surfaces.

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?

Only 1 of 6 parameters (asset_class) has any schema description, so coverage is 17% and the description must compensate — but it adds nothing about `channel`, `symbols`, `start_ns`/`end_ns`, or `limit` semantics. The rationale text lives in the schema's `$defs`, not in the tool description, so an agent skimming the description learns nothing about parameter meaning.

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

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

The sentence identifies the resource (stored rows), the key dimensions (one channel, multiple symbols, nanosecond time range) and the data it touches, which is more than the bare name provides. But it is a fragment with no verb and doesn't distinguish this scan from the sibling `query` or `catalog` tools, so an agent can't tell why it should pick this one.

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

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

There is no guidance on when to use this tool rather than `query`, `catalog`, `catalog-symbols`, or `catalog-dates`, all of which appear in the sibling list and touch similar data. No preconditions, exclusions, or alternatives are mentioned anywhere.

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

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

No annotations exist, so the description carries the full burden; it discloses one behavioral trait — the deliberate omission of the inventory aggregate, implying a cheaper/lighter query than catalog-inventory. It says nothing about read-only semantics, whether the lake must exist on disk, error behavior, or how channels are identified.

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

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

A single front-loaded clause with no padding; the scope exclusion is attached immediately to the object it qualifies. It is a fragment rather than a sentence, which is efficient but leaves it terse to the point of omitting setup context.

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 annotations, no output schema, and a large family of catalog-* siblings (catalog-summary, catalog-channels, catalog-dates, catalog-inventory), the description does not say what a 'channel' is, how the counts are grouped, or which sibling answers an adjacent question. The critical selection detail is left to the tool name.

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 asset_class enum is already documented with the rationale for being required, so the schema does the heavy lifting. The description adds nothing about how asset_class affects which counts are returned.

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 unit of output (per-channel row counts) plus an explicit scope exclusion (no per-symbol inventory aggregate), which implicitly separates it from catalog-inventory. It stops short of naming the sibling tool, so routing still requires inference from the name.

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

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

The phrase 'without the per-symbol inventory aggregate' implies the when-not condition (don't use this if you need per-symbol inventory), but no sibling is named and no positive trigger ('use when you only need channel-level volume') is given. Usage is implied, 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?

No annotations are provided, so the description must carry the full behavioral burden, but it only describes the return payload in broad terms. It does not state that this is a read-only operation, whether it has side effects, permission requirements, or any other execution behavior.

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

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

The description is a single efficient sentence with no filler. However, its terseness leaves important routing and behavioral information unstated.

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?

In a crowded catalog family with many similarly named siblings and no output schema, the description does not provide enough context to decide when this tool is the right choice. It describes the output superficially but omits differentiation, usage conditions, and behavioral expectations.

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

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

Schema description coverage is 100%, so the lone asset_class parameter is fully documented in the schema. The description adds no parameter semantics beyond that, which is acceptable when the schema does the heavy lifting, yielding the baseline score.

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 returned resources (channels and on-disk exchanges) and says counts are included, but it is a noun phrase rather than a clear verb+resource statement. With siblings like catalog-channels, catalog-exchanges, and catalog-stats present, it does not explicitly distinguish what this summary does that those do not.

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

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

There is no guidance on when to use this tool versus the closely related catalog, catalog-channels, catalog-exchanges, or catalog-stats tools. The agent must infer usage from the name and minimal description alone.

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

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

No annotations are provided, so the description carries the full burden. It only implies a read operation by mentioning 'present in the lake inventory' but discloses nothing about permissions, pagination, return format, or any behavioral constraints. This is a significant gap for a tool with no structured safety hints.

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

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

The description is a single short sentence with no wasted words, which is concise and front-loaded. However, brevity here comes at the cost of under-specification rather than efficient communication.

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

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

Given 3 parameters, no annotations, and no output schema, the description is far too thin. It should at least clarify that the tool is read-only, what it returns (a list of distinct symbols), and how it differs from similar tools like list_symbols or resolve-symbols.

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%, so the description should compensate by explaining parameter meaning. It adds nothing beyond the schema. Although the schema itself contains a detailed $defs description for source and channel, the tool description does not help an agent understand how to use the parameters, especially the required asset_class enum.

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

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

The description states it returns distinct symbols from the lake inventory, which is slightly more than restating the name. However, it lacks a clear verb+resource construction and does not distinguish it from siblings like list_symbols, search_symbols, resolve-symbols, or universe, leaving ambiguity about its specific role.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention conditions, exclusions, or prerequisites, leaving the agent to infer usage from the name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a live read-only snapshot, but does not disclose whether it hits the network, rate limits, caching behavior, or what happens with empty venue lists. For a tool with no annotation coverage, this is a significant gap.

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

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

The description is a single front-loaded sentence with no wasted words. However, the brevity may be excessive given the tool's three parameters and required enum, though structurally it 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?

With no output schema and no annotations, the description should do more to explain the return shape, asset-class behavior, and parameter effects. It names the data categories but omits how to invoke the tool correctly across its required 'asset_class' enum.

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%, and the description does not explain the required 'asset_class' enum or how 'venues' and 'coin_pages' affect the snapshot. It vaguely maps 'coin universe' to coin_pages, but does not compensate for the undocumented parameters.

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

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

The description states a concrete resource and scope: a live whole-market snapshot covering venue market counts, coin universe, and DeFi TVL. This is clearer than the opaque name 'census', but it does not distinguish the tool from overlapping siblings such as 'universe', 'markets', or 'inventory_snapshot'.

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

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

There is no guidance on when to use this tool versus alternatives like 'universe', 'markets', or 'inventory_snapshot'. No prerequisites, exclusions, or selection criteria are given, leaving the agent to infer usage from the name and one-line description.

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

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

With no annotations, the description carries the full burden; it does disclose the bounded [0, 100] output and that the result is a pure function of four supplied readings, which implies a side-effect-free computation. It does not state that the tool is read-only/no-side-effect explicitly, nor that asset_class switches which interpretation the readings take — a material behavioral fact that lives only in the schema text.

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

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

One tight sentence with the output range and input source front-loaded and zero filler. It is arguably undersized for a five-parameter tool with dual asset-class semantics, but nothing in it is wasted.

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

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

For a tool with five required parameters, no output schema, no annotations, and 20% schema coverage, the description omits too much: required asset_class, the equity re-specification of two field names, and any hint of the return shape beyond the [0, 100] range. The nested schema prose covers some of this, but the description itself does not leave an agent fully equipped 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?

Schema description coverage is only 20% (asset_class alone is described at the property level), so the description needed to compensate and does not: it says 'four supplied readings' without naming them, giving units, or flagging that stablecoin_deviation and sequencer_delay are reinterpreted for equities. The rich unit discussion sits in the nested $defs text, not in the tool description, so an agent skimming the description gets no parameter meaning.

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

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

The description names a specific resource (a composite market-stress index) and states its output range [0, 100] and that it derives from four supplied readings, so an agent knows exactly what it computes. It does not differentiate itself from stress-adjacent siblings such as lending-stress, peg-deviation, or sequencer-latency, which is the only thing keeping it below a 5.

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

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

There is no guidance on when to reach for chaos-score versus the many single-signal siblings (lending-stress, peg-deviation, ofi, gas-vol), nor any note that it aggregates those readings into one number. The agent must infer its role as a composite from the one-line description alone.

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

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

With no annotations at all, the description carries the full burden and delivers almost nothing: it does not say whether the call blocks indefinitely, what max_reconnects=-1 implies, whether records are appended vs overwritten in the lake, or that a dead-letter report is produced. Only the vague "write every record" hints at durability semantics.

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 front-loaded sentence with no filler and no repetition — structurally clean. But for a 7-parameter, long-running streaming ingest it is under-specified rather than genuinely concise, so efficiency alone doesn't earn a 4.

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

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

No output schema, no annotations, 7 parameters including a blocking duration and reconnect cap, yet the description is a single clause. An agent can guess this streams data into storage but lacks the termination, failure, and write-target semantics needed 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?

Schema description coverage is 14% and the three required parameters (sources, symbols, channels) are completely undocumented — notably 'channels', which likely maps to the catalog-channels/list_data_channels siblings but is never explained. The tool description adds no parameter meaning; only asset_class has schema text, and the long $defs note is design rationale rather than usage guidance.

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?

"Subscribe to live venues and write every record into the lake" gives a clear verb (subscribe) plus the two resources (live venue streams, the lake). It is a coherent ingest-and-persist statement, but it never disambiguates from the near-identical sibling 'collect-market', nor from 'backfill'/'replay' which also write into the lake.

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 when-to-use, when-not-to-use, or alternative is named despite obvious siblings (collect-market, backfill, replay). An agent has no stated condition for choosing this over them, or for whether it is a blocking/long-running call that needs duration_seconds set.

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

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

No annotations are provided, so the description carries the full burden. "Subscribe" hints at a long-running stream, but nothing is said about that being a blocking/persistent job, how it terminates (duration_seconds), reconnect behavior, rate limits, or the DLQ reporting the parameters imply. The agent is left to infer operationally significant behavior from parameter names.

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

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

A single front-loaded sentence with no filler, but for a 14-parameter long-running subscription tool this is under-specification rather than concision — the brevity is achieved by omitting, not by compressing.

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

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

No annotations, no output schema, 14 parameters at 7% coverage, and a subscription lifecycle to explain — the description is far short of what an agent needs. Partial credit only because the schema's embedded description covers the top/all_symbols rule and the collect relationship.

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 7% across 14 parameters, and the description adds nothing about any of them. The schema's own top-level text explains top/all_symbols mutual exclusivity and asset_class, but kinds, quote, use_ws, book_depth, max_symbols, poll_interval, max_reconnects, dlq_report_path and duration_seconds remain undocumented anywhere.

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?

"Subscribe to a whole slice of a venue's market" gives a verb (subscribe) and a resource, but "slice of a venue's market" is undefined jargon — an agent cannot tell what a "slice" contains without reading the schema's $defs description. It also never names its closest sibling, collect, so the distinction is only discoverable inside the schema.

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

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

There is no guidance on when to use this instead of collect, universe, resolve-symbols, or markets. The one genuinely differentiating fact — that symbols come from the venue's live universe rather than being named by the caller — appears only in the schema description, not here.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Inventory' weakly implies a read operation, but the description does not disclose permissions, response behavior, filtering behavior, error cases, or what a coverage row represents.

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

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

The description is a single front-loaded sentence with no wasted text. It is concise, though its brevity contributes to the larger under-specification problem.

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 four-parameter tool with no annotations, no output schema, and low schema description coverage, this is insufficient. An agent cannot tell what coverage rows are, how source/channel filtering works, or what to expect from the result.

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

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

Schema description coverage is only 25%, so the description needs to compensate. It clarifies that the symbol must be exact and singular, but says nothing about the source or channel filters, nor does it explain how asset_class inference interacts with those filters.

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

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

The description states a resource, 'coverage rows,' and a scope, 'one exact symbol,' but 'inventory coverage' is vague without defining what coverage means or what rows contain. It does not distinguish this tool from nearby catalog/inventory siblings.

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

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

The only usage signal is 'one exact symbol,' which implies exact-match lookup rather than prefix or bulk search. There is no explicit when-to-use guidance, no exclusions, and no named alternatives among the many catalog/list 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?

No annotations are provided, so the description carries the full burden. It only hints at 'real L1 when keyed' without explaining data source, freshness, key requirements, or how as_of_ns/max_age_ns affect 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 front-loaded sentence with no wasted words, but it is too terse and cryptic for a tool with seven parameters and no annotations. It is efficiently short but under-specified.

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

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

Given a 7-parameter financial data tool with no output schema and no annotations, the description is far too sparse. It communicates the broad output concept but omits parameter behavior, return format, and key operational constraints.

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 7 parameters and only 14% schema description coverage, the description must compensate but does not. It explains none of bins, top_n, method, as_of_ns, max_age_ns, or asset_class, and 'reference price' does not clearly map to any parameter.

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

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

Identifies the output as a 'market-depth ladder around a reference price,' which gives a rough sense of the resource. However, 'real L1 when keyed' is opaque and the description does not distinguish this tool from siblings like liquidity-depth or query_market_data.

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

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

No guidance on when to use this tool versus alternatives such as liquidity-depth. The phrase 'real L1 when keyed' hints at a condition but does not state prerequisites or selection criteria.

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

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

No annotations exist, so the description carries the full burden. 'Write ... out to a file' does signal a filesystem mutation, but it says nothing about write permissions, the readonly/_refuse_readonly refusal path, overwrite behavior, or the security hazard of a caller-chosen absolute dest path — all of which live only in the schema's $defs prose, not the tool description.

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

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

A single front-loaded sentence with zero filler or repetition. It is efficient, though the extreme brevity is under-specification rather than deliberate concision given the tool's complexity.

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

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

For an 8-parameter, 5-required filesystem-writing mutation with no annotations, no output schema, and 13% schema coverage, the description omits format options, row limiting, return value, and the critical readonly/trust constraint on dest. An agent could invoke it but not safely or predictably.

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 13% (just asset_class), so the description must compensate. It loosely maps 'channel, symbol set and time range' and 'file' onto channel/symbols/start_ns/end_ns/dest, but leaves fmt, limit, asset_class, and the nanosecond units of the bounds entirely 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 concrete verb (write) and resource (channel, symbol set, time range) with an explicit destination (a file), so an agent can tell this is a bulk data-dump tool rather than a query or catalog lookup. It stops short of naming a sibling (e.g. query/collect) that would sharpen the boundary.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the many data-access siblings (query, query_market_data, collect, backfill). An agent must infer that this is the file-materialization path rather than an in-memory fetch.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says the result is annualised and accumulated, but does not disclose permissions, data source behavior, error conditions, pagination, or return format.

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

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

The description is a single compact sentence with no wasted text and is front-loaded with the core concept. Its brevity is efficient, though the same brevity contributes to gaps covered under other dimensions.

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

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

For a tool with four parameters, no annotations, no output schema, and low schema description coverage, the description is too thin. It does not explain return values, timestamp units, symbol semantics, or how annualisation and accumulation are computed.

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 25%, so the description should compensate but does not. It vaguely implies a position symbol and a time window through “position” and “per-period,” but does not explain the required symbol, start_ns, end_ns, or the asset_class enum.

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

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

The description clearly identifies the resource as per-period financing cost annualised and accumulated, which maps well to a funding APR calculation. It is more specific than a tautology, but it does not distinguish this from siblings such as funding-predict, perp-basis, or basis.

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

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

The description gives no guidance on when to use this tool versus alternatives or when not to use it. It does not mention prerequisites, data availability, or the presence of related funding/basis tools in the sibling set.

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

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

With no annotations and no output schema, the description carries the full burden of behavioral disclosure, yet it only says it forecasts. It does not state the forecasting method, minimum input length, handling of short histories (the default window_size of 5 implies a fallback), failure modes, or whether asset_class changes behavior beyond selecting an implementation.

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

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

A single front-loaded sentence with zero waste. It is appropriately sized, though its brevity is also the source of its under-specification.

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 3-parameter computational tool with no annotations and no output schema, the description should explain input requirements (e.g., how many rates, what window_size does, what asset_class changes). It leaves an agent unable to call the tool confidently beyond the bare minimum.

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%, so the description should compensate, but it adds nothing about window_size or why asset_class is required. The phrase 'supplied rate history' loosely maps to rates, but the meaning of window_size (fallback window) and the crypto/equity choice are left to the schema, which mostly lacks descriptions.

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 (forecast) and resource (next-period funding rate) sourced from a supplied rate history, which is clear enough for an agent to understand what the tool does. However, it gives no differentiation from siblings like funding-apr, basis, or perp-basis, which also deal with funding/rate 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?

The description offers no guidance on when to use this tool versus siblings such as funding-apr (which likely computes a current APR) or basis tools. There are no stated prerequisites, exclusions, or alternative routing.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only computation, what the return shape is, how misalignment or missing data is handled, or whether the result includes p-values or only correlation coefficients. For an analysis tool with no output schema, these omissions matter.

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

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

The description is a single front-loaded sentence with no filler. It is concise, though its brevity borders on under-specification rather than optimal economy. Structurally there is no clutter or burying of the main point.

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 computes correlations from two aligned data series, but the description does not explain the return value, minimum data requirements, or alignment expectations beyond what the schema object description separately states. With no annotations and no output schema, the description is too incomplete for an agent to call the tool confidently without studying the schema closely.

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 description says nothing about the three parameters. Schema description coverage is 33%, with asset_class documented but gas and vol lacking property-level descriptions. The schema's object-level description does explain alignment on local_ts, which partially helps, but the tool description adds no parameter semantics and does not compensate for the low coverage.

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

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

The description names a specific computation: Pearson and Spearman correlation between gas costs and volatility. This is clear enough to distinguish the tool from most siblings such as basis, funding-apr, or vol-skew. It stops short of explicitly naming when this is preferred over a generic correlation tool, but the purpose itself is 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?

The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites such as aligned series, minimum sample size, or the asset_class parameter. An agent must infer the usage context entirely from the name and schema.

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

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

No annotations, so the description carries the full burden, yet it says nothing about whether this is a pure read/compute, how lookback before start_ns is handled, or what `fill_empty` changes. Only the phrase 'over stored OHLCV' hints at the data dependency.

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 short sentence with no filler, but it is under-specified rather than concise: a single fragment cannot front-load the semantics of an 8-parameter 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?

For an 8-parameter tool with no annotations, no output schema, and 13% schema coverage, the description leaves the agent guessing on almost every argument and on the return shape. It is a label, not an operating contract.

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 13% (only asset_class documented), so the description should compensate. It implicitly enumerates the accepted `indicator` values (MA/RSI/MACD/Bollinger) and the default period of 14 matches RSI, but symbol, start_ns/end_ns, interval, fill_empty, and null-indicator behavior are all 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?

States the resource (technical indicators) and names the concrete computations (moving averages, RSI, MACD, Bollinger bands) over stored OHLCV, which is enough to distinguish it from raw data siblings like query_market_data. It is a noun phrase without an explicit verb ('compute'/'calculate'), so the action is only implied.

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 statement of when to use this versus query_market_data, resample, or base-market-data. Nothing tells the agent that stored OHLCV must already exist (i.e., that backfill/collect may be a prerequisite), nor what to do when `indicator` is left null.

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

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

No annotations are provided, so the description carries the full burden. It partially discharges this by disclosing the returned row columns, which substitutes for the missing output schema, and by identifying itself as an alias (so behavior matches catalog-inventory). It says nothing about read-only safety, whether it scans the whole lake, latency, or pagination.

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

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

Two short fragments with no filler; the row-field list is front-loaded and the alias tag follows immediately. It is arguably under-specified rather than merely concise, but nothing is wasted.

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

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

For a 3-parameter catalog tool with no annotations and no output schema, describing the returned columns is the most valuable thing the description could do, and it does that. However, it omits the required asset_class parameter and any usage context, leaving gaps an agent must resolve by opening the schema.

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

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

Schema description coverage is only 33% and the tool description adds no parameter information at all — it never mentions the required asset_class enum (crypto/equity) or the source/channel filters. The $defs block does explain source and channel at length, but that lives in the schema, not the description, and the critical required-parameter constraint is unaddressed here.

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

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

The description names the exact output shape (exchange, channel, symbol, timestamps, row count) and states the resource is a per-symbol coverage inventory. The '(alias of catalog-inventory)' tag is a strong differentiator against the many catalog-* siblings, though the description never uses a verb (list/get/return), so it describes content rather than action.

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 alias note implies the tool is interchangeable with catalog-inventory, which is useful routing information, but it never explicitly says 'identical results, use either' or names a condition that would select one over the other. There is also no guidance on when this is preferable to catalog-symbols, catalog-summary, or data-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?

With no annotations, the description carries the full burden of behavioral disclosure and provides essentially none: nothing about permissions, cost, rate sensitivity, what the 'cross-section' actually contains, or how asset_class changes the answer. It implies a read-only computation but never says so.

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

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

A single front-loaded sentence with no filler or repetition. It is efficient, though the term 'cross-section' is left unexpanded, making the brevity partly under-specification rather than pure 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?

For a 4-parameter tool with no annotations, no output schema, and 50% schema coverage, one sentence is not enough. An agent still lacks sibling differentiation, timestamp semantics, symbol format expectations, and any description of the returned surface structure.

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 50%, and the description itself contributes no parameter meaning at all. The schema explains rate convention and why asset_class is required, but at_ns (timestamp units) and underlying (symbol format) are undocumented in both places, so the description fails to compensate for the gap.

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

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

The description names a specific resource — an implied-volatility cross-section for one underlying at one instant — which is enough for an agent to know what the tool produces. It does not distinguish this from close siblings such as vol-skew or term-structure, leaving the agent to infer that this is the full strike-by-expiry surface rather than a skew or a time slice.

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

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

There is no guidance on when to use this tool versus vol-skew, term-structure, or risk-reversal, all of which sit in the same options family. The only usage-relevant detail ('one underlying at one instant') describes scope but not selection criteria.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says the tool annotates rows but does not disclose whether it mutates inputs or returns new objects, how unmatched rows are handled, or what permissions or side effects apply.

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

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

The description is a single front-loaded sentence with no wasted words. Its brevity is appropriate for the conciseness dimension, even though other dimensions show the definition is under-specified.

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 five parameters, three required, no annotations, and no output schema, the description is far too thin. It omits the required asset_class, the known_only option, and any explanation of what the returned labeled rows look like.

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

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

Schema description coverage is only 20%, so the description needs to compensate, but it only hints at watchlist and min_usd. It says nothing about the required asset_class enum, the shape of transfers, or the known_only flag.

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

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

The description states a specific verb and resource: annotate transfer rows with watchlist labels, with an optional USD filter. It is clear what the tool does, but it does not distinguish itself from any sibling tool such as smart-money or whale-alerts.

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

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

There is no guidance on when to use this tool versus alternatives, and no exclusions or prerequisites are stated. The only conditional language, 'optionally filtered by USD,' describes a parameter rather than a usage 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?

No annotations are provided, so the description carries the full behavioral burden. It doesn't say this is a pure computation (no side effects, no external calls), doesn't state how the haircut applies (to collateral value before threshold?), and doesn't describe the response shape despite there being 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 front-loaded sentence with no filler. It is efficient, though its brevity is a symptom of under-specification rather than disciplined minimalism.

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 five-parameter computation tool with no annotations, no output schema, and 20% schema coverage, the description does far too little. An agent cannot know units for the four required numerics, how the stressed health factor is derived, or what value to expect back.

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% and the description adds zero meaning for any of the five parameters. The verbose schema text argues about required-vs-default arity rather than explaining what collateral_usd, debt_usd, liquidation_threshold, or haircut_pct mean (units, ranges, whether haircut_pct is a percent 0-100 or a fraction). asset_class also raises an unexplained 'symbol' reference with no symbol parameter present.

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 output (health factor of a lending position) plus a stress variant (under a collateral haircut), which an agent can distinguish from general risk siblings like chaos-score or liquidity-depth. It stops short of defining what 'health factor' means numerically or what a haircut applies to.

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

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

The description gives no indication of when to use this versus alternatives such as chaos-score or simulate-price-impact, and no preconditions or exclusions are stated. Usage must be inferred entirely from the one-line purpose.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing: not read-only vs mutating, not latency/cost, not that the crypto path scans stored data from zero to now while the equity path snapshots a live ladder, and not what the response shape looks like. That material behavioral context exists only inside the JSON schema's docstring, which is not where an agent selecting a tool would look.

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 sentence is short and front-loads the metric, but its brevity is under-specification rather than economy: one clause of content stands in for what should be a purpose statement plus return-shape and market notes.

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 annotations and no output schema, the description is the only prose an agent gets, and it omits return format, the crypto-vs-equity behavioral split, symbol format, and asset_class inference. For a two-parameter analytics tool with a non-trivial dual implementation, this is not enough to call correctly 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 50% ('symbol' has no description at all), so the description needed to compensate and does not — it never mentions 'symbol' or 'asset_class', nor that there is deliberately no time-range parameter. The single sentence adds no meaning beyond the schema.

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

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

The description names a specific metric (bid/ask size) and specific depth bands (1, 2, 5 percent of reference price), which tells an agent roughly what is computed. However it never says what the tool returns (a per-band size vector? a snapshot? a sequence-indexed series?) and does not distinguish it from siblings such as 'depth', 'slippage', or 'simulate-price-impact', which plausibly overlap.

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 'depth' or any other liquidity sibling, and no preconditions (which markets are supported, whether the equity path snapshots live data). The agent is left to infer routing from the name alone.

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

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

No annotations are provided, so the description carries the full disclosure burden, yet it says nothing about this being a non-destructive read, whether results reflect the on-disk lake versus a live source, or what happens when a lake has no channels. For a simple list operation the risk is low, but the disclosure is essentially absent.

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, resource stated first, alias qualification second — zero filler. It is arguably slightly too terse, but nothing in it is wasted.

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

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

For a single-parameter list tool with full schema coverage and no output schema, the description covers what is returned (channel names) but omits scope details an agent might need, such as whether the list is asset-class scoped or whether it includes empty/inactive channels.

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

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

Schema description coverage is 100% and the asset_class enum is documented in-schema as required with an explanation of why it cannot be inferred. The description adds nothing beyond that, so the baseline 3 applies.

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

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

States a specific resource ('channel names present in the lake') with a clear verb-less listing intent, and explicitly identifies itself as an alias of catalog-channels, which lets an agent distinguish it from unrelated siblings. It stops short of distinguishing it from near-neighbours like list_dates or list_exchanges except by resource name.

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

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

The alias note implies this tool and catalog-channels are interchangeable, which is useful routing information, but it never states when to prefer one over the other or which lakes/asset classes qualify. Usage is inferred from the resource name rather than spelled out.

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

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

No annotations are provided, so the description carries the full behavioral burden, but it only says what data is returned. It does not mention that both parameters are required, that channel is intentionally not defaulted, the behavior for genuinely empty channels, or any output or pagination characteristics.

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 short sentences and front-loads the resource scope before the alias note. There is no repetition or irrelevant detail.

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 two required parameters, an enum, no annotations, and no output schema, the description is too thin. It omits the asset_class parameter entirely and does not compensate for the partial schema description coverage.

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 description mentions 'one channel' but never mentions the required asset_class parameter or its crypto/equity enum. With only 50% schema description coverage and no behavioral details about valid channel names, the description leaves the agent dependent on the schema to discover a required parameter.

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

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

The description states a specific resource, 'distinct date partitions present for one channel,' and explicitly identifies itself as an alias of catalog-dates. This lets an agent distinguish it from unrelated siblings, though the verb is implied rather than stated and the alias relationship to catalog-dates is the main differentiator.

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 signal is '(alias of catalog-dates),' which implies this tool is interchangeable with catalog-dates. It does not say when to choose one over the other, what prerequisites exist, or what happens if the channel is invalid or empty.

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

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

With no annotations, the description carries the full burden. It discloses that the tool does not touch the data lake or network, which is useful behavioral context for a static registry read, but it omits permissions, return shape, and whether the registry reflects installed connectors versus a remote catalog.

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

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

Two short sentences with the registry description front-loaded. 'No lake, no network' is terse but potentially cryptic, keeping it from a perfect score, yet 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?

For a one-parameter list tool with full schema coverage, the description is close to complete, but the missing sibling differentiation and cryptic 'source connectors' phrasing leave an agent unsure exactly what is returned and how it relates to catalog-exchanges or markets.

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

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

Schema coverage is 100%, so the schema already fully documents the single required asset_class enum. The description adds no parameter-level meaning of its own, so the baseline 3 applies.

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

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

The description says it returns 'registered source connectors this build can collect from,' which conveys a static registry of exchanges. However, it never uses the word 'exchanges,' has no verb, and gives no clue how it differs from siblings like catalog-exchanges, list_exchanges_on_disk, or markets.

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 alternatives. The phrase 'No lake, no network' hints at a lightweight offline read but does not name any sibling or state when-not-to-use; the filtering advice appears only in the schema description, not here.

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

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

No annotations are provided, so the description carries the burden. 'Present on disk' strongly conveys a passive read with no mutation, and the alias disclosure is genuine behavioral context. However, it says nothing about permissions, error behavior when no lake/exchanges exist, or volume of 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?

Two compact clauses with zero filler; the on-disk qualifier is front-loaded and the alias note is parenthetical. Nothing is wasted, though the terseness leaves gaps rather than being optimally informative.

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

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

For a single-parameter, no-annotation, no-output-schema tool, the description identifies what is returned conceptually but never describes the shape of the result (names? partition ranges? counts?) nor how asset_class scopes it. Adequate to select the tool, thin for invoking and interpreting it.

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

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

Schema description coverage is 100% and the single asset_class enum is documented in the schema with its own rationale, so the schema does the heavy lifting. The description adds no meaning about asset_class or how it affects which market's partitions are listed.

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 precisely ('Exchange partitions present on disk') and distinguishes it from a sibling concept ('as opposed to registered connectors'), so an agent can tell it apart from list_exchanges. The verb is only implied by the noun phrase, and the alias note to catalog-exchanges further clarifies identity.

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 contrast with registered connectors implies the selection condition (want on-disk partitions, not configured exchanges), and the alias note tells the agent catalog-exchanges is equivalent. But there is no explicit when-to-use/when-not-to-use statement or named alternative to prefer for the connectors case.

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

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

No annotations are provided, so the description carries the full behavioral burden, but it discloses very little beyond saying symbols are present in the lake inventory. It does not clarify read-only vs mutation behavior, permissions, pagination, ordering, or return characteristics for an inventory-listing operation.

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

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

The description is concise and front-loaded, with no filler. However, for a tool with no annotations, incomplete parameter coverage, and no output schema, this level of brevity leaves important structure and context absent rather than merely concise.

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

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

Given three parameters, one required enum, no annotations, no output schema, and low schema description coverage, the description is too incomplete. It does not explain the asset_class requirement, the shared source/channel filters, or what the agent should expect from the listing result.

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

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

The description adds no meaning about the three parameters, including the required asset_class enum and the optional source/channel filters. With only 33% schema description coverage, the description should compensate for undocumented parameter semantics, especially the shared filter behavior, but it 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?

The description identifies the resource and scope as symbols in the lake inventory, and notes it is an alias of catalog-symbols. However, it does not use a clear verb like 'list' and does not distinguish the tool from several sibling symbol-related tools such as search_symbols, resolve-symbols, universe, or even catalog-symbols when both are present.

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 routing hint is '(alias of catalog-symbols)', which identifies an equivalent tool but gives no guidance on when to use this versus search_symbols, resolve-symbols, universe, or the canonical catalog-symbols name. No exclusions or context for choosing alternatives are provided.

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

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

No annotations, so the description carries the full burden and delivers almost nothing: it does not confirm this is a read-only listing, whether results are cached, whether network calls to exchange APIs occur (relevant for a ccxt-backed tool), or what the cost of calling is. The only real disclosure is that the set is build-dependent ('reachable from this build'), which is genuinely useful but isolated.

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 clause with no padding, so nothing is wasted — but the brevity is under-specification rather than economy. There is no front-loaded verb or scope statement to anchor the 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?

Four parameters, one required enum, no annotations and no output schema — this definition is drastically under-served. An agent cannot tell what a returned 'venue' record looks like or how to combine asset_class with the boolean filters, and the equity half of the enum is only referenced obliquely in the schema text.

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 25%, so only asset_class is documented structurally; the description's 'native connector or ccxt' is the sole hint that ccxt_only and native_only are mutually meaningful filters. The search parameter is never mentioned, and the interaction between the two boolean flags (are they mutually exclusive?) is left entirely 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 phrase 'Every venue reachable from this build' implies an enumeration of markets but supplies no verb (list? fetch data? resolve?) and no statement of what is returned. Siblings like list-exchanges, catalog-exchanges, universe and search make it impossible to tell from the text how this differs; 'venue' is never reconciled with the sibling vocabulary of 'exchanges' or 'symbols'.

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?

'native connector or ccxt' gestures at the ccxt_only/native_only switch but gives no guidance on when to call this versus list-exchanges, catalog-exchanges or universe. There are no exclusions, no prerequisites, and no note on what a caller should do with the result.

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

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

No annotations are provided, so the description carries the full behavioral burden, but it does not disclose read-only/offline behavior, side effects, output format, or limitations. The schema mentions an offline sequence, but the tool description itself does not.

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 single sentence is front-loaded and has no filler, but it is under-specified for a three-parameter analytic tool. It is concise without being sufficiently informative.

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

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

With no output schema, no annotations, and low schema coverage, the one-line description leaves the agent without the return format, parameter structure, or execution semantics needed to invoke the tool 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 only 33%, and the description never mentions any of the three parameters. It does not explain the required trades array structure, the asset_class enum, or what sandwiches_only changes.

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

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

The description states a specific verb ('Flag') and resource ('sandwich-attack legs') with a clear scope ('same-block, same-pool trade sequence'). It is distinct from all listed siblings, though it does not explicitly contrast itself with an alternative tool.

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 sentence defines the input domain but gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. An agent must infer selection from the domain phrase alone.

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

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

With no annotations, the description carries the full disclosure burden, and it only reveals the data dependency (consecutive book snapshots). It says nothing about read-only behavior, whether data must pre-exist/backfill, error behavior for missing snapshots, or asset-class handling (that lives only in the 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 front-loaded clause with zero filler; every word (metric, bin, source) earns its place.

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

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

Overstated. No output schema and no annotations for a multi-param analytical tool; the description omits return shape (per-bin values), units, and required data availability. Incomplete for the tool's complexity.

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?

Five parameters at 20% schema description coverage (only asset_class is documented). The tool description adds no meaning for symbol, start_ns, end_ns, or interval; 'per time bin' faintly gestures at interval but gives no format or default. It does not compensate for the coverage gap as required.

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 microstructure metric (order-flow imbalance) plus its binning ('per time bin') and its input ('consecutive book snapshots'), which is enough to separate it from siblings like indicators, depth, or liquidity-depth. It stops short of stating the output shape, but the purpose itself is 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?

No when-to-use, when-not-to-use, or alternative is mentioned. An agent cannot tell from this sentence whether to reach for ofi versus indicators, depth, or query_market_data when it wants order-book-derived signal.

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

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

With no annotations, the description carries the full behavioral burden. It communicates that the operation is read-only and returns spot price, reserves, and pool address for a Base mainnet AMM pool, but it omits operational details such as freshness, rate limits, error behavior, or authentication requirements.

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

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

The description is a single front-loaded sentence with no filler. Every word contributes to identifying the output fields and the pool scope.

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 no annotations, no output schema, and only 50% schema description coverage, the description is too sparse. It does not explain the required symbol format or the role of asset_class, and gives no usage guidance among many sibling tools.

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 50%, and the symbol parameter has no property description. The description does not clarify the expected symbol format (e.g., token pair or pool identifier) or how asset_class affects the query, leaving meaningful gaps beyond the schema.

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

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

The description clearly states the resource and scope: spot price, reserves, and pool address for one Base mainnet AMM pool. It distinguishes the tool by chain and pool type, though it does not explicitly contrast with siblings like depth, liquidity-depth, or base-market-data.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as liquidity-depth, depth, or base-market-data. The scoping phrase 'one Base mainnet AMM pool' implies context but does not provide usage conditions or 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses forward fill and stored-record sourcing, but omits important context such as time-range defaults, empty-result behavior, asset-class inference, and any access or rate-limit constraints.

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

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

The description is a single tight sentence with no wasted words. The most important traits are front-loaded.

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

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

For a four-parameter analytics tool with no annotations and no output schema, one sentence is not enough. Key operational details like time defaults, symbol-pattern behavior, and asset-class inference are missing from the description.

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 25%, and the tool description adds no meaning about parameters. The start_ns and end_ns semantics are undocumented in both places, while symbols and asset_class are explained only inside the schema rather than in the 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?

The description clearly identifies the resource as open interest aligned across venues, with forward fill, from stored records. It lacks an explicit verb and does not distinguish itself from nearby sibling tools such as basis, perp-basis, or funding tools.

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

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

There is no guidance on when to use this tool versus alternatives, nor any when-not-to-use conditions. Sibling tools like basis, perp-basis, or funding-apr are not referenced, leaving the agent to infer selection criteria.

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

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

No annotations, so the description carries the full burden, and it says nothing about what is returned (deviation value? flag against threshold?), whether it errors on unknown symbols, or how threshold changes output. The 'neither is an error' nuance appears only in the schema description, not here.

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

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

A single short sentence, front-loaded with the purpose — efficient, but so terse that it omits the mode logic that makes the tool usable. Brevity comes at the cost of specification here.

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?

7 optional parameters, no annotations, no output schema, and low schema coverage: the description would need to explain mode selection, default target/threshold semantics, and expected output for the agent to call it reliably. It does not.

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 14% (just asset_class), so the description should compensate for 7 parameters, yet it mentions neither target nor threshold, and only gestures at price/bid/ask and symbol. The valuable mode arithmetic is buried in $defs rather than the tool 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?

States a specific resource (stablecoin deviation from peg) and sketches two input modes ('one mid price' vs 'from the lake'). It is distinguishable from sibling tools like basis or spot-future-basis, though 'the lake' is internal jargon an agent may not decode.

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

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

No guidance on when to pick this over alternatives (e.g. basis, onchain-price) or which mode to choose; the mode-selection logic lives only inside the schema's $defs text, not the description. The agent must open the schema to learn that a derivable mid means pure mode, a symbol means lake mode.

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

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

No annotations exist, so the description carries the full disclosure burden. 'per update' hints at tick-level, high-cardinality output, which is useful, but nothing is said about read-only nature, data availability, symbol-class behavior, or result volume — the equity-vs-crypto computation split lives only in the schema text, not the description.

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

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

A single, tightly packed sentence with zero filler and the core metric front-loaded. It is a noun fragment rather than a complete statement, but nothing is padded or 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 four-parameter time-series tool with no annotations, no output schema, and only 25% schema coverage, the one-line description is far too thin. An agent cannot learn the timestamp units, the meaning of the asset_class inference, or the output shape from what is provided.

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 25% (only asset_class is annotated). The description's 'from one symbol' usefully clarifies that symbol takes a single value rather than a list, but start_ns and end_ns are left entirely unexplained in both schema and description, including that they are nanosecond epochs.

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 phrase 'derivative price against its index price' identifies the metric (perp mark vs index basis) and 'from one symbol' pins the input shape, so the resource is recognizable. However there is no verb (compute/return) and no differentiation from close siblings like 'basis' or 'spot-future-basis', which an agent must disambiguate by name alone.

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

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

The description gives no when-to-use guidance, no exclusions, and never names an alternative. With 'basis' and 'spot-future-basis' in the sibling list, the agent gets no signal about which of the three basis tools to pick.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies read-only access to views, but does not disclose safety constraints, row limits, permissions, error behavior, or whether non-read SQL is rejected.

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

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

The description is a single front-loaded sentence with no wasted words. It is efficiently concise, though the terseness contributes to the missing detail elsewhere.

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 generic SQL query tool with no annotations, no output schema, and only partial parameter documentation, the description is too thin. It does not explain available views, result shape, row limits, or how asset_class affects the queried catalog.

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 50%. The description itself says nothing about the two required parameters. The schema documents asset_class through its enum description, but sql receives no description, and the long QueryParams text discusses omitted limit behavior rather than how to form valid SQL.

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

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

The description states a specific verb and resource: execute DuckDB SQL against the lake's channel views. It is clear what the tool does, but it does not differentiate from the sibling query_market_data or explain the role of asset_class.

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

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

There is no guidance on when to use this tool versus alternatives such as query_market_data, catalog-scan, or search. The description gives no prerequisites, exclusions, or context for choosing SQL over purpose-built sibling tools.

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

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

With no annotations, the description carries the full disclosure burden and meets very little of it: it never says the operation is read-only, that results are row-limited, or how failures surface. It also calls itself a plain alias while the schema demands an extra required `asset_class`, so the agent cannot tell how much of `query`'s contract actually carries over.

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 and waste-free in themselves, but the brevity is achieved by omitting what matters rather than by compression. Appropriate length for a well-annotated tool, too thin for one with no annotations and partial schema coverage.

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

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

No annotations, no output schema, and a schema whose own description is a stale internal design note that describes a one-field payload while the surface requires two. For a bare SQL-execution tool the description needs to cover read-only status, row caps, and available views; it covers none of these.

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 50% and the description says nothing about parameters. The `sql` field has no description anywhere, so the only place dialect/scope meaning could be supplied is the description, and it isn't.

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 ("Execute DuckDB SQL against the lake's channel views") and names the sibling it duplicates ("alias of query"), so an agent can locate it relative to `query`. It stops short of 5 because calling it only an alias obscures whether any behavior actually differs.

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?

"alias of query" implies the two are interchangeable but gives no when-to-use / when-not guidance and no prerequisites (e.g. must a channel be collected first?). Nothing tells the agent how to choose between this and `query`, `catalog-scan`, or `search`.

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

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

With no annotations, the description carries the full burden and only discloses the merge and ordering behavior. It says nothing about whether this is a read-only disk scan or a network call, how 'limit' interacts with the merge (per-channel vs global truncation), how ties across channels at identical timestamps are ordered, or whether duplicate records are deduplicated.

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

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

A single front-loaded sentence with no filler, which is structurally sound. However, for a six-parameter tool with required time bounds, that brevity tips into under-specification rather than economy.

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?

Six parameters, four required, no annotations, no output schema, and 17% schema coverage mean the description should explain units, filtering semantics, and result shape. It supplies none of that, so an agent could not confidently construct a call from this definition alone.

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 17%, so the description must compensate, yet it only alludes to 'channels'. It never explains that start_ns/end_ns are nanosecond bounds, what symbols filter relative to channels, or what limit caps. The one documented field (asset_class, inferred from symbol source) is documented in the schema, not the 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?

The description states a concrete verb ('merge'), a resource ('stored channels'), and the shape of the result ('one globally time-ordered record stream'), which tells an agent this is a multi-channel temporal merge rather than a plain fetch. It does not differentiate from plausible siblings like query, query_market_data, or resample, which likely also return time-ordered market data.

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

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

No guidance on when to use this instead of query, query_market_data, resample, or export, all of which operate on similar stored data. There is also no mention of prerequisites such as channel names needing to come from catalog-channels or list_data_channels.

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

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

No annotations are provided, so the description carries the full burden. It implies a read over stored prints but says nothing about what happens with empty buckets (the fill_empty flag is never explained), whether the operation is expensive over long ranges, or what the output looks like.

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

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

A single front-loaded sentence with no waste. Sizing is appropriate for the sentence as written, though it is sparse rather than efficient given the tool's complexity.

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?

Six parameters, 17% schema coverage, no annotations and no output schema — the description does not fill any of those gaps. For a tool whose correctness hinges on time-bound and empty-bucket semantics, this is insufficient.

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 17%, so the description must compensate, but it only covers 'interval'. The required start_ns/end_ns (nanosecond semantics, inclusive/exclusive bounds) and fill_empty behavior go entirely unexplained in both the schema and the 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?

States a specific verb (aggregate) and resource (stored trade prints) producing OHLCV bars at a chosen interval. An agent can tell this is a bar-construction tool, though it never names the sibling it competes with (e.g. query_market_data or indicators) to sharpen the distinction.

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 when-to-use guidance, no prerequisites, no mention of alternatives among the many sibling query/indicator tools. The agent must infer that this is for OHLCV construction rather than raw retrieval.

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

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

With no annotations, the description carries the full burden, yet it says nothing about what happens on ambiguous or unresolvable input, whether channel/asset_class inference occurs, or what a success vs failure response looks like. 'Free-form' hints at fuzzy matching but no failure semantics are disclosed.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though the brevity borders on under-specification given four parameters and no annotations.

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?

Four parameters, no annotations, no output schema, and 75% of parameters undocumented in the schema. For a normalization tool with ambiguity resolution at its core, the description leaves too much unsaid for an agent to call 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 only 25% (only asset_class is documented), so the description must compensate and does not. It never explains that `symbols` is a list of unnormalized strings, what `channel` filters, or what the `ambiguous` enum values (all/error/first) actually do — that explanation lives only in the schema $defs, not the tool 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?

Specific verb ('resolve') and resource ('free-form symbol inputs' -> 'canonical catalog symbols'), so the transformation is clear. However, it offers no differentiation from closely related siblings such as search_symbols, catalog-symbols, or list_symbols, leaving the agent unsure which symbol tool to pick.

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 search_symbols or catalog-symbols, nor any prerequisite or exclusion. The agent must infer that this is the normalization step rather than a search/listing step.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not state whether the operation is read-only, what the return format is, how the risk reversal and butterfly are computed, or any rate/expiry constraints, beyond saying the input is one expiry's skew.

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 single sentence is front-loaded and contains no filler. It is concise, though the brevity leaves important gaps that a more structured description could fill without bloat.

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 six-parameter quantitative tool with no output schema, no annotations, and low schema description coverage, one sentence is not enough. It gives the core purpose but omits usage boundaries, output expectations, and most parameter semantics.

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%, so the description must compensate for undocumented parameters. It mentions target delta and single-expiry skew, but says nothing about rate conventions, underlying, at_ns, expiry_ns, or asset_class, leaving most parameters to the schema alone.

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

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

The description names the specific analytics it produces — risk reversal and butterfly — and the scope of the input, one expiry's skew, at a target delta. It is clear enough to identify the capability, though it does not explicitly contrast itself with sibling tools such as vol-skew or iv-surface.

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

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

There is no explicit guidance on when to use this tool versus alternatives like vol-skew or iv-surface. The phrase 'from one expiry's skew' implies a single-expiry use case, but no exclusions, prerequisites, or alternative routing are 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?

No annotations are provided, so the description carries the full behavioral burden and it delivers only the word 'ranked'. It says nothing about whether the operation is read-only, how the ranking works, what the default result cutoff of 20 does, or how source/channel narrow the search. For a five-parameter tool with zero annotation coverage this is a substantial gap.

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

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

A single front-loaded sentence with no filler, which is structurally sound. The problem is under-specification rather than verbosity — there is room for one or two more sentences that would materially help, so the brevity is not fully earned.

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 five parameters, two required, and no annotations or output schema, the description should do more work. It never mentions that asset_class is mandatory and chooses between crypto and equity implementations, which is the single most likely cause of a failed call. Essential facts an agent needs are absent.

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

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

Schema description coverage is only 20% — only asset_class is documented, while q, limit, source, and channel carry no descriptions. The one-sentence tool description adds nothing about any of these: it does not say q is a free-text symbol fragment, that limit is a ranking cutoff rather than a transport cap, or what source and channel filter on. It does not compensate for the coverage gap.

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

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

The description names a specific verb+resource pair: 'ranked symbol search over the lake inventory'. That is clear enough for an agent to know it queries a local symbol catalog and returns ranked results. It does not, however, distinguish this tool from the sibling 'search_symbols', which reads as nearly the same capability, so it stops short of a 5.

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

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

No guidance on when to use this versus 'search_symbols', 'query', 'catalog-symbols', or 'resolve-symbols', all of which appear in the sibling list. Nothing states prerequisites, such as the required asset_class selection or any need to have data loaded locally. The agent is left to infer everything from the name.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that results are ranked and scoped to the lake inventory, but says nothing about read-only safety, permissions, pagination, error behavior, or return format. For a five-parameter search tool with no annotations, this is a substantial gap.

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

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

The description is two short sentences with no filler, and the core purpose is front-loaded. The alias note is useful but slightly cryptic; overall the structure is efficient rather than bloated.

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

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

For a five-parameter tool with two required parameters, no annotations, and no output schema, the description is far too thin. It does not explain required asset_class, how results are shaped, or how this differs operationally from its many sibling search and catalog tools.

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%, and the description adds no parameter-level meaning. It does not explain q, limit, source, channel, or the required asset_class enum, so an agent must infer almost everything from the schema itself.

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

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

The description states a specific verb and resource: 'Ranked symbol search over the lake inventory.' That is clear enough to tell it is a symbol-search tool and not a data export or market-data query. The parenthetical 'alias of search' further identifies its relationship to the sibling tool, though it does not explain why an agent should choose this alias over search itself.

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 signal is '(alias of search)', which implies equivalence but gives no explicit when-to-use guidance. It does not say whether to prefer this over search, list_symbols, resolve-symbols, or catalog-symbols, nor does it state prerequisites or 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?

No annotations are provided, so the description carries the full burden, and it discloses almost nothing: no read-only nature, no mention that the answer is two summary rows (that fact lives only in the schema docstring), no units, no source semantics. For an unannotated network surface this is a substantial gap.

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

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

A single ten-word sentence is front-loaded and free of padding, so nothing is wasted. But it is terse to the point of under-specification rather than crispness — brevity here costs information rather than saving it.

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 annotations, no output schema, and a partially documented parameter set, the description should carry the load and does not: return shape, units, and the `source` dimension are all missing. An agent knows the topic but not how to call it correctly 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?

The description says nothing about either parameter. With 50% schema coverage, `asset_class` is documented in-schema but `source` (defaulting to `base_onchain`) has no description anywhere, and the description does not compensate for that gap or explain what a source selection means for the returned latency figures.

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?

It names the specific metrics — block production interval and ingestion delay — for an L2 sequencer, which distinguishes it from generic siblings like gas-vol or depth. But it is a bare noun phrase with no verb: an agent cannot tell whether it fetches, computes or streams, nor which sequencer or source the answer covers.

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

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

There is no when-to-use guidance, no prerequisite or exclusion, and no named alternative among the ~50 siblings. An agent must infer from the topic alone that this is the latency surface rather than gas-vol or data-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?

No annotations are supplied, so the description carries the full burden. 'Against the stored book' is a genuine disclosure — the output reflects local book data, not a live venue quote, and presumably no order is transmitted — but nothing states read-only status, staleness risk, permissions, or failure modes when no book is stored. That is thin for an unannotated simulation tool.

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

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

Two sentences, front-loaded with the actual computation and zero preamble or filler. It is tight, though the alias caveat arrives as a trailing parenthetical rather than being integrated into the routing guidance.

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?

Five parameters, no annotations, no output schema, and a nearly undocumenting schema — the description should do more work than two sentences. It never says where the book comes from, how to interpret a stale or missing book, or what shapes the returned price/slippage pair takes.

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%; only `asset_class` has an inline description. `side` never documents its accepted values (buy/sell? bid/ask?), `symbol` format is unspecified, and the rambling `$defs` docstring explains `size_unit`'s history rather than what a caller should pass. The description adds nothing beyond 'for a size', so the coverage gap is not compensated.

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 precisely what the call computes — expected execution price and slippage for a given size against the stored book — which is a specific outcome, not a restatement of the name. The parenthetical '(alias of slippage)' identifies the relationship to a sibling, so an agent can tell it duplicates `slippage` rather than complementing 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?

The alias note implies this and `slippage` are interchangeable, which is useful routing information, but it never says which to prefer, whether there is any difference in cost or output, or when not to use it. Usage is implied rather than directed.

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

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

With no annotations, the description carries full behavioral burden but discloses only that the book is 'stored' — hinting at a local/cached read rather than a live fetch. It does not say whether the call is read-only, what happens when the stored book is empty or stale, or whether an error or null is returned for an unknown symbol.

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

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

A single front-loaded sentence with zero filler, and the part that matters (what is computed) comes first. It is efficient but so compressed that it reads more like a title than a definition.

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 five-parameter analytics tool with no annotations and no output schema, the description omits both the return shape (price plus slippage in what units?) and any guidance on book staleness or asset-class selection. An agent could invoke it but would not know how to read the result relative to its 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 20% (only asset_class is documented in properties), so the description needed to compensate and does not — symbol, side, size, and size_unit are untouched. The phrase 'for a size' gestures at the size parameter but adds no unit, sign, or format semantics beyond the schema's anyOf.

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 computation (expected execution price and slippage) over a specific input (a size) against a specific source (the stored book), which is far more informative than the bare name. It stops short of distinguishing itself from the close sibling simulate-price-impact, so an agent cannot tell from the text alone which of the two to call.

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

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

There is no when-to-use, no when-not-to-use, and no named alternative among the many siblings (simulate-price-impact, depth, liquidity-depth) that plausibly overlap. The agent must infer the division of labor entirely from tool names.

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

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

No annotations exist, so the description carries the full burden, and it discloses almost nothing behavioral: no auth requirements, no note that output is per-address keyed, no disclosure that a single 13F quarter yields no institutional flow, and no hint that equity rows are filings rather than transfers. All that context lives in the schema docstring, not the tool description.

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

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

A single tight sentence with the core noun (net flow/volume/last activity) and data source front-loaded. Nothing is wasted, though the terseness is arguably under-specification rather than true economy.

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?

A three-parameter, three-required structural tool with no annotations and no output schema, spanning two asset classes whose input shapes differ semantically. The one-sentence description is nowhere near enough for an agent to invoke it correctly without reading the schema docstring, and it never mentions 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?

Schema description coverage is only 33%, and the top-level description adds nothing about what shape a transfer row or watchlist entry must take. The critical facts — that a row may be a crypto transfer or a Form 4/13F filing, and that watchlist may be a map, bare list, or nested wrapper — appear only in the schema's own docstring, so the description does not compensate for the coverage gap.

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

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

The description names a concrete computation and its output dimensions ("Net flow, volume and last activity per watched address, from transfers"), so an agent knows this is an aggregation over a transfer/filing set rather than a raw fetch. It doesn't explicitly contrast with lookalike siblings such as label-transfers or whale-alerts, which keeps it off a 5.

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

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

"from transfers" weakly implies you must supply rows and a watchlist, but there is no statement of when to pick this over whale-alerts, label-transfers, or query, and no mention that asset_class is required to disambiguate the two markets. Nothing tells the agent when NOT to use it.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the important conditional behavior that supplying expiry adds annualisation, but it omits whether the tool is read-only, what data must exist, what the return shape is beyond that column, and how errors or missing contracts are handled.

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 a single front-loaded sentence with no filler. The brevity is appropriate structurally, though it leaves the definition under-specified for the tool's complexity.

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 six-parameter tool with no annotations, no output schema, and low schema description coverage, this is too thin. It explains the annualisation trigger but not the required symbols, time range, asset-class selection, or expected output.

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 low at 17%. The description only reflects the expiry/annualisation behavior, which is already explained in the schema, and does not clarify future_symbol, spot_symbol, start_ns, end_ns, or asset_class semantics.

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

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

The sentence identifies the calculation as a spot-vs-future basis and notes that results are annualised when a contract expiry is supplied. That is specific enough to understand the resource, but it does not explicitly distinguish this from nearby tools such as basis, perp-basis, or term-structure.

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

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

There is no guidance on when to use this tool instead of sibling basis tools, no exclusions, and no prerequisites such as required symbol availability or date-range constraints. The implied use case is spot-future basis, but an agent receives no routing help.

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

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

With no annotations, the description carries the full burden, and it does disclose that the result is a point-in-time snapshot of ATM IV by expiry, which is real behavioral information. However, it says nothing about what happens when an expiry series is missing, what permissions or data availability is required, or how large the response may be.

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

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

A single front-loaded sentence with no filler; nothing is wasted. It is efficient, though its brevity is partly the source of the specification gaps noted elsewhere.

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 4-parameter, 3-required tool with no annotations, no output schema, and two undocumented required parameters, one sentence is not enough. The agent gets no sense of the return shape (expiries, IV values, units) or of the required timestamp and symbol semantics.

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 50%: `rate` and `asset_class` are well documented in the schema, but `at_ns` (a required timestamp) and `underlying` (required) are bare. The description mentions neither parameter nor explains the timestamp semantics, so it does not compensate for the gap.

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

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

States a specific resource (ATM implied volatility per expiry) and a scope (one underlying, one instant). It is clear what data comes back, but it never names its obvious sibling iv-surface, so the agent must infer that term-structure is the ATM slice rather than the full surface.

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 pick this over iv-surface, vol-skew, or risk-reversal. The phrase 'at one instant' faintly implies a snapshot rather than a time series, but nothing tells the agent when this tool is the right choice or what prerequisites it has.

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

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

No annotations exist, so the description carries the full burden and delivers almost nothing behavioral. It doesn't say whether this hits the network, whether results are cached or paginated, how large the returned set can be, or what permissions are needed. Only the scope ('whole set for one venue') is disclosed.

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 well-formed sentence with no filler and the scope front-loaded. It is efficient, though arguably too terse given six parameters and almost no schema documentation.

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 6 parameters, 2 required, 17% schema coverage, no annotations, and no output schema, one sentence is far from enough. Ordering, result shape, and the interaction between `top`, `limit`, and `kinds` are all left unaddressed.

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 17% across 6 parameters, so the description needed to compensate and largely doesn't. 'Volume-rank' weakly maps to the undocumented `top`, and 'one venue' maps to `source`, but `kinds`, `limit`, and `quote` are unexplained in both places.

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?

Specific verb pair ('Enumerate or volume-rank') plus a precise resource and scope ('one venue's whole tradable instrument set') tells an agent exactly what comes back. It stops short of differentiating from near-siblings like list_symbols, catalog-symbols, or search_symbols, so an agent still has to guess which of those to pick.

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 when-to-use or when-not guidance and no alternative is named. The 'one venue' phrasing implies it isn't a cross-venue tool, but that constraint is inferred rather than stated, and nothing explains when to enumerate versus volume-rank.

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

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

With no annotations provided, the description carries the full burden and discloses almost nothing: no permissions or auth requirements, no mutation/read profile, no rate limits, no return shape (e.g., strikes included, greeks fields). It states the output concept but not how the tool behaves.

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

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

A single, front-loaded sentence with no filler; the resource and scope are stated immediately. It is appropriately terse, though the terseness also reflects missing detail rather than disciplined economy.

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 five-parameter tool with no annotations and no output schema, the description is too thin. An agent is left without return-format expectations, usage routing, or explanation of the three undocumented required parameters.

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 40%; rate and asset_class are documented in the schema, but underlying, expiry_ns, and at_ns have no descriptions anywhere. The tool description adds no parameter meaning, so it fails to compensate for the coverage gap on three required 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 names a specific analytical output (per-strike implied volatility and delta) scoped to a single option expiry, so an agent can tell what it returns. It does not contrast itself with closely related siblings like iv-surface, risk-reversal, or term-structure, which keeps it from a 5.

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

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

There is no guidance on when to use this tool versus iv-surface, risk-reversal, or term-structure, all of which live in the same volatility area. The only usage hint comes indirectly from the schema, not the description.

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

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

No annotations are supplied, so the description carries the full burden, and it discloses almost nothing behavioral: no read-only confirmation, no result limits or pagination, no ordering, and no indication of what a returned row contains. The embedded parameter notes do cover the min_usd default (100,000) and that start_ns/end_ns bound transaction date for equities, which is genuinely useful context, but that is scoping detail rather than the tool's operational behavior.

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