Backtest360

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

No annotations are provided, so the description fully carries the burden. It discloses quota counting, scaling behavior, timeout failure mode, error structure for 400/422, and return format including relative metrics for benchmarks. This is comprehensive.

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 well-structured with a clear purpose statement, paragraphs for behavioral notes, and a bullet-like Args section. Every sentence provides valuable information without unnecessary 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?

Given the tool's complexity (5 params, nested objects, output schema), the description covers all aspects: purpose, usage constraints, parameter details, return schema, error handling, and scaling behavior. It is fully complete for agent 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 coverage is 0%, so the description provides all parameter details. It describes each parameter including the complex 'strategies' array structure, default values, and enum for response_detail. This adds substantial meaning 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?

The description clearly states 'Run several strategies on the same data and compare side by side.' It uses a specific verb (compare) and resource (backtests), and distinguishes itself from siblings like run_backtest by noting it handles multiple strategies in one call.

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

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

The description provides explicit guidance on timeout handling, retry advice, and notes that the call counts as one quota but compute scales. However, it does not explicitly mention when not to use it (e.g., for a single strategy) or suggest alternatives like run_backtest, which would make it 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?

Without annotations, the description carries the full burden. It discloses that a wrong 'trading_days_per_year' silently mis-annualizes metrics, and that the returned metric set depends on the API key's plan. It doesn't mention mutation or side effects, but the tool appears to be read-only, which is adequately implied.

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 well-structured with 'Args' and 'Returns' sections, and each bullet is focused. It is concise for the amount of detail, though splitting into subsections could improve scanability slightly. No superfluous text.

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 5 parameters (2 required), nested objects, and an output schema. The description covers all parameters, explains return shape ('{"stats": {...}}'), and references 'get_catalog' for metric details. It is complete for a non-trivial computation 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 0%, so the description must compensate, which it does thoroughly. It defines the 'returns' format with 'dates' and 'values' arrays, explains 'trading_days_per_year' with examples (252 for equities, 365 for crypto), describes 'benchmark_returns' shape, and lists fields for 'trades'. This adds critical meaning beyond the schema.

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

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

The description clearly states 'Compute the engine's performance metrics from a returns series,' specifying the verb, resource, and input. It distinguishes the tool from the sibling 'run_backtest' by noting that backtest results already include these statistics.

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 explicitly says to use this tool when returns came from somewhere other than run_backtest (external system, portfolio), and not to use it when returns come from run_backtest since those already include statistics. This provides clear when-to-use and when-not-to-use guidance, referencing an alternative.

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?

Discloses that the tool is free and not quota-counted, which is valuable context beyond the missing annotations. It implies non-destructive behavior and appropriate usage frequency.

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

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

Two short, front-loaded sentences with no waste. Every piece of information serves a purpose.

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 zero parameters and the presence of an output schema, the description fully covers what an agent needs: purpose, usage, and behavioral notes.

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?

No parameters exist (schema coverage 100%), so baseline is 4. The description correctly omits parameter details, adding no unnecessary information.

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 returns engine version, API contract number, and health. It uses specific verbs and resources, and is easily distinguishable from sibling 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?

Explicitly advises calling once at session start to confirm reachability and contract, providing clear when-to-use guidance and distinguishing it from other 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?

Despite no annotations, the description discloses all behavioral traits: quota-counted, plan restriction, base64 encoding, error types (403, 400/422, tool errors), and size limit with resolution. This fully informs the agent of side effects and failure modes.

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 well-structured with a summary, quota/plan note, args list, and returns section. It is front-loaded with the main purpose and every sentence adds value. No 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?

The description covers usage context, error handling, output format, and size limit workaround. It references sibling tools for parameter shapes, which is acceptable given their existence. Missing details about the exact structure of 'data_source' and 'strategies' are minor 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?

With 0% schema coverage, the description adds meaning for all three parameters by explaining their roles and referencing sibling tool shapes (e.g., 'same shape as run_backtest'). It does not detail nested object structures, but the cross-references are helpful for agents familiar with those tools.

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 action 'Export a multi-strategy comparison as an Excel workbook', using a specific verb and resource. It distinguishes from similar tools like 'compare_backtests' (comparison object) and 'run_backtest' (single run) by specifying the output format and multi-strategy 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?

The description provides explicit guidance on quota counting, plan requirements, and 403 handling ('do not retry'). It also advises narrowing the request on size errors. However, it does not explicitly compare with siblings like 'compare_backtests' or state when to choose this tool over returning 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?

