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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, and the description adds substantial behavior beyond them: LEFT-join semantics (every left row is kept), collision suffixing on right column names, unmatched right values becoming None/no_match, the matched_t column, and the critical fact that large outputs are stored and returned as a result_id. That last detail is real operational context an agent cannot infer.

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

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

Dense but front-loaded: the operation and join semantics come first, then options, then output shape. Every clause carries information, though the single run-on paragraph could be split for scanning; no filler sentences.

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

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

With no output schema, the description fully specifies the returned columns (left columns, chosen right columns with suffix, matched_t, None for no match) and the result_id escape hatch, and it covers all seven parameters. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description weaves the parameters into the join semantics rather than restating them — how direction, tolerance (ISO-8601, e.g. PT5M) and by (e.g. ticker) combine to select the matched row, and what default right_columns means. This adds contextual meaning beyond the per-field schema text.

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 operation (as-of join / ASOF LEFT JOIN) on a specific resource (two stored time series) and states the execution context (computed locally in DuckDB). An agent can distinguish it from siblings like analytics_resample or analytics_returns without opening 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?

It gives an explicit use case — 'Use it to line up series of different frequencies' — which tells the agent when this tool applies. It stops short of naming alternatives (e.g., analytics_resample) or stating when not to use it, so it clears the bar but isn't fully prescriptive.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial behavior: local DuckDB computation, shared-timestamp return alignment, the None/insufficient_data outcome below min_obs, refusal of mismatched timeframes, and rolling output when window is set. It even discloses that large outputs are persisted and returned as a result_id, which is exactly the kind of context annotations cannot carry.

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

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

dense but no waste

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

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

With no output schema, the description partially compensates by naming the returned quantities (beta, alpha, r_squared, or None) and the result_id fallback, and annotations cover safety. It stops short of describing the full output shape/columns, so it is strong but not exhaustive.

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 baseline is 3, but the description adds cross-parameter meaning the schema does not: the shared-timestamp alignment rule, the min_obs=20 cutoff behavior, and the fact that window yields one row per window end. These interactions go beyond per-parameter field 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?

The description states a precise operation: 'Beta of each asset series against a benchmark, from two stored price results ... computed locally in DuckDB.' That verb+resource combination is unmistakably distinct from every sibling (analytics_correlation, analytics_volatility, analytics_returns, etc.), and the added note that the benchmark must hold exactly one series further sharpens the scope.

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

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

Usage is only implied through prerequisites: two stored results are required, the benchmark must be a single series, and period is 'needed when their bars differ.' There is no explicit when-to-use-this-vs-an-alternative guidance (e.g., correlation vs beta), leaving the agent to infer selection.

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

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

Annotations already cover read-only and idempotent behavior, but the description adds substantial operational context: DuckDB-local computation, long-form output with both pair orders and diagonal, pairwise-complete timestamps, insufficient_data threshold behavior, a 50-series cap, and large-output result_id storage. No annotation contradiction.

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

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

The description is front-loaded and dense, with nearly every sentence carrying behavioral detail. It is longer than strictly minimal but remains focused, with only slight implementation-density that keeps it from being perfectly 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?

For a no-output-schema analytics tool, the description explains output shape, edge-case behavior, scale limits, and result-storage behavior. Combined with full schema coverage and safety annotations, it is complete enough for correct invocation.

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 baseline is 3. The description adds meaning beyond the schema by explaining value_column default logic, price-to-returns transformation, and min_overlap producing None below the threshold, though it does not cover every parameter in depth.

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 precise operation, resource, and output shape: pairwise Pearson correlation of series in one stored result, returned in long form. It does not explicitly name or distinguish sibling analytics tools, but the verb+resource 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?

Implies usage when pairwise correlations across series in a stored result are needed, with examples such as bars of several tickers or returns. It gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance (e.g. analytics_returns, analytics_beta).

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: NULL/NaN/infinite/non-positive values are skipped, drawdowns are fractions, and large outputs are persisted with a returned result_id. That output-storage behavior is genuinely useful and not derivable from annotations.

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

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

Dense but front-loaded: the core computation comes first, then mode outputs, then edge-case handling and output persistence. No filler sentences, though the run-on structure packs many clauses per 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?

With no output schema, the description carries the return-shape burden and does so: it enumerates the max-mode columns (max_drawdown, peak_t, trough_t, recovery_t, peak_to_trough_days, n_obs) and explains series mode. An agent has what it needs to call and interpret results.

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

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

Schema description coverage is 100%, so the schema already documents mode, result_id, value_column, and series_column. The description largely restates the mode semantics and defaults already present in the schema, adding little new parameter-level meaning. Baseline 3 is appropriate.

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

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

States a specific verb (compute drawdown) and resource (each series in a stored result of prices/equity), and defines the computation precisely (running peak, value/peak - 1). This distinguishes it cleanly from sibling analytics tools like analytics_returns and analytics_volatility without needing to name them.

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

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

Gives implied usage guidance through the mode descriptions (max for summary, series for per-observation) and the note 'Use split-adjusted bars,' but never states when to prefer this over alternatives or any prerequisites/exclusions. Usage is inferable but not explicit.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: exact OHLCV aggregation rules, per-series agg semantics, NaN/infinite row skipping, UTC bucket alignment, output model preservation, and result_id storage for large outputs. This is unusually rich behavioral disclosure.

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

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

Front-loads the purpose and then packs only substantive behavioral detail. It is a dense single block rather than bulleted, which slightly hurts scanability, but essentially every clause 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?

