kwant

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

Without annotations, the description carries the full burden and it does well: it discloses no-lookahead (next bar's close), long-only constraint, return types (trades + metrics), and paid cost. It still leaves out details like minimum data history or error handling, but the provided context is substantial.

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

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

The description is a single dense sentence that front-loads the main action, then packs strategy details, no-lookahead behavior, output summary, and pricing into efficient clauses. No waste 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?

With no output schema and no annotations, the description covers behavior, outputs, and cost, but lacks details on performance metric names, behavior with insufficient data, and the purpose of 'params'. It is comprehensive for a moderately complex tool but not fully 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 0%, so the description must compensate. It explains the strategy enum values (SMA 50/200, RSI thresholds, MACD vs signal) and ticker is obvious, but the 'params' object (additionalProperties) is left unexplained, and 'range' is only self-explanatory via its enum values. Partial compensation with a notable gap.

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

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

The description clearly states it backtests a simple long-only technical strategy on daily price history, names specific strategies, and indicates outputs. This distinguishes it from portfolio-level backtesting tools like run_portfolio_backtest.

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 provides clear context: long-only, daily price history, and strategy options. It doesn't explicitly mention when not to use it (e.g., for portfolio-level backtests) or name alternatives, but the scope is logically 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?

With no annotations provided, the description carries the full burden and does so thoroughly: it discloses the resampling aggregation (open=first, high=max, low=min, close=last, volume=sum), the skip behavior for failed/incomplete tickers, the ranking method, and the return structure. It even includes pricing.

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

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

The description is a single dense paragraph that front-loads the core purpose and then systematically details method, parameters, and output. It is longer than minimal but every sentence contributes necessary context for a complex tool; no fluff.

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

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

Given no output schema, the description explains the return object thoroughly (range, as_of, count, results with fields). It also covers the skip/warning behavior and range guidance. The only missing piece is the full semantics of the resample parameter and defaults for non-range parameters, but overall it is highly 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 description coverage is 0%, so the description must explain all parameters. It covers range, universe, tickers, and top_n well, but does not explain the resample parameter's effect when set to 'Q' — it only states monthly resampling, which is incomplete given the schema allows 'M' or 'Q'. Defaults for top_n and universe are also omitted.

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+outcome: 'Rank a universe of tickers by monthly dollar volume with trailing returns.' It clearly distinguishes itself from siblings like screen by focusing on monthly resampling and ranking, and details the exact output structure.

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

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

The description implies usage by defining the available universe options (SP500, TSX, or explicit tickers) and gives an explicit practical guideline: use a multi-year window for the 12-month horizon. It does not explicitly name alternatives or when-not-to-use, but the 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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It openly states that unresolvable or history-insufficient symbols are skipped and reported in 'warnings', and that rank 1 = best. It also surfaces pricing. However, it does not clarify how 'best' is interpreted for each metric (e.g., lower volatility vs. higher return), which is a notable gap.

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

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

The description is two tight sentences plus a pricing parenthetical, with no fluff. The first sentence states the core action and metric list, the second covers error handling and output structure, and the pricing note is informative. 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?

Given no output schema and no annotations, the description adequately covers the return shape (list of {ticker, value, rank, currency}), the skip/warning behavior, and the ranking definition. It falls short only on defining per-metric 'best' and leaving the range parameter semantically open, but overall the tool is sufficiently described for a competent agent.

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

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

The schema has 0% coverage, so the description must add meaning for parameters. It does clarify the 'metric' parameter by listing its allowed values and the 'tickers' parameter by requiring at least two and explaining skip behavior. However, the 'range' parameter is entirely unexplained, and the description does not elaborate on how range interacts with the metric or the rankings.

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 ('Rank') and resource ('two or more tickers') with a clear scope: ranking by a single metric. It lists the allowed metrics and explicitly describes the output format, distinguishing it from sibling tools like compute_stats or screen, which have broader or different purposes.

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

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

The description implies usage when comparing multiple tickers by a metric, but it does not explicitly mention when not to use the tool or provide alternative tool names. Sibling tools like screen or compute_stats have overlapping capabilities, and no exclusions or fallback guidance 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?

With no annotations, the description fully discloses the process (fetching, return conversion, Pearson correlation, date alignment), failure handling (dropping fetch-failed tickers, requiring at least two survivors), output structure, and even cost. This exceeds typical transparency expectations.

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?

Every sentence earns its place: the purpose, the process, the constraints, the output format, and the cost are all compactly stated in three sentences. The most critical information is front-loaded, and no waste is present.

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

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

Given the lack of output schema and annotations, the description thoroughly covers the return envelope, matrix structure, diagonal, range, tickers used, and edge-case behavior. It is self-contained for safe invocation and result interpretation.

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

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

The schema provides no descriptions (0% coverage), so the description must add meaning. It explains that 'tickers' requires at least two and clarifies that some may be dropped, and 'range' is used for the daily history window. However, it does not specify the default behavior when 'range' is omitted or detail each enum value's implications, leaving some gaps.

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 begins with a specific, action-oriented verb ('Compute') and names the exact resource ('pairwise return-correlation matrix') and input ('list of tickers'), clearly distinguishing it from sibling tools like single-ticker stats calculators or portfolio metrics.

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 purpose sentence establishes a clear context for use (computing correlations between tickers), but it does not explicitly mention when to avoid this tool or name alternatives. The guidance is implied, not explicit, 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?

With no annotations provided, the description carries the full burden and does an excellent job. It discloses the return content (warmup-aligned series, latest values, summary), parameter aliases, default length of 20, the all-warmup NaN pitfall when range is too short, response echoing of effective params, and the paid cost per call. This is far more transparent than typical tool descriptions.

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?

Though the description is long, every sentence contributes operational value. It is well-organized: purpose, return value, parameter tuning, aliases, warnings, and cost. The front-loaded purpose makes it easy to scan, and the complexity of the tool justifies the length.

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

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

Given the tool's complexity (15 parameters, 8 indicators, no annotations, no output schema), the description covers behavior, parameters, and common pitfalls thoroughly. It lacks explicit response field names and does not clarify `interval` semantics, but the provided guidance is sufficient for an agent to select and invoke the tool correctly in most cases.

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

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

Schema description coverage is 0%, so the description must compensate. It does so by mapping parameters to indicators (length for SMA/EMA/RSI/ATR/ADX/BBANDS), explaining MACD/BBANDS/STOCH parameters, aliases, and nested params flexibility. The only notable gap is the `interval` parameter, which is not explained in the description despite being 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?

The description opens with a specific verb and resource: 'Compute a technical indicator' and explicitly lists supported indicators (RSI, MACD, SMA, EMA, BBANDS, ATR, ADX, STOCH). This clearly distinguishes it from sibling tools like compute_correlation_matrix or detect_signals, making the tool's purpose immediately obvious.

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 provides clear context for when to use the tool: when a technical indicator over a ticker's price history is needed, and includes detailed guidance on parameter tuning, aliases, and range requirements. However, it does not explicitly mention when not to use this tool or point to alternatives, so it stops short of full usage differentiation.

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

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

With no annotations provided, the description carries the full burden. It discloses critical behaviors: weights are normalized internally, unfetchable tickers are dropped with warnings and renormalization, risk_free_rate only affects Sharpe, and the output envelope contains range, normalized weights, and stats. It also mentions the per-call cost, which is useful operational context.

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 moderately long but each sentence adds value: purpose, input format, normalization behavior, error handling, parameter semantics, and output structure. The pricing note is extra but acceptable. It is front-loaded with the main purpose and then details, without 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?

Given the tool has no output schema, the description adequately explains the return envelope: it holds the range, normalized weights, and stats dict, and the metrics were already listed earlier. It also covers edge cases (dropped tickers) and parameter effects, making it self-sufficient for an agent to invoke 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 0%, so the description must explain all parameters. It does so: 'weights' is described as a {ticker: weight} mapping, 'range' is used to fetch daily history (with an enum in schema but no meaning), and 'risk_free_rate' is specified as an annual rate used only by Sharpe. This fully compensates for the schema's lack of 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 clearly states the tool computes portfolio-level statistics for a weighted basket of tickers, and explicitly contrasts this with per-ticker statistics ('not per-ticker'). It lists the specific metrics (volatility, Sharpe, max drawdown, total return) and the resource (weighted basket), making it distinct from sibling tools like compute_stats.

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

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

The description provides clear context for when to use the tool: for a weighted basket of tickers rather than individual tickers. It also gives key usage details like weights not needing to sum to 1 and the role of risk_free_rate. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of a 5.

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

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

With no annotations, the description discloses the paid cost ($0.0050/call), default metric behavior, and dependency between metrics and benchmark/risk_free_rate. It does not mention error behavior or output format but covers the key behavioral caveats.

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 pack all essential information without fluff, front-loading the core purpose. The parenthetical details are efficiently structured.

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

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

The description covers the necessary usage nuances for a 5-param tool with no output schema, leaving obvious parts (range, output shape) implicit. It's sufficient for an agent to invoke correctly for most cases.

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

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

The schema has no descriptions, so the description adds crucial semantics: default metrics, benchmark requirement for beta/correlation, and the role of risk_free_rate. It doesn't explain range, but the enum values are self-explanatory.

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

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

The description clearly states it computes quantitative statistics (volatility, sharpe, max_drawdown, returns, beta, correlation) over a ticker's daily price history, distinguishing it from portfolio-level or indicator tools. It lists the specific metrics available, making it 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?

It explains when to omit metrics for defaults, that beta and correlation require a benchmark, and that risk_free_rate only affects Sharpe. This gives clear parameter-level guidance, though it doesn't name alternative tools explicitly. The pricing note also helps with cost-aware decisions.

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

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

With no annotations provided, the description carries the full burden and does well: it discloses the full pipeline (resolve universe, fetch prices, compute raw scores, convert to z-scores, rank), warns about dropping tickers with insufficient history or fetch failures, reports warnings, describes the output structure, and even states the pricing. It does not explicitly state read-only safety or authorization needs, but the described behavior is thorough for a computational tool. This exceeds a 3, though not a 5 due to a few omissions (e.g., default universe behavior).

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

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

The description is front-loaded with the primary purpose, then systematically explains process, signals, parameters, and output. It is lengthy due to the necessary signal definitions, but every sentence adds value. No filler or redundancy is present, making it appropriately concise for the tool's complexity.

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

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

Given the tool's complexity (5 parameters, 3 enums, no output schema, no annotations), the description is highly complete: it explains the algorithm, signal definitions, parameter semantics, output structure, and edge-case handling (dropping tickers). Minor gaps remain, such as unspecified defaults for 'universe' and 'top_n' and no explicit statement about what happens when neither universe nor tickers is provided. Overall, it is thorough and well above the minimum viable.

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 all parameter meaning, and it does. It explicitly defines 'range' with its enum values and default, explains 'top_n' as truncating output, describes 'universe' as either SP500 or TSX, and provides detailed definitions for each 'signal' enum value. It also covers the relationship between 'tickers' and 'universe' (override). This fully compensates for the lack of schema-level 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 opens with a specific verb+resource: 'Score and rank a universe of tickers by a cross-sectional signal.' It clearly defines the tool's function, differentiates it from individual indicator tools by mentioning cross-sectional scoring and ranking, and specifies the output ordering (rank 1 = highest z-score). This is unambiguous and distinguishes it from siblings like compute_indicator or compute_stats.

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

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

The description implies context (use when you need to cross-sectionally rank a universe) and details how the tool resolves universes and signals, but it does not explicitly state when to use this tool over alternatives or list exclusions. Sibling tools like screen_with_scores or compare_tickers could overlap, but no explicit guidance or named alternatives are provided. This is clear context without exclusion guidance, matching a 3.

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

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

With no annotations, the description carries the full burden. It discloses that some methods fetch daily history, that failed tickers are dropped with a warning, and describes the output envelope. This is thorough and goes beyond a simple purpose statement.

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

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

The description is compact and front-loaded: it opens with the core purpose, then lists methods and behaviors, and ends with output and pricing. Every sentence contributes value, and the structure is logical.

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

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

The description covers input, methods, data fetching, failure handling, and output. It does not explain optional parameter defaults or which methods require top_n or range, leaving minor gaps for a tool of this complexity.

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

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

Schema coverage is 0%, so the description must explain parameters. It explains scores, method (with each option), and range (listing valid values). However, top_n is only mentioned as an output field, not explicitly defined as an input controlling selection, leaving a partial gap.

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

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

The description clearly states the tool's purpose: converting a ticker-score mapping into long-only portfolio weights with non-negative weights summing to 1.0. It lists specific methods, distinguishing it from sibling tools like compute_portfolio_stats or backtest.

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

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

The description provides clear context: it is for when you have a score mapping and want portfolio weights. It does not explicitly exclude alternatives or say when not to use it, but the input/output specification makes the use case evident.

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

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

No annotations are provided, but the description discloses crucial behavior: signals are returned as triggered/not-triggered under signal_summary, insufficient history results in a not-triggered status with a warning rather than a failure, and call pricing. This fully compensates for the missing annotations.

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

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

The description is a single well-structured paragraph, front-loaded with the core purpose, followed by detailed signal definitions and behavior. No redundant sentences; the pricing note is useful and 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 explains the return experience (signal_summary with triggered/not-triggered, date, detail). It also covers edge-case behavior (insufficient history) and pricing. This is a complete specification for a tool with 5 parameters and 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 0%, so the description carries the burden. It defines each signal precisely and clarifies that `lookback` scopes the golden/death cross checks. It does not explain `range` or `interval`, but their enum values are self-explanatory, and the most complex parameters are thoroughly addressed.

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 ('Detect') and resource ('classic technical-analysis signals on a ticker's price history'), listing six concrete signals. This clearly distinguishes it from siblings like get_price_history or compute_indicator, which are about raw data or single indicators.

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 provides clear usage context: 'Each requested signal is evaluated and reported as triggered/not-triggered' and 'Signals (omit `signals` to check all six)' tells the agent how to parameterize the request. However, it does not explicitly name alternative tools for exclusion, so it isn't 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?

With no annotations provided, the description carries the full burden and does an excellent job. It discloses the return envelope fields, null-handling for unavailable data, symbol format requirements, and pricing, providing comprehensive behavioral context.

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 three sentences, each serving a distinct purpose: stating the tool's function, listing output fields, and noting nulls and cost. It is concise, front-loaded, and has no redundant 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?

Even without an output schema, the description thoroughly explains the return envelope and its fields, as well as the behavior for missing fields. It also covers the input symbol variations and cost, making it complete for a single-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?

The schema provides no description for the ticker parameter, but the tool description fully compensates by explaining exact formatting rules: US symbols are bare (AAPL) and TSX symbols use .TO or TSX:RY form. This is critical information that goes far beyond the schema.

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

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

The description clearly states 'Get fundamental data for a ticker (profile + key ratios)', specifying the action and resource. This distinguishes it from siblings like get_quote and get_price_history, which focus on different data types.

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

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

The description implies usage by stating what data it returns, but does not explicitly mention when to use it over alternatives or provide any exclusionary guidance. It lacks direct comparison to sibling tools, so the usage context is only implicit.

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

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

With no annotations provided, the description carries the full burden. It discloses the return envelope structure, parameter defaults, accepted ticker formats, and cost per call. It does not mention error handling or data adjustments, but these are not critical for a read-only historical data tool.

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

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

The description is compact and well-structured, starting with purpose, then parameter specifics, return format, and cost. Every sentence adds useful information without redundancy or fluff.

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

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

Given no output schema and moderate complexity, the description fully explains the response envelope, parameter options with defaults, and symbol conventions. It is self-contained, allowing an agent to invoke the tool correctly without needing additional context.

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%, and the description effectively documents all parameters. It explains ticker formatting, enumerates interval and range values (matching the schema enums), and adds default values, going beyond the raw 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?

Clearly states it retrieves historical OHLCV price bars for a ticker. Explicitly describes the scope (historical) and distinguishes from siblings by focusing on price history rather than quotes or fundamentals.

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

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

Provides clear context about the tool's purpose and output, but does not explicitly contrast with alternatives like get_quote or compute_indicator. However, the description of OHLCV data and parameter defaults strongly implies when it should be used.

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

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

With no annotations, the description carries the full burden. It discloses the return envelope structure, lists the quote fields, mentions the data source (Yahoo forms), and includes pricing. It does not explain error behavior or data delays, but for a simple read-only quote tool it is reasonably transparent.

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

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

The description is concise: three sentences covering purpose, ticker format, and return envelope, plus a cost note. Every sentence adds value, and the most important information (what it does) is front-loaded.

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

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

For a single-parameter tool with no output schema, the description is complete. It explains the return fields and the only parameter's semantics. The pricing disclosure is a nice extra. No critical information is missing for a simple quote lookup.

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

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

The schema provides zero description for the ticker parameter. The description compensates fully by explaining ticker formats for US and TSX symbols, including concrete examples (AAPL, RY.TO, TSX:RY), which is essential for correct invocation.

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

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

The description clearly states the tool gets the latest available quote for a ticker, using a specific verb and resource. It distinguishes itself from sibling tools like get_price_history (historical) and get_fundamentals (fundamentals) by focusing on 'latest available quote'.

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

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

The description provides clear context for when to use the tool (when you need the latest quote) but does not explicitly mention alternatives or when not to use it. It gives practical formatting guidance for tickers, which is useful for correct usage.

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

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

With no annotations provided, the description takes on the burden of detailing behavior. It discloses lookahead prevention ('using only data up to that date'), cost handling, the crash filter mechanism, and the return envelope contents. It also notes the paid cost. Some behaviors like rate limits or error conditions are not mentioned, but the core operational behavior is well covered.

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

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

The description is dense but every sentence adds value. It front-loads the main purpose and follows with mechanics and parameter meanings. The structure is a single paragraph, which could be slightly more scannable with bullet points, but remains effective.

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 complex tool with 9 parameters and no output schema, the description covers the algorithm, key parameters, and output keys. It misses a clear explanation of top_n and some method details, but overall it gives the agent enough to select and invoke the tool appropriately.

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

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

The description explains several parameters (rebalance, cost_bps, benchmark, crash_filter, signal) but omits top_n and does not enumerate method options. Since schema description coverage is 0%, the description needs to compensate more fully; it partially does but leaves gaps for a few parameters.

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

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

The description clearly states the tool's purpose: 'Backtest a rebalanced, multi-ticker, long-only quant portfolio.' It specifies the walk-forward simulation, rebalancing, and output metrics, distinguishing it from sibling tools like the simpler 'backtest.'

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

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

The description provides clear context on when to use this tool, such as for multi-ticker rebalanced portfolios with specific signals and methods. However, it does not explicitly state when not to use it or mention alternatives like 'backtest' as a simpler option.

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

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

No annotations are provided, so the description carries full burden. It discloses the logical AND operator and the per-call cost, but it does not describe the return format, sorting behavior, handling of empty results, or whether the operation is read-only. The description largely restates schema enums rather than adding deeper behavioral context.

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

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

The description is a single, front-loaded sentence stating the action, then listing fields and operators compactly. It includes the cost note efficiently. The only minor waste is repeating enum values already present in the schema, but overall it is well-structured and concise.

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

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

Given the tool's complexity (5 parameters, nested objects, no output schema) and zero annotations, the description is incomplete. It covers filter semantics but omits return structure, sorting, and universe selection details. Without an output schema, the agent cannot infer what the tool returns (e.g., tickers vs. full objects), and the relationship to 'screen_with_scores' is unclear.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning to the 'filters' parameter by listing allowed fields and operators and clarifying the AND conjunction. However, it does not explain 'range', 'sort_by', 'max_tickers', or the 'universe' parameter beyond their enum values, leaving some semantics implicit.

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?

Description explicitly states it screens a stock universe for tickers matching quantitative filters with logical AND, and lists the exact fields and operators. This is a specific verb+resource+scope, but it does not differentiate from the sibling tool 'screen_with_scores' or other screening-related tools.

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

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

The description implies usage for quantitative filtering of a stock universe, and the paid note ('$0.0100/call') is a practical cost consideration. However, it gives no explicit guidance on when to use this tool versus alternatives like 'screen_with_scores' or 'compute_universe_scores', nor any 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?

With no annotations, the description carries the behavioral disclosure burden. It usefully adds that scores are relative to the scanned set and reveals a per-call cost, but it does not describe the return format, pagination, or behavior of parameters like top_n and max_tickers.

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 three concise sentences, front-loaded with the core action and followed by essential details (signals, relative scoring, cost). Every sentence adds information without redundancy or filler.

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

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

The tool has no annotations and no output schema, so the description should cover output behavior, but it does not explain what the returned ranking looks like or the difference between top_n and max_tickers. Core purpose and signal list are present, but parameter semantics and return behavior are incomplete.

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

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

Schema description coverage is 0%, so the description must compensate. It only enumerates the signal choices and mentions 'stock universe,' but it does not explain range, top_n, max_tickers, or how they interact. The parameter names and enums provide some self-evident meaning, but the description adds little beyond the schema.

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

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

The description clearly states the tool's purpose with a specific verb ('Rank'), a resource ('stock universe'), and the exact ranking semantics ('rank 1 = highest z-score'). It also lists the supported signals, which distinguishes it from generic screens or score computations.

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

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

The description implies the tool is used when you need a cross-sectional signal-score ranking of a universe, but it does not explicitly state when to prefer it over sibling tools like 'screen' or 'compute_universe_scores'. No exclusionary or alternative guidance is provided.

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