Describes catalogs as 'cheap, cacheable per session', indicating they are inexpensive and safe to call repeatedly. No annotations exist, so the description carries the burden; it could mention response format or idempotency but provides useful 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 uses a clear structure with a bold opening sentence and bullet points for each catalog. While it is somewhat lengthy, every sentence and bullet adds value, justifying 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?

For a simple tool with one parameter and an output schema, the description covers all enum values, provides usage context, and includes behavioral notes. No gaps are apparent given the tool's complexity.

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

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

The single parameter 'catalog' is an enum with no schema descriptions (0% coverage). The description compensates fully by listing all seven enum values with detailed explanations of each, far exceeding what the schema 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 clearly states 'Fetch one engine reference catalog' and lists all seven specific catalog types, distinguishing it from sibling tools like compare_backtests or compute_stats which perform different operations.

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?

Explicitly advises to 'Fetch the relevant catalog BEFORE building a strategy or config' and instructs to 'build only from values it lists — never guess parameter names or frequencies', providing clear when-to-use and how-to-use 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?

Since no annotations are provided, the description carries full burden. It discloses that the tool is 'available on paid plans' and that it should be called before fetching. It implies the tool is a read-only metadata query with no side effects, which is sufficient 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 two sentences long, front-loaded with the tool's purpose, then the usage guideline. Every sentence provides unique information with 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?

The description covers the tool's purpose, when to use it, and key behavioral traits. However, with no parameter explanations and 0% schema coverage, it is incomplete for a tool requiring two untyped string parameters. The presence of an output schema mitigates the need to describe return values.

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%, yet the description does not explain the parameters beyond their names ('symbol', 'frequency'). It adds no details about valid values, formats, or constraints, which would be 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 returns 'available date range and estimated bar count for a symbol/frequency.' It specifies the exact resource (date range and bar count) and verb (get), and differentiates from sibling tools like get_price_history or get_quote by emphasizing its role as a pre-fetch check.

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 explicitly says 'Call before a server-side fetch' and explains the purpose: to ensure the requested start/end stay within provider's delivery and bar count within per-run limit. This gives clear when-to-use guidance, though it does not mention when not to use or alternative 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?

Discloses that it operates on the most recent bar only, no P&L, and no stats. Given no annotations, this is good but could mention side effects or read-only nature.

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, front-loads the core purpose, and uses a clear pattern to differentiate from run_backtest. 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?

Despite having 4 complex object parameters and no schema descriptions, the description offers no parameter guidance. It is incomplete for an agent to correctly invoke the 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 has 4 parameters with 0% description coverage. The description does not explain any parameters or their structure, leaving agents to guess how to provide strategy, execution, data_inputs, or data_source.

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

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

The description states it evaluates the strategy on the most recent bar only, returning the latest signal (-1/0/1), condition slots, and timestamp. This clearly distinguishes it from siblings like run_backtest and compare_backtests.

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?

Explicitly says 'Use for "what would this strategy do right now" questions; use run_backtest for performance.' This provides clear guidance on when to use this tool vs. alternatives.

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

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

With no annotations provided, the description carries full burden. It discloses that the data is free, returns observations at native frequency, includes series descriptor and as_of date, and downsamples long histories with markers. Crucially, it warns that values are latest revised figures, not point-in-time, which is a key behavioral trait for a data retrieval 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 somewhat long but front-loaded with the core purpose. Each sentence contributes value: purpose, free access, parameter constraints, downsampling behavior, and a note about revised figures. While a bit verbose, it is well-structured without 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?

Given that an output schema exists (stated in context), the description appropriately covers the tool's purpose, parameters, behavior (downsampling, frequency), and data characteristics (revised figures). It provides sufficient context for an agent to use the tool correctly without needing additional documentation.

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 add meaning. It explains that series is an id from list_macro_series with examples, and describes start/end as dates in YYYY-MM-DD format, optional, inclusive. This provides essential context beyond the schema's type and default 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?

The description clearly states the verb 'get' and the resource 'macro series' with constraints: one series over an optional date range. It distinguishes from sibling tools like list_macro_series (which lists series) and other data retrieval tools by specifying the unique purpose of fetching observations for a single macroeconomic 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?

The description explains that the tool is free and that the series parameter must be an id from list_macro_series, with examples. It notes that start/end are optional and the date format. However, it does not explicitly state when to use this tool versus alternatives like get_price_history for stock data, though the context implies the 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?