With no output schema, the description still explains the return contract (output retains the input's model; large outputs are stored behind a result_id). Combined with the aggregation and alignment rules, an agent has enough to call it correctly, though the exact return shape for the stored case could be clearer.

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 baseline is 3, but the description adds real meaning: it explains that agg applies per value column for non-bar series while bars use fixed OHLCV rules, and that timeframe must be coarser and hold whole bars. It enriches the schema rather than merely restating it.

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

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

States a specific verb (resample) and resource (a stored time series) and adds the mechanism (computed locally in DuckDB). It is clearly distinguishable from siblings like analytics_align or analytics_returns, which do different transformations of series.

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?

Gives clear context: it enumerates the accepted input types (bars, quotes, trades, snapshots, portfolio history, query results) and a hard precondition that the target must be coarser than the bars and hold whole bars. It does not name alternative tools or state when not to use it, so it stops short of the top tier.

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

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

Goes well beyond the readOnly/idempotent annotations: first row has no return, NULL/NaN/infinite/non-positive prices are skipped and counted in notes, period sampling takes the last price per UTC bucket with t as bucket start, returns are fractions, and large outputs are persisted with a returned result_id. This is rich behavioral context an agent can't get from the structured fields.

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?

Front-loaded with the core purpose, then formulas, edge cases, and output routing in a tight paragraph. Dense but nearly every clause carries semantic weight; slightly over-long for a single block of 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 output schema, the description compensates by explaining the return format (fractions) and the result_id handoff to results_query. It covers the essential behavior for a computation tool, though it doesn't sketch the shape of the returned result beyond the id.

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 baseline is 3, but the description adds meaning: it clarifies the precise effect of period (last price per UTC bucket, t = bucket start) and the default resolution behavior, and confirms price_column defaults to close for bars. It adds real value over the schema without being exhaustive.

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 verb and resource — computes simple or log returns of each series in a stored result identified by result_id. This is unambiguous and distinguishable from analytics_resample, analytics_volatility, and results_query (which it explicitly routes to for output).

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?

Tells the agent the required entry point (pass a result_id) and recommends split-adjusted bars (adjustment=all), plus where outputs go (results_query or other analytics_* tools). It lacks explicit when-not-to-use guidance or a named alternative for the same job, so it falls short of a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds real behavioural value beyond that: local DuckDB computation, omission of rows before the window fills, the reporting point (window's last observation), the fraction-per-year unit convention, and that large outputs are persisted as a result_id.

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

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

A single dense paragraph that front-loads the core computation and formula, then edge behaviour and units. It is information-rich, though the periods_per_year mapping and return_kind notes duplicate schema text and could be trimmed.

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

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

With no output schema, the description supplies the missing return semantics: annualised fraction units, per-window reporting point, and result_id persistence for large outputs. Only minor gaps remain (no mention of error conditions or empty-series behaviour), so it is nearly complete for a read-only analytics tool.

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

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

Schema description coverage is 100%, so the schema already documents window bounds, result_id format, return_kind enum, and column defaults; that sets a baseline of 3. The description adds marginal framing (window as rows of returns, return_kind ignored for returns results) but largely restates the periods_per_year mapping already present in 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?

States a specific verb+resource (computes rolling annualised volatility per series over a stored result) and pins down the exact formula, scope, and input source. It also distinguishes itself from the sibling analytics_returns by clarifying it can consume that tool's output.

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

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

It makes clear the tool operates on a stored result of prices, or on returns produced by analytics_returns, which routes the agent to the right upstream tool. It stops short of explicitly stating when to prefer this over sibling analytics like beta/correlation/drawdown, so it is clear context without exclusions.

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

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

Annotations already cover read-only/idempotent/non-destructive, but the description adds meaning beyond them: pricing in quote currency, volume in base units, UTC bar starts, and the out-of-band result storage with a result_id. That storage/pagination behavior is the kind of trait annotations cannot express.

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

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

Three tightly packed sentences that front-load what the tool returns before touching defaults and the result storage behavior. No filler, though the timeframe/lookback defaults slightly duplicate schema content.

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

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

With no output schema, the description carries the return-shape burden and does so reasonably (OHLCV, one row per pair/bar start, units, stored large results via results_query). A brief note on the pagination/no-output-schema contract would make it airtight.

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 every parameter is already documented, including defaults and the lookback-only-when-start-omitted rule. The description restates timeframe/lookback defaults rather than adding syntax or constraints beyond the schema; the baseline 3 applies. Unit semantics it does add are output-oriented, not parameter-level.

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+resource ('Historical OHLCV bars for crypto pairs') and adds scope detail (one row per pair and bar start, UTC). The 'Historical' qualifier implicitly separates it from the crypto_latest_bars sibling, but no sibling is named explicitly.

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?

Gives clear operational context: window by start/end or lookback (default P1D), timeframe default 1h, and the crucial routing note that large results are stored and retrieved via results_query with a result_id. No explicit when-not-to-use or named alternative (e.g. crypto_latest_bars for the current bar), so it stops short of a 5.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only that bars are one-minute and per-pair, but says nothing about what happens when a ticker is unknown, max 200 batching behavior at runtime, or return shape. With annotations carrying the safety burden, this is a modest addition.

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. Appropriately sized for a one-parameter tool, though it is arguably too thin to be a strong 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 tool in a dense crypto/market family with many near-namesake siblings, the description does not disambiguate from crypto_bars, crypto_latest_quotes, crypto_snapshots, or market_latest_bars, and provides no return-value or error context. No output schema exists, so the description should carry more of this burden.

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 tickers parameter format (BASE/QUOTE, 1-200 items) is already fully documented in the schema. The description adds nothing beyond what the schema provides, which is baseline 3 when the schema does the heavy lifting.

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 scope: the latest one-minute bar for each crypto pair. That distinguishes it from time-series siblings like crypto_bars, though it doesn't explicitly name the sibling or note that it's a snapshot rather than a range. Clear verb+resource, but no sibling differentiation.

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 crypto_bars (historical bars) or crypto_latest_quotes. The 'latest' framing implies a snapshot use case, but the agent is left to infer that vs. history or quotes. No exclusions or prerequisites stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds a genuinely useful unit clarification ('sizes in base units'), but says nothing about rate limits, venue aggregation, or freshness/latency of the 'latest' data.

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 sentence, zero filler, and the most decision-relevant qualifier ('latest') plus the unit caveat are packed into the front of the line. Nothing to trim.

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

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

With no output schema, the description must carry the return-value burden. It hints at the shape (best bid and ask, sizes in base units) but omits the actual field names, timestamp semantics, and whether multiple venues/levels are returned — real gaps for a quote tool.

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

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

Schema description coverage is 100%, and the schema already documents the tickers array as BASE/QUOTE pairs with 1-200 limits. The description adds no parameter detail 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?

The description names a specific resource (crypto pair best bid/ask) and qualifies it as 'latest', which tells an agent this is a top-of-book snapshot rather than a trade or bar series. It does not, however, differentiate itself from close siblings like crypto_quotes or crypto_snapshots, which an agent must resolve on its own.

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 crypto_quotes, crypto_orderbooks, crypto_latest_bars, or crypto_latest_trades. The agent gets no explicit context or exclusions, only an implied 'use it to get quotes'.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds genuine content context by specifying one trade per pair and the inclusion of taker side, but says nothing about response shape or ordering beyond that.

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 scope (per pair) comes before the return detail. It is efficient, though the brevity is partly what leaves the usage and completeness gaps 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?

With only one fully-described parameter, rich annotations, and no output schema, the description covers the essentials of what it does and what it returns. It is incomplete on the one thing that matters here: how it differs from crypto_trades and the other latest_* 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 100% and the single tickers parameter is fully documented in the schema (BASE/QUOTE format, 1-200 items). The description adds no syntax or formatting detail beyond the schema, 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 verb+resource ("latest trade for each crypto pair") and adds the return detail "with the taker side." An agent can distinguish this snapshot-style tool from crypto_trades, but the description never names the sibling it differs from, so it stops short of full disambiguation.

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-tool guidance. Nothing tells the agent why to pick this over crypto_trades or crypto_latest_quotes, leaving selection to inference from the tool 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: level 0 is best price, sizes are in base units, levels beyond depth are truncated, and empty levels are dropped but surfaced in notes. It stops short of rate limits, auth, or pagination/ordering guarantees.

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

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

Two dense sentences with no filler, front-loading the resource and the row-per-level structure before the depth/default detail. Slightly clause-heavy, but every phrase carries information about output shape or truncation behavior.

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

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

With no output schema, the description does meaningful work to explain the return format (row per level and side, best price first, base-unit sizes, dropped levels counted in notes). It is nearly complete for correct invocation, though the notes field and remaining row columns are only partially characterized.

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%, with both tickers (BASE/QUOTE format) and depth (1-1000, default 20) fully documented in the schema. The description restates the default depth and per-side semantics but adds no new parameter-level meaning, 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 states a specific verb+resource (latest order book per crypto pair) and goes further by describing the output shape: one row per price level and side. This clearly separates it from trade/quote siblings like crypto_latest_quotes or crypto_trades, though it never names those alternatives explicitly.

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

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

Usage is implied rather than stated: 'latest order book' with per-level granularity signals depth/L2 retrieval, distinguishing it implicitly from top-of-book quote tools. There is no explicit when-to-use, when-not-to-use, or named alternative anywhere in the text.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open world). The description adds genuinely non-structured behavior: a missing side returns null/no_data, sizes are in base units, and large result sets are stored rather than returned, yielding a result_id. The result-truncation disclosure is the kind of trait annotations cannot express.

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

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

Three compact, front-loaded sentences with no filler: purpose, windowing, then the result-storage caveat. Slightly dense in the first clause (sizes/no_data parenthetical) but each sentence carries distinct information.

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

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

With no output schema, the description carries the return-value burden and does so for the two most surprising cases: null sides and stored results via result_id. Pagination via page_token is only covered in the schema, not the description, leaving a small gap for a tool that can return truncated data.

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 every parameter (start, end, lookback, sort, tickers, page_token) is already documented in the schema, including the PT15M lookback default. The description's windowing sentence largely restates that, adding no format or constraint detail beyond the schema. Baseline 3 applies.

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

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

States a specific resource and temporal scope: 'Historical best bid and ask for crypto pairs.' The word 'Historical' implicitly separates it from crypto_latest_quotes and crypto_orderbooks, but no sibling is named explicitly, so an agent must infer the boundary.

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

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

'Window by start/end or lookback (default PT15M)' gives invocation guidance, and the results_query handoff tells the agent what to do with truncated output. However, there is no explicit when-to-use-this-vs-alternative statement (e.g. historical quotes vs crypto_latest_quotes or crypto_orderbooks), so usage is only implied.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety and idempotency are covered. The description adds that the 'latest state' is returned and that change is derived, which is useful context. But it doesn't clarify timing/staleness characteristics or that one ticker per pair is returned.

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

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

A single dense sentence that front-loads the resource and enumerates return fields without waste. The parenthetical '(fraction)' is a useful precision note. Slightly list-heavy but efficient.

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

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

For a read-only aggregation tool with no output schema, the description does a reasonable job listing returned fields. But without an output schema, the field list is prose-only and lacks structure; and the relationship to sibling tools that cover subsets is unaddressed. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, and the tickers parameter is well-documented in the schema (BASE/QUOTE format, 1-200 range). The description adds no further parameter syntax or format detail beyond what the schema provides, so baseline 3 applies.

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

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

States a specific resource (crypto pair snapshots) and enumerates the fields returned (last trade, bid/ask, minute close, OHLCV, VWAP, change). It's clear what the tool provides. However, it doesn't distinguish itself from very similarly-named siblings like crypto_latest_trades, crypto_latest_quotes, or market_snapshots.

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 alternatives. With siblings like crypto_latest_trades, crypto_latest_quotes, and crypto_orderbooks that cover subsets of what this tool aggregates, the description should explain that this is a consolidated single-call snapshot. It does not.

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 annotations already declaring read-only/idempotent/open-world, the description adds genuinely useful behavior the annotations cannot convey: trades carry base-unit size and taker side, and large results are stored rather than returned inline, yielding a result_id for results_query. This offsets the missing return-shape detail.

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

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

Three tight sentences, front-loaded with the resource and its key data semantics, then windowing, then the results-storage caveat. 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?

No output schema exists, so the description carries extra burden, and it covers the most important surprises: size units, taker side, and stored-result/result_id behavior. It could still say more about pagination and the truncation case, but the essentials are present.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including the lookback default and formats; baseline 3 applies. The description restates the windowing and default PT15M without adding format or syntax detail 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?

States a specific verb+resource: 'Historical crypto trades' with the taker side, and the parenthetical clarifies size units. The word 'Historical' implicitly separates it from the sibling crypto_latest_trades, but the description never names that sibling, so an agent must infer 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?

Explains how to scope the window (start/end or lookback, default PT15M) and routes the agent to results_query when results are large. It gives clear context for invocation but does not explicitly state when to prefer this over crypto_latest_trades or market_trades.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description is free to add value elsewhere — and it does, disclosing unit conventions and the null/'no_data' behavior for a side with no active quote. This is meaningful context beyond the annotations, though batch/rate behavior is not addressed.

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

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

A single dense sentence with zero filler: the core purpose is front-loaded, followed by units and then null handling. Every clause carries information an agent needs to interpret the result.

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

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

With no output schema, the description correctly carries the return-value burden by enumerating bid/ask, price units, size units, YTM, YTW, and null semantics. This is close to complete, though it does not describe the overall response shape (e.g. per-ISIN grouping) in detail.

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 'isins' parameter (1-100) is fully documented in the schema, so the baseline of 3 applies. The description adds no syntax or format detail about the ISIN input beyond what the schema already provides.

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

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

The description names a specific verb and resource ('the latest best bid and ask per bond by ISIN'), making the operation unambiguous. The 'bond' scope implicitly distinguishes it from market_latest_quotes and options_latest_quotes, though it never explicitly differentiates itself from those 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?

There is no when-to-use guidance, no mention of alternatives, and no stated prerequisites. The agent can infer it fetches quotes for a list of ISINs, but nothing tells it when this tool is preferable to market_latest_quotes or other quote tools.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond them: UTC row alignment, source feed, and notably that large results are stored rather than returned, yielding a result_id to fetch via results_query.

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?

Densely packed but front-loaded with the core resource and scope, then parameters, then the result-storage caveat. Semicolon-heavy run-on style is efficient but slightly harder to parse than distinct sentences.

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

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

With no output schema, the description carries return-value burden and does so - explaining row format and the result_id/results_query handoff for truncated fetches. It could still say more about pagination (page_token) explicitly, but the essential behavior for correct invocation is present.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds intent beyond the schema - it explains that adjustment=all is 'what return analytics need' and ties window defaults to timeframe context, giving meaning to why defaults differ (P5D intraday vs P1Y daily).

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+resource ('Historical OHLCV bars for US stocks') with scope, units (USD, shares), and row granularity (one row per ticker and bar start, UTC). 'Historical' and 'US stocks' clearly separate it from market_latest_bars, crypto_bars, and options_bars among the 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?

Gives useful context (defaults for timeframe/window, the configured stock_feed, and routing large results to results_query), but never states explicitly when to prefer this over market_latest_bars or other bar tools, nor when-not to use it. Usage is implied rather than prescribed.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely useful semantics (prices in USD, volume in shares), but says nothing about freshness/latency of the 'latest' bar or partial-day 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 filler; the units parenthetical is the only extra clause. Appropriately sized, though it errs toward under-specification rather than 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 simple one-parameter read tool this is close to adequate, but with no output schema the description could have said what a 'bar' contains (OHLC fields) or how fresh the latest bar is. Those gaps are minor but real.

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 one parameter and schema description coverage is 100% — the schema already documents the ticker format, example, and the 1-200 bound. The description adds no parameter-level meaning beyond what the schema provides, so baseline 3 applies.

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

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

The description states a specific verb (return/latest), resource (one-minute bar) and scope (for each stock ticker), which cleanly separates it from quote/trade siblings. It does not explicitly name the sibling it differs from (e.g. market_bars for history, market_latest_quotes for quotes), so differentiation is implied rather than stated.

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

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

There is no when-to-use guidance at all: nothing says to pick this over market_bars (historical bars), market_latest_quotes, or crypto_latest_bars. The agent must infer the choice 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?

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds genuinely useful behavior beyond that: price/size units (USD, shares) and the null/no_data convention for a side with no active quote, which the schema does not convey.

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

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

One dense sentence that front-loads the core purpose and tucks units and null semantics into parentheticals. No filler or repetition; every clause carries 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?

With no output schema, the description does the work of explaining the return shape (bid/ask per ticker, null for a missing side) and units, which is the critical gap it needed to fill. It is slightly thin on batch semantics, such as behavior for unknown tickers in a multi-ticker request.

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% for the single tickers parameter, including the 1-200 range and an example format, so the baseline is 3. The description adds no ticker-specific semantics (e.g., symbol normalization or batch failure behavior) beyond what the schema already states.

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: the latest best bid and ask for each stock ticker, which is precise and actionable. It does not, however, distinguish itself from close siblings like market_quotes, market_snapshots, or the crypto/options/fixed-income variants of 'latest_quotes', so the agent must infer the asset-class scoping from the name rather than the text.

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 mention of prerequisites, and no routing to alternatives such as market_quotes or market_snapshots. The agent is left to infer that this is the point-in-time top-of-book call 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds the returning semantics (price in USD, size in shares), which is useful, but says nothing about the timestamp of the 'latest' trade, exchange aggregation, or whether tickers not trading return empty.

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 that front-loads the resource and ends with the returned fields. No filler, no repetition of the title.

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

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

For a simple one-parameter read tool with a 100%-covered schema and annotations carrying the behavior profile, the description is nearly sufficient, and it partially compensates for the absent output schema by naming the returned fields. It still omits any notion of a timestamp or empty-result behavior, leaving a modest gap.

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

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

Schema description coverage is 100% and the single tickers parameter is fully documented with an example and bounds (1-200). The description adds no parameter-level meaning 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 verb (retrieve the latest) and resource (trade per stock ticker) plus the returned fields (price USD, size shares). It is distinguishable from market_trades (historical) and crypto/options variants by the 'stock' scoping, but it never explicitly contrasts with the adjacent market_latest_bars and market_latest_quotes 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?

There is no explicit when-to-use guidance or set of alternatives. The word 'latest' implies the intent (one snapshot per ticker vs. a history), but the description never routes an agent between market_latest_trades, market_latest_quotes, market_latest_bars or market_trades.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description earns credit by adding behavior beyond the annotations: that values are cumulative for the current trading day and that as_of reflects the screener's last update, which tells the agent how fresh the data is.

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 that leads with what is returned and where. Both clauses carry information (ranking basis, freshness semantics) and there is no filler.

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

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

For a two-optional-parameter screener with no nested objects and no output schema, the description covers ranking basis, universe (US stocks), timeframe, and freshness. It is close to complete; the absence of any hint about result shape or result count is a minor gap given there is no output schema to fall back on.

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 schema already documents both 'by' (with enum) and 'top'. The description's 'ranked by share volume or trade count' restates the 'by' semantics and adds nothing for 'top', matching the baseline 3 when the schema does the heavy lifting.

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 scope: 'Today's most active US stocks ranked by share volume or trade count,' which is far more precise than the bare title. It does not, however, explicitly distinguish itself from the close sibling market_movers, leaving the agent to infer the difference (ranking by activity vs. price change).

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 ranking criteria implicitly signal the query this tool answers, so a competent agent can infer usage. But there is no explicit when-to-use vs. the analogous market_movers or market_quotes tools, and no stated exclusions or prerequisites.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description earns credit for adding output semantics: percent_change is a fraction (0.05 = 5%) and results are ranked separately per direction. It still does not state data freshness/snapshot timing or pagination/truncation behavior.

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

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

A single dense sentence that front-loads the resource, then the returned fields, then the ranking rule. No filler; the parenthetical percent fraction clarification is the only elaboration and it is load-bearing.

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 only two optional params, the description usefully enumerates the returned fields (price, change, percent_change) and their units. Only minor gaps remain, such as the definition of 'today' (session vs calendar day) and result size interactions with 'top'.

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%: 'top' and 'market_type' are both fully documented in the schema. The description largely restates these ('ranked within each direction' mirrors the schema's 'how many gainers and how many losers'), so baseline 3 applies.

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

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

States a specific verb+resource ('Today's top gainers and losers') and names the two supported market types. The price-change ranking metric is clearly distinct from the volume-based sibling 'market_most_active', though no sibling is named explicitly.

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

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

Usage is implied by 'Today's' (a same-day ranking screen) and by the stocks/crypto choice, but there is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as market_most_active or market_snapshots.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description is free to add real behavioral context: round-lot conversion at 100 shares before 2025-11-03, null-vs-0 semantics for inactive sides, and the side effect that large result sets are stored rather than returned, yielding a result_id. That is meaningful disclosure beyond the annotations.

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

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

Three compact sentences, front-loaded with what the data is, then semantics, then the windowing/storage mechanics. No filler; each clause carries actionable 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?

With no output schema, the description still conveys the return shape (one row per quote), unit conventions, null handling, and the result_id indirection for large payloads, plus pagination via page_token in the schema. Nothing essential to correct invocation is missing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds practical meaning: the start/end vs lookback relationship, the default window length, and the operational implication that windows should be short because quotes are dense. This informs parameter choice rather than merely restating field docs.

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 qualifier: 'Historical best bid and ask quotes for US stocks', with the 'Historical' qualifier implicitly separating it from market_latest_quotes. The row-granularity and currency/unit semantics (USD prices, share sizes) make the returned artifact 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?

Gives concrete operating guidance: window via start/end or lookback (default PT20M), and an explicit warning that quotes are dense so windows should be kept short. It also routes the agent to results_query for large results. It stops short of naming sibling alternatives (e.g. market_latest_quotes for real-time) or stating exclusions.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so safety is covered. The description adds real behavioral context beyond them: change_pct is expressed as a fraction, change is derived specifically from last trade vs. previous close, and tickers with no data are surfaced in notes rather than silently dropped. No auth or rate-limit detail, but the value-add is genuine.

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, zero filler, and the resource scope is front-loaded before the field inventory. Every clause carries information an agent needs to interpret the response.

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

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

With no output schema, the description carries the return-value burden and does so well by listing the fields and the notes behavior for unmatched tickers. It could say a bit more about units/price semantics, but nothing needed to call it correctly is missing.

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

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

There is a single parameter with 100% schema description coverage that already documents the format (['AAPL','BRK-B']) and the 1-200 bound. The description adds nothing about the tickers argument, 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 states a specific verb+resource ('Latest state per stock ticker') and enumerates exactly which fields the snapshot contains, which implicitly separates it from the single-datatype siblings (market_latest_trades, market_latest_quotes, market_latest_bars). It stops short of naming those siblings, so the differentiation requires the agent to infer 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?

Usage is only implied: the field list suggests this is the one-shot aggregate call to prefer over several single-type calls, but there is no explicit when-to-use statement, no exclusion, and no named alternative. Adequate but with a clear gap.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), yet the description adds substantive behavior: canceled/incorrect trades are dropped and counted in notes, and large results are stored rather than returned with a result_id. These are non-obvious traits an agent could not derive from annotations.

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

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

Three tightly packed sentences with no filler; the core resource, the data-hygiene caveat, the windowing rule, and the large-result workflow are all front-loaded in that order.

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

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

With no output schema, the description carries return-shape duty and does explain the result_id handoff and notes for dropped trades. It stops short of describing row fields beyond price/size, but for a paginated market-data tool this is nearly 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?

Schema coverage is 100%, so parameters are documented, but the description still adds value by clarifying units ('price USD, size shares') and the windowing model (start/end vs lookback with default PT20M). This meaningfully augments the schema rather than repeating it.

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

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

States a specific verb and resource ('Historical trades for US stocks') with clear scope, and the 'historical' qualifier implicitly separates it from market_latest_trades and crypto_trades/options_trades siblings. An agent can identify the resource and asset class without opening 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?

The description explains how to window data (start/end or lookback, default PT20M) and routes large results to results_query, which is useful context. However, it never names an alternative tool or states a when-not condition (e.g. use market_latest_trades for the current snapshot), so tool selection is left to inference.

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

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

With readOnlyHint/idempotentHint already declaring the safe-read profile, the description still adds substantial behavioral context: third-party text should be treated as data, never instructions (prompt-injection safety), include_content yields large bodies, and — critically — large results are stored rather than returned, yielding a result_id to query with results_query. That result_id indirection is a major non-obvious behavior disclosed nowhere in annotations or 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?

Dense but front-loaded: it leads with what is returned, then filtering, then safety, then windowing, then the storage caveat. Every clause carries information and nothing is padded.

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

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

There is no output schema, so the description carries the full return burden — and it does: it lists the returned fields, default sort, and the result_id/results_query handoff for large results. Combined with the safety note, an agent has everything needed to call and follow up 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 100%, so the schema already documents every parameter, including the start/end/lookback interaction and defaults. The description restates the windowing model and flags include_content as large, adding emphasis but little meaning beyond what the schema states, 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 states the resource (news articles), enumerates the returned fields, gives the default ordering (newest first), and the optional ticker scoping. It is unambiguous about what the tool fetches. It does not differentiate from siblings, but news_search has no overlapping sibling among the listed tools, so the differentiation requirement is largely moot.

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

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

Usage is implied rather than stated: the mention of tickers, windows, and include_content tells the agent how to configure a call, but there is no explicit 'use this when / not when' framing and no alternatives named. For a tool whose siblings (market_movers, analytics_*) also surface market context, more routing guidance would 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?

Annotations already cover read-only/idempotent/non-destructive/open-world, so the bar is lower. The description adds real behavioral context the annotations cannot: units (premium per share USD, volume in contracts) and the truncation contract — large results are stored and returned as a result_id to fetch via results_query.

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

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

Three tight sentences, front-loaded with the resource and scope, no filler. Minor duplication of defaults that already live in the schema keeps it short of a 5.

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 exists, so naming the fields (OHLCV), units, and the result_id handoff covers the essential return semantics. Pagination and sort are left to the schema, which is acceptable given 100% schema 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?

Schema description coverage is 100%, so the schema fully documents all seven parameters, including start/lookback mutual exclusion and pagination. The description restates the timeframe/lookback defaults and the start-or-lookback choice, adding little beyond the schema; 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 precise verb+resource: 'Historical OHLCV bars for option contracts by OCC symbol.' The 'historical' + 'option contracts' framing separates it from the latest/snapshot siblings (options_latest_quotes, options_snapshots) and from equity bars (market_bars) without needing to name them.

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

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

Usage context is implied by the OHLCV/window framing, and it helpfully routes large responses to results_query. But it never states when to pick this over options_chain, options_trades, or market_bars, and gives no exclusions or prerequisites.

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

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

Annotations already cover readOnly/idempotent/non-destructive/openWorld, so the safety profile is done. The description adds genuinely useful behavior beyond them: large results are stored rather than returned inline and the caller receives a result_id to fetch via results_query. It does not mention pagination behavior even though page_token exists 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?

Three tight sentences, front-loaded with what the tool returns, then the filtering constraint, then the result-storage behavior. No filler or restated field names.

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

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

With no output schema, the description steps in to explain the return contract (stored results plus a result_id for results_query), which is exactly the missing piece. Combined with the annotations and 100% schema coverage, an agent has what it needs to call this 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 100%, so the schema already documents every parameter including strike_min/max as inclusive USD values and expiration_from/to. The description only summarizes the same information ('strike range (USD)', 'expiration (exact or from/to)'), adding little beyond the structured fields.

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 ('option chain of one underlying') and the exact content of a row (greeks, implied volatility), plus the filter axes (type, strike range, expiration). This distinguishes it from siblings like options_snapshots, options_bars and reference_option_contracts.

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?

Gives clear operational guidance: 'Chains are large; filter by expiration and strike', steering the agent toward narrowing filters. It also routes the agent to results_query for retrieving stored output, but does not explicitly state when to prefer options_snapshots or options_bars over this tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral detail beyond that: sizes are in contracts and a missing side is returned as null with a no_data reason, which tells the agent how to interpret incomplete 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?

One dense sentence that front-loads the core resource and folds in the two non-obvious details (contract units, null handling) with zero padding. Nothing is wasted or buried.

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

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

For a read-only, single-parameter quote lookup, the description covers the essentials and hints at the return shape (bid, ask, sizes, null sides). With no output schema, it could say more about the response envelope (timestamps, whether quotes are per-exchange or consolidated), but it is sufficient to call the tool correctly.

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

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

Schema coverage is 100% and the single occ_symbols parameter is fully documented with format example and 1-100 bound. The description only reinforces 'per option contract' and adds no syntax or format detail beyond the schema, 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 verb and resource: latest best bid/ask per option contract. It clearly distinguishes itself from trade-based siblings (options_latest_trades, options_trades) by naming bid/ask, though it never names an alternative explicitly, so sibling differentiation is implied rather than stated.

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

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

The description offers no when-to-use guidance and no comparison against close alternatives such as options_snapshots, options_chain, or options_quotes. The agent must infer the use case entirely from the tool name and field 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the safety and idempotency profile is covered. The description adds that data comes from a 'configured options_feed', hinting at a potential dependency on external configuration, but doesn't detail the fallback behavior if the feed is unconfigured or the latency/refresh characteristics. This additional context is modest but useful.

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

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

A single sentence that front-loads the key information: action (latest trade), scope (per option contract), and source (configured options_feed). No wasted words.

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 read-only tool with one parameter and full schema coverage, the description is adequate but not rich. It lacks information about return format (e.g., does it include timestamp, price, size?), pagination, or error handling. Given no output schema, the agent might need more context on what 'latest trade' includes, though annotations cover the read-only nature.

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%; the occ_symbols parameter is fully documented in the schema including format example and range. The description adds no parameter-level details beyond what the schema provides, 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 verb (retrieve latest trade) and resource (option contract, OCC symbols), distinguishing it from options_trades (historical) and options_latest_quotes (quotes). However, it doesn't explicitly name the siblings it differs from, so an agent must infer the distinction. The phrase 'from the configured options_feed' adds a mild scope qualifier but is not fully explained.

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

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

No explicit when-to-use guidance is provided. It doesn't state 'use this when you need the most recent trade for specific contracts' or contrast with options_latest_quotes or options_snapshots. The agent must infer usage from the name and sibling list.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely non-obvious behavior: large results are stored rather than returned, yielding a result_id to redeem via results_query, plus the greeks methodology (Alpaca Black-Scholes, per share) and IV as an annualised fraction.

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

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

Two dense sentences, front-loaded with what the tool returns and ending with the result-handling caveat. Every clause carries information; no filler.

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

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

With no output schema, the description carries the full burden and delivers: it enumerates the returned fields and the truncation/result_id mechanism. Combined with the annotation safety profile, an agent has everything 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 100%, so both occ_symbols (with an example) and page_token are already documented in the schema. The description's note that expiration, strike and type are parsed from the OCC symbol adds a little interpretive value but no syntax beyond what the schema provides, so baseline 3 applies.

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

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

States a specific resource and scope: 'Latest state per option contract' with the exact fields returned (greeks, IV, last trade, best bid/ask, today's bar, previous close). This clearly separates it from siblings like options_chain, options_bars and options_latest_quotes, which cover different slices of option 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?

Usage is implied rather than stated: the agent can infer this is the snapshot/point-in-time tool, and the description routes to results_query when results are large. However, it never says explicitly when to prefer this over options_chain or options_latest_quotes, nor any exclusions.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive). The description adds genuinely useful behavior the annotations cannot express: large results are persisted rather than returned, and a result_id is handed back to be fetched via results_query. It omits pagination/truncation behavior details and rate limits.

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 tightly packed sentences: the first gives resource, identifier scheme and units; the second gives windowing and the large-result/result_id behavior. Front-loaded and zero filler.

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

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

With no output schema, the description carries the return-value burden and does so partially, disclosing the unit conventions for premium and size plus the result_id escape hatch for oversized responses. It never describes the row shape (fields per trade) or truncation semantics, which leaves a small gap for a 6-parameter tool.

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

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

Schema description coverage is 100%, so every parameter (start, end, lookback, sort, page_token, occ_symbols) is already documented in the schema, including the P1D default that the description repeats. The description adds units context ('premium per share in USD, size in contracts') but nothing about the inputs beyond the schema, 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 verb+resource ('Historical trades for option contracts'), and the word 'Historical' plus 'by OCC symbol' implicitly contrasts with siblings like options_latest_trades and options_bars. It stops short of naming an alternative explicitly, so an agent must infer the boundary from the adjective 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?

Gives concrete usage mechanics (window by start/end or lookback, default P1D) and routes to a specific sibling ('query with results_query') for the stored-result case. It does not state when to prefer this over options_latest_trades or options_chain, so the when-not side is absent.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds only that the response includes "trading attributes," which hints at return content but names none of them and gives 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 tight sentence with the resource and accepted identifier formats front-loaded and zero wasted words.

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 read-only lookup with rich annotations, the definition is nearly sufficient; the only gap is the unspecified set of "trading attributes" returned, which matters slightly given there is no output 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 100% and the ticker format examples (BRK-B, BTC/USD) are duplicated verbatim from the schema, so the description adds no meaning beyond the structured field. Baseline 3 for a fully documented single 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?

States a clear resource (a single asset) and the identifier formats it accepts, with "One asset" implicitly contrasting with the bulk sibling reference_assets. It never names that sibling explicitly, so the differentiation is left to inference.

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

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

No when-to-use guidance and no alternatives named. The agent must guess that reference_assets is the bulk counterpart and that market_* tools are for pricing rather than reference 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), but the description adds the crucial behavioral fact that large results are not returned inline and instead produce a result_id to retrieve via results_query. That is genuine, non-redundant disclosure about result 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?

Two sentences, front-loaded with what the resource contains and followed by usage and result-handling notes. The attribute enumeration is dense but informative and every clause carries weight.

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

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

With no output schema, the description compensates by explaining the result_id storage mechanism, which an agent needs to actually consume the output. Filter options and asset contents are also covered, leaving little an agent would need to infer before calling.

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% with all four parameters documented in the schema itself. The description merely recaps the filter fields (status, class, exchange, attributes) without adding syntax, defaults, or edge-case meaning beyond the schema, so baseline 3 applies.

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

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

The description names a concrete resource (tradable assets) and enumerates the attributes returned, which tells an agent exactly what data it yields. It is clear but does not explicitly contrast itself with near-siblings like reference_asset (singular) or reference_option_contracts.

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

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

It states which fields can be used to filter ('Filter by status, class, exchange or attributes') and warns the unfiltered list is large, which implies the preferred usage. However, there is no explicit when-to-use guidance or routing to alternatives such as reference_asset, results_query, or results_describe.

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

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: times are converted from New York to UTC, early closes are included, and a settlement date is returned. That is meaningful disclosure beyond the structured fields, though pagination and response shape are unaddressed.

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

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

A single dense sentence with the resource and range front-loaded before the output details. It is slightly overloaded with parenthetical asides, but every clause carries information and nothing is padded.

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

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

With no output schema, the description usefully enumerates what comes back (core and extended session times, early closes, settlement date), which is what an agent needs to decide whether to call it. Only pagination/volume limits and timezone-format edge cases are left implicit for a two-parameter read-only tool.

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

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

Schema description coverage is 100% and both parameters already document their defaults ('today, UTC' and 'start + 31 days'). The description's restatement of the default range mirrors the schema rather than adding syntax or format nuance, 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 states a specific resource (US equity trading days) and the concrete payload (core open/close and extended session times, settlement date), which is far more than a restatement of the name. It does not explicitly name or contrast with a sibling tool, but no sibling competes for the calendar concept, so differentiation is implicit.

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

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

Usage is implied by the reference_ prefix and the calendar framing, but the description never says when to reach for this versus reference_clock or the market data tools, nor does it state prerequisites. Adequate context, no explicit when/when-not guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered structurally. The description adds that the answer is live status with UTC timestamps, but says nothing about caching/refresh semantics, holiday handling, or whether the next open/close accounts for early closes — modest added value over the annotations.

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

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

A single clause with the core answer front-loaded ('Whether the US equity market is open now') followed by the supporting detail. No filler or restated name/title content.

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

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

With no output schema, the description must hint at the return values, and it does: open/closed status plus next open and close in UTC. It omits timestamp format and timezone-edge handling, which is a minor gap for such a small, no-input tool.

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

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

The tool takes zero parameters, so the baseline is 4; there are no parameter semantics the description could or should document.

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 subject (US equity market open status) and the returned values (next open and close, UTC) in one sentence, which an agent can grasp immediately. It does not name or distinguish itself from the closest sibling, reference_calendar, leaving the split to inference.

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

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

No explicit when-to-use or when-not-to-use guidance, and no mention of the alternative reference_calendar for schedule-style questions. For a zero-argument status tool the intended usage is strongly implied, but the description never states the condition that selects it over calendar lookups.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not say what happens when the id is unknown, whether the response is a snapshot or a live record, or what fields come back.

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 terse sentence with no filler and the identifying key front-loaded. It is efficient, though it borders on 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?

This is a one-parameter read lookup with no output schema, so the bar is low and annotations cover the safety semantics. Still, the description omits how to obtain the id and what the returned announcement contains, leaving the agent to infer the list-then-fetch workflow.

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

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

Schema description coverage is 0%, so the description must carry the burden for the single parameter, and 'by its id' only restates the obvious. It does not explain where the announcement_id comes from (e.g., the id values returned by reference_corporate_action_announcements) or what the opaque identifier format represents; the pattern/maxLength constraints are only in 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 phrase 'One corporate action announcement by its id' names a specific resource and signals single-item lookup keyed by an identifier, which distinguishes it in spirit from the plural sibling reference_corporate_action_announcements. It never names that sibling explicitly, so the differentiation is inferred rather than stated.

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

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

There is no statement of when to use this tool versus reference_corporate_action_announcements (list) or reference_corporate_actions. The agent must guess that this is the drill-down companion to the list endpoint, and no prerequisites or error conditions are given.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds real operational context beyond that: the 90-day maximum window, which date fields the range filters on, and the shape of the returned data (dates, cash per share in USD, old/new rates).

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

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

One dense sentence that front-loads the resource and its type scope before the window constraint and optional filters. Nothing is wasted, though the clause stacking makes it slightly heavy to parse.

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

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

For a read-only reference query with full schema documentation and no output schema, the description covers resource, scope, window limit, filter dimensions and returned fields. The only omission is disambiguation from the singular sibling tool.

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

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

Schema description coverage is 100%, so every parameter is already documented, including the 90-day cap and the date_type enum. The description largely restates those facts and adds no format or syntax detail beyond the schema, 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 verb and resource ('Announced corporate actions') and enumerates the covered types (dividends, mergers, spin-offs, splits), so an agent knows exactly what it retrieves. It does not, however, distinguish itself from the near-identical singular sibling reference_corporate_action_announcement, leaving that routing to inference.

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

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

Usage is implied by the constraints given: a bounded date window filtered by one of four date types, optionally narrowed by ticker or CUSIP. There is no explicit when-to-use versus the singular announcement tool or reference_corporate_actions, and no stated exclusions.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description adds non-obvious behavior: sparse columns are explicitly null rather than omitted, and oversized results are persisted server-side with a returned result_id. Those are genuine operational traits beyond the annotations.

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

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

One dense paragraph, front-loaded with what a row looks like before moving to filtering and the truncation/pagination escape hatch. Every clause carries information; slightly long but no filler.

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

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

With no output schema and 7 optional params, the description does the heavy lifting on return shape (columns, null handling) and the result_id handoff to results_query. Complements the schema's page_token note; nothing critical is missing, though the relationship to the announcements sibling remains unexplained.

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 71%, and the description adds semantics the schema lacks: the domain meaning of the five date columns, that cash rate is per-share USD, that ratio legs are old/new, and that non-applicable columns are null/'not_applicable'. This meaningfully extends the schema's terse parameter docs.

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+resource ('Processed corporate actions, one row per action') and enumerates the returned fields (action_type, dates, cash rate, ratio legs). It does not name the near-sibling reference_corporate_action_announcement, so an agent can't distinguish this from the announcement feed on description alone, but the 'processed' framing implies 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?

Explains filtering dimensions (tickers, CUSIPs, types, process-date window, default today) and the follow-up path when results are large (result_id → results_query). No explicit when-not-to-use or sibling routing, but the triggering context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is fully covered. The description adds only the phrase 'with its deliverables' as extra content context; it does not disclose rate limits, error behavior, or freshness. With annotations carrying the burden, a 3 is appropriate.

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 fragment with zero filler. It is efficient, though its brevity borders on under-specification for routing against the plural sibling.

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 read-only lookup with no output schema and full annotation coverage, the description is close to adequate. The one meaningful gap is failing to differentiate from reference_option_contracts, which an agent could confuse with this tool.

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

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

There is a single parameter with 100% schema description coverage, including an example OCC symbol, so the schema does all the work. The description adds no syntax or format detail beyond it, matching the baseline 3 for fully documented params.

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 (one option contract), a lookup key (OCC symbol), and scope (singular), which distinguishes it from list-style tools. However, it never names or contrasts with the obvious sibling reference_option_contracts (plural), leaving the single-vs-list distinction implicit.

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

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

There is no explicit when-to-use guidance or mention of alternatives. The singular 'One option contract' weakly implies a single-symbol lookup versus the plural sibling, but no exclusion or condition is stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond that: results may be truncated and persisted rather than returned inline, yielding a result_id. That is exactly the kind of context annotations cannot express.

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 resource and its field list, then the critical storage/result_id behavior. The parenthetical field inventory is long but each item is informative. No filler or tautology.

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

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

With no output schema, the description carries the return-value burden and does so by listing the returned contract fields, plus the result_id/truncation workflow. Pagination via page_token is left to the schema, which documents it adequately, so the definition is close to self-sufficient.

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

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

Schema description coverage is 83%, so the schema already documents most filters, and the description largely restates the same filter set (underlyings, expiration exact or from/to, type, style, strike range, root). It adds minor clarification (strike in USD, deliverables on request) but nothing about default semantics such as the active-only status default.

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

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

The description opens with a specific verb+resource ('Listed option contracts') and enumerates the returned fields (OCC symbol, underlying, expiration, strike, type, style, multiplier, open interest, last close), so the agent knows exactly what data comes back. It does not, however, explicitly distinguish itself from the singular sibling reference_option_contract or from options_chain, which an agent scanning the tool list would need.

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

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

It names a concrete downstream alternative and the condition that selects it: large results are stored, and the returned result_id should be queried with results_query. It also states 'deliverables on request,' implying when to set show_deliverables. It stops short of saying when to prefer this over options_chain or reference_option_contract.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered without description help. The description adds only the content hint (code→name mapping) and no information about enumeration completeness, caching or return shape; with annotations carrying the behavioral burden this is adequate but thin.

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

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

A single front-loaded sentence with the resource named first and the usage hint second; no filler, no redundancy.

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

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

For a zero-argument static reference lookup with no output schema, the description tells the agent what the rows contain (codes and names) and what they are for. An explicit note that the list is a fixed enumeration would make it fully complete, but nothing essential is missing.

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

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

The tool takes zero parameters (NoArgs schema), so there is no parameter semantics to document; the baseline for a 0-param tool applies. Nothing in the description conflicts with the empty 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?

States a specific resource (option exchange codes and names) that is clearly a reference-data lookup, distinguishing it from the sibling contract-lookup tools (reference_option_contract(s)) and from the market-data tools. The verb is implicit in the noun phrase, but an agent can still tell what it returns.

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

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

The parenthetical 'to read the exchange columns of option quotes and trades' gives a concrete usage context, which is more than most reference tools offer. However, it names no alternative and gives no explicit when-not-to-use condition, leaving usage implied rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so safety is covered. The description adds real behavioral context about what the response contains: typed columns with units, null/min/max stats, first/last row previews, provenance, pagination, and three ready-made queries — meaningful disclosure given there is no output schema.

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

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

A single front-loaded sentence that opens with the verb and then uses a colon-list to enumerate outputs. Every clause conveys content; the list is dense but not padded. Slightly list-heavy, but no wasted sentences.

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

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

With no output schema, the description carries the burden of describing returns and does so thoroughly (columns, units, stats, previews, provenance, pagination, suggested queries). Only minor gaps remain, such as error behavior for an invalid or expired result_id and any size limits on the preview.

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%: result_id is fully documented with a regex pattern and a concrete example ('r_8c1f0a9d3e'), and the schema itself notes it comes from this session. The description adds no additional syntax or format meaning beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Show a stored result's summary again') and enumerates exactly what the summary contains, so the agent knows this is a re-display/describe operation rather than a new query. It does not, however, explicitly contrast itself with siblings like results_query, results_sample, or results_list, so sibling differentiation is left to inference.

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

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

The word 'again' hints that this re-shows a summary produced earlier (e.g. by results_query), implying usage context. But there is no explicit when-to-use versus results_list/results_query/results_sample, and no stated preconditions such as the result_id having to originate from this session's prior query.

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

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

The description declares a delete ('Delete one result stored in this session'), but the annotations declare readOnlyHint=true and destructiveHint=false. A removal operation is a state mutation, so the description directly contradicts the structured safety profile. It also fails to disclose whether the drop is reversible or what happens on a repeated drop of the same id.

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

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

Two short sentences with no filler; the destructive action is front-loaded and the return behavior follows. Nothing is padded or repeated from the schema.

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

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

With no output schema, the description does supply the return signal ('whether it was dropped'), which is useful. But for a deletion tool with contradictory annotations, it omits irreversibility/undo semantics and the behavior of dropping an already-dropped id, leaving real gaps.

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

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

There is a single parameter with 100% schema description coverage; the schema already documents the result_id format and example pattern. The description adds no parameter-level meaning 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 verb and resource ('Delete one result') plus a scope qualifier ('stored in this session'), which is enough to separate it from results_list/results_query/results_sample. It does not, however, explicitly name or contrast itself with any sibling, 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?

The description says what the tool does but never says when to reach for it versus results_list, results_query, results_describe, or results_sample, nor whether the result must be re-created afterwards. No usage context or exclusions are given.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description still adds real behavioral value beyond them: the sort order ('newest first') and the exact set of fields returned, which is important because there is no output schema.

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

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