The description details the return structure (scopes, limits, usage, capabilities) and notes it's a 'small fixed-shape record' returned as sent. While it implies read-only behavior, it doesn't explicitly state non-destructiveness, but the cost indication ('Cheap') provides some transparency.

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) and front-loaded with the core purpose. Every sentence provides unique information: purpose, usage advice, and return field details.

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 parameters, the description fully covers what the agent needs: purpose, when to call, and the exact fields returned. The output schema existence further supports complete 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?

With zero parameters and 100% schema coverage, the description does not need to explain inputs. It uses the space to clarify the output structure, adding value 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 returns 'the configured API key's permissions, limits, and current usage.' This is a specific verb-resource pair, and it distinguishes itself from sibling tools like get_quote or engine_info by focusing on authentication context.

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

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

It explicitly advises to 'call early in a session — before planning work' to avoid failed calls, providing clear when-to-use guidance. No alternatives or exclusions are needed due to the tool's unique role.

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

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

No annotations are provided, so the description carries the full burden. It extensively discloses behavioral traits: downsampling behavior (first/last bar always kept, thinning on same dates), return structure (summary, market-hours, OHLCV arrays), plan cap, and bounded window. This is comprehensive for a price history 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 a single dense paragraph that covers all essential aspects without waste. While it could be more structured (e.g., bullet points), it remains concise and front-loaded with the core purpose.

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 an output schema exists, the description need not detail return values exhaustively. It still provides sufficient context: mentions summary, market-hours, OHLCV arrays, downsampling info, and plan cap. This is complete for an agent to understand the tool's behavior and output.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for start (YYYY-MM-DD), end (defaults to today), and symbol (implicit). However, the frequency parameter is not mentioned despite having a default of 'daily'. This is a minor gap but overall helpful.

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 provides 'OHLCV price history for a symbol over a date range', using a specific verb-resource combination. It distinguishes from siblings like get_quote (single snapshot) and get_data_range (sizing helper) by mentioning that the window is bounded and to 'call get_data_range first to size a request'.

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 when to use the tool (for OHLCV history), provides format for start (YYYY-MM-DD) and default for end (today), and mentions the prerequisite of a paid plan and the need to call get_data_range first. It does not explicitly state when not to use, but the context is clear enough.

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 provided, but description explains it returns a last-known price (not live tick), how frequency affects the bar, and the role of as_of timestamp. Could mention rate limits or error 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?

Short paragraph with front-loaded purpose. Every sentence adds value. Clear and scannable.

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?

Output schema exists, so return values are covered. Explains inputs and behavorial nuance. Could mention error cases for invalid symbols.

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

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

Adds meaning beyond the schema: explains symbol is required, frequency defaults to daily, and how frequency changes the returned bar (end-of-day vs. last completed). Schema had 0% description coverage.

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

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

Clearly states it returns the latest available price for a symbol with OHLCV and as_of timestamp. However, it does not differentiate from sibling tool get_price_history.

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?

Mentions requirement of a paid plan and explains frequency behavior. No explicit guidance on when to use vs. alternatives like get_price_history or ticker info.

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 provided, but the description adequately implies a read-only operation by stating 'get' and describing the return value. It does not mention side effects or auth, but for a schema retrieval tool, this is sufficient.

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 concise sentences with no redundancy. The first sentence clearly states the tool's purpose, and the second provides actionable usage context.

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

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

Given the tool's simplicity (no parameters, has output schema), the description adequately covers what the tool returns, its purpose, and how it relates to validate_strategy. No 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?

The tool has zero parameters, so the description does not need to add parameter info. The schema coverage is 100%, meeting the baseline for no 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 that the tool returns a JSON Schema for the strategy document, specifically covering condition_tree and indicators. The verb 'get' aligns with the name, and no sibling tool serves this exact purpose.

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?

Explicitly advises fetching this schema before manually composing a strategy and points to validate_strategy as the complementary tool for validation. Provides clear context for when to use 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?

No annotations provided, so description carries full burden. It clearly states metadata-only, no market data, no cost, and describes return fields (identity, coverage summary). Does not claim any destructive behavior, and the read-only nature is clear.

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?

Single paragraph, every sentence adds value: purpose, cost implication, return structure, usage guidance, sibling reference. Front-loaded with key info, 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?