A single front-loaded sentence with a colon-delimited field list; nothing is wasted and the key action and ordering come first. The field enumeration is dense but justified since no output schema exists to carry that 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?

For a zero-argument, read-only list tool, the description covers purpose, ordering, and return fields, which compensates for the absent output schema. It does not mention pagination limits or how long the session's result set persists, which is a minor gap given the 'created and expiry time' field.

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

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

The tool takes no parameters (empty NoArgs schema, 100% coverage), so by the rubric this is a baseline 4. The description correctly adds no parameter detail because there is nothing to document.

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 ('List') plus resource ('results stored in this session'), with scope and ordering ('newest first') and an enumeration of returned fields. It clearly distinguishes the read-only inventory role from siblings like results_query and results_sample, though it never names them outright.

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

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

Usage is implied by 'the results stored in this session' and 'newest first', which signals an inventory/discovery use case. However, it gives no explicit when-to-use guidance and does not route the agent between results_list, results_query, results_sample, or results_describe.

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?

Goes well beyond the annotations by disclosing the row cap and the silent lowering of oversized LIMITs, the fact that large answers or store=true are materialized as a NEW result returned by result_id, and the exact refusal boundary. This side effect (a read that can create a new stored result) is precisely the kind of behavior annotations alone would hide.

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

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