Given output schema exists, description covers return values adequately (identity fields and coverage summary). Missing error handling or behavior for invalid symbols, but for a metadata tool this is sufficient. Sibling differentiation helps completeness.

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%, meaning description does not explain the parameters. While 'symbol' is self-explanatory, 'frequency' is not described (valid values, effect). Description mentions 'for a given frequency' but lacks detail to compensate for missing schema 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?

Description clearly states verb+resource: 'Identity and data coverage for one symbol'. It distinguishes from sibling tools like 'get_data_range' and implies use before quote/price fetch. Specific and actionable.

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?

Explicitly states when to use ('confirm a symbol resolves... before requesting a quote or a price fetch') and mentions metadata-only with no paid plan. Names an alternative tool ('get_data_range') for precise range, providing good context.

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 fully discloses behavioral traits: cheap and cacheable per session, return format differences between compact and full modes, truncation behavior indicated by 'truncated_by_mcp', and wire optimization that requests descriptions conditionally. This gives the agent a clear understanding of side effects and internal 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 detailed and well-structured with clear sections, code blocks for return shapes, and front-loaded purpose. However, it is somewhat verbose, with the wire optimization paragraph being somewhat technical and possibly unnecessary for most uses. Every sentence does add value, but a slightly shorter version would be ideal.

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

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

For a tool with two parameters and no output schema, the description covers all relevant aspects: what is returned in each mode, how to use arguments, edge cases like truncation and case-insensitivity, and best practices. It leaves no ambiguity about the tool's behavior and is complete for an AI agent to select and 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?

The schema coverage is 0%, so the description carries the full burden. It explains that 'name' accepts an id or name (case-insensitive) and causes full entries, while 'compact' controls whether entries are compact or full, with default true. It also explains the interaction between name and compact, adding significant meaning beyond the schema.

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

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

The description clearly states two primary use cases: listing all indicators as a compact catalog, or fetching a single indicator's full schema by name. It distinguishes between these modes and implies that this tool is for indicator discovery, differentiating from sibling tools like get_catalog or get_strategy_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 provides explicit guidance on when to use each argument combination: no arguments for discovering available indicators, name='rsi' before adding an indicator to a strategy, and compact=False for full entries but warns about potential truncation. It also suggests preferring compact or name= over compact=False to avoid truncation, and explains wire optimization as a behind-the-scenes saving.

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 states the tool is free, returns a catalog with specific fields, and allows optional filtering. No side effects or destructive behavior are present, and the read-only nature is implied.

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, front-loaded with the main purpose, and uses clear phrasing without extraneous words. It effectively organizes information with a brief introductory sentence followed by details.

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 listing tool with one optional parameter, the description covers the purpose, return fields, usage guidance, and parameter details. The presence of an output schema (not shown) may complement, but the description stands alone as complete.

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

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

The schema description coverage is 0%, meaning the schema has no parameter descriptions. The description compensates by explaining the sole parameter 'category' with concrete examples (rates, yield_curve, inflation, etc.) and its purpose (filtering), adding significant meaning beyond the schema.

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

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

The description clearly states that the tool lists available macroeconomic series (the catalog), specifies what it returns (id, title, category, frequency, units), and distinguishes it from get_macro_series which fetches a specific 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?

The description advises to 'Call this first to find the id for the series you want,' providing clear guidance on when to use this tool before get_macro_series. It also mentions optional category filtering but does not compare with all sibling tools.

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

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

With no annotations provided, the description covers key behavioral aspects: it is 'cheap, cacheable per session', returns templates 'available to the calling key', describes return formats for both modes, and notes potential truncation for non-compact output.

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

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

The description is well-structured with paragraph breaks and front-loads the purpose. It is fairly concise at ~150 words, with each sentence adding value, though it could be slightly more terse.

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 only 2 parameters, no output schema, and no annotations, the description is remarkably complete. It covers both functional modes, parameter behavior, return format, edge cases (truncation), and relates to sibling tools.

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

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

Schema coverage is 0%, so the description provides all meaning: explains name accepts id or name (case-insensitive) to fetch a single template, and compact controls output verbosity. It also details the structure of returned entries and references sibling tool schemas (validate_strategy, run_backtest).

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 dual purpose: listing predesigned strategy templates in a compact catalog or fetching one in full by name. It distinguishes between the two modes of operation and contrasts with sibling tools like get_catalog or get_strategy_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 provides clear context for when to use each mode: 'Use it to discover what exists' for the catalog mode, and 'Pass name='sma-cross' ... to get that single template's complete entry'. It also warns about the large size of compact=False. However, it does not explicitly state when not to use or compare with alternatives.

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

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