Three dense sentences, front-loaded with what the tool is, then return behavior, then the refusal boundary. No filler; every clause carries operative 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?

With no output schema, the description carries the return-value burden and does so: row count semantics, result_id for stored answers, and the scope of what is queryable and refused. An agent has everything 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 100% and the schema already documents sql, store and max_rows (including the default and 200 cap). The description restates these limits rather than adding new semantics, 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 verb (run ONE read-only SQL SELECT), the exact dialect (DuckDB) and constructs allowed, and the resource model (each result_id is a table name). An agent can distinguish it from results_list, results_describe and results_sample purely from the description.

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?

Clearly frames the operating context: query results already stored in this session, with explicit refusals (files, settings, other sessions, writes). It does not explicitly name a sibling alternative or say when to prefer results_list/results_sample over SQL, so routing guidance is implied rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description still adds real context beyond them: the 'repeatable random sample' (determinism of randomness), the 1-50 bound, and the fallback to storage order when no time column exists.

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

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

A single dense sentence with the core action front-loaded and the modifiers (method, n bound, column subsetting) trailing in priority order. No filler or redundancy.

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

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

For a four-parameter, read-only tool with no output schema, the description conveys the essential shape of the result (n rows, optionally a column subset). It does not describe ordering guarantees or how the sample relates to the underlying result_id, but nothing critical for calling it correctly is missing.

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

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

Schema coverage is 100%, so n, method, columns, and result_id are already documented in the schema, making 3 the baseline. The description's only marginal addition is that the random method is repeatable, a nuance the enum label 'random' does not convey.

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 (Show) and resource (n rows of a stored result) with the sampling scope spelled out (first/last/random, optional column subsetting). It reads clearly as a preview/sampling tool, distinguishing it from full-query siblings like results_query and results_describe without needing to name them.

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

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

Usage is implied by 'Show n rows ... of a stored result', which signals a preview/sampling purpose, but there is no explicit when-to-use guidance or routing to alternatives such as results_query. The agent must infer that this is for inspection rather than full data retrieval.

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