No annotations provided, but the description fully discloses the truncation behavior and the truncated_by_mcp marker, which is critical for agent understanding.

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?

Concise two-sentence description with front-loaded purpose. Could be slightly more structured, but 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?

Given the output schema exists and the description covers truncation and sibling tool differentiation, it provides complete context for effective use.

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%, but the single optional parameter 'asset_class' is self-explanatory and the description mentions its purpose. High coverage not required for one simple param.

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 lists available tickers with optional filtering by asset class, and distinguishes it from search_tickers which resolves specific assets by name.

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

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

Explicitly advises to use asset_class to narrow results or switch to search_tickers for specific assets, providing clear context for when to use this tool over alternatives.

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

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

With no annotations, the description fully discloses behavioral traits: quota-counted and compute-bound, error handling details (400/422 return accepted:false, other errors raise tool error with recovery guidance), response truncation (truncated_by_mcp), and benchmark-relative metrics when benchmark is provided.

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 thorough but somewhat lengthy. However, it is well-structured with clear sections (core action, usage guidance, parameter details, return info), front-loaded with key points, and uses formatting effectively. Minor reduction possible but every sentence adds value.

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?

Despite no annotations and 0% schema coverage, the description provides complete context for using this complex tool: explains return values (including benchmark_relative/alignment, truncation), error handling, parameter options, and interactions with sibling tools. The output schema exists, but description still adds value on return shape.

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

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

Schema coverage is 0%, but the description compensates fully by explaining each parameter in depth: data_source formats, strategy/signals structure, execution defaults via get_catalog, benchmark shape, data_inputs format, response_detail enum meanings, include options (including signal_diagnostics behavior), and trades_limit. This adds significant semantic meaning beyond the schema.

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

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

The description clearly states the tool action: 'Run a historical backtest against the engine.' It uses a specific verb and resource, and distinguishes itself from siblings like validate_strategy by mentioning it's compute-bound and quota-counted.

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 explicit guidance: validate the strategy first with validate_strategy (cheaper), avoid retrying 504 timeouts by reducing date range/coarsening frequency/simplifying strategy, wait for Retry-After on 429/503, and notes that server-side data_source requires a paid plan. It also clarifies mutual exclusivity of strategy and signals.

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 provided, so description carries full burden. Mentions relevance-ranking and asset_class filter values, but omits details like return format or pagination behavior. Adequate but not comprehensive.

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?

Concise with clear line breaks separating usage guidance from parameter info. No wasted sentences, but could be slightly more 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?

Given 3 parameters and an output schema, description covers main use case. Doesn't explain return values (output schema covers that) or error handling, but overall adequate for a search tool.

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

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

Schema coverage is 0%, so description must compensate. It adds meaning for 'asset_class' by listing acceptable values, but 'query' and 'limit' are not described beyond the schema. 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?

Description clearly states it searches assets by ticker or name and returns relevance-ranked results. It distinguishes from sibling tools like 'list_tickers' (which likely lists all) and 'get_ticker_info' (which gets details for one).

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

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

Explicitly advises using it to resolve a user's asset mention before a server-side data fetch, providing clear context. Lacks explicit when-not-to-use instructions but context is strong.

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 provided, so description carries full burden. Discloses it is cheap (separate quota), not a backtest, and that failed validation is a normal result, not an error. This adds useful behavioral context beyond what structured fields would provide.

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?

Well-structured with intro, quota note, and clearly separated Args/Returns sections. Every sentence adds value, though slightly verbose; could be more terse while retaining clarity.

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?

Description covers return format (success and failure cases with detailed error structure) and references get_strategy_schema for strategy shape. Given tool complexity and existing output schema, it provides complete context for an agent to use 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 0%, but description fully compensates with detailed arg explanations: strategy document shape (name, indicators, condition_tree) and how injected_indicators are used. References external schema for exact format, adding clear meaning beyond schema types.

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 clearly states 'Validate a strategy document without running a backtest', providing a specific verb and resource. It distinguishes from siblings like run_backtest by emphasizing the tool does not execute a 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?

Explicitly advises 'validate freely and ALWAYS before run_backtest', indicating when to use. References get_strategy_schema for shape details. No explicit exclusions for other scenarios, but strong guidance is present.

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