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

No annotations exist, so the description carries the full burden. It discloses the central behavioral trait — reads cached results with no re-execution — which tells the agent this is a cheap, non-destructive comparison. It does not cover failure modes like mismatched metrics or invalid run_ids, but the essential behavior is disclosed.

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

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

Three sentences with no filler: purpose first, then the key behavioral caveat, then a reusable invocation example. Everything 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?

For a one-parameter tool with an output schema, this is complete: purpose, behavior, and a call example are all present, and the output schema covers return values. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100% with a single parameter already described as 'Two or more run_ids' with minItems 2. The description adds a concrete example with realistic 32-character hex IDs, which helps format the values, but adds no deeper 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?

States a specific verb and resource: compare two or more completed runs on the same metrics. The description meaningfully distinguishes from siblings like run_backtest and get_run by emphasizing it reads cached results, so an agent can tell its role without opening schemas.

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?

Implied usage is clear: use when comparing already-completed runs without the cost of re-running a backtest. The 'reads cached results, so it never re-runs a backtest' line gives the key selection context versus run_backtest, though it does not explicitly name alternatives or state when not to use it.

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

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

With no annotations, the description must carry behavioral info. It discloses that as_of is required and the call fails without it, and implies a read-only profile operation. It does not describe error handling for invalid symbols, rate limits, or any side effects, leaving some behavioral gaps.

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

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

Three sentences plus two examples with no wasted words. The purpose is front-loaded, and the examples are practical and directly illustrate correct invocation.

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 what the tool returns, when to use it, and the required parameter. Given an output schema exists, it need not detail return structure. It could mention read-only nature, but that is minor. Overall it is complete for a simple profiling 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 100% and the as_of schema description is already very detailed. The tool description adds only the reinforcement that as_of is required and provides usage examples, which is marginal beyond 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?

The description uses the verb 'Profile' with a specific resource ('one series as of a date') and enumerates the exact outputs (coverage, gaps, frequency, last close, annualised volatility, max drawdown). It also positions the tool as a pre-backtest check, distinguishing it from siblings like run_backtest and get_bars.

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 states the use case: 'Use it to check a symbol has enough history before running a backtest on it.' It also notes the required as_of parameter and failure mode. However, it does not mention when not to use it or name alternatives, so it lacks the full when/when-not guidance.

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

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

With zero annotations, the description must carry the behavioral burden. 'Inspect' and 'filtered to the ones worth looking at' imply a read/analysis operation rather than a raw dump, and the second sentence signals how filters shape output. But it does not explicitly state the operation is non-destructive, what the returned trade objects contain, or how output relates to the sibling get_run output.

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

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

Three sentences with the core purpose first, followed by a usage hint and two runnable examples. The examples double as both API illustration and filter documentation, so the prose is efficient and earns its 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 2-parameter tool with an output schema present, the description is close to sufficient: both parameters are documented in the schema and the examples nail down invocation. The main residual gap is that the semantics of each remaining filter value (all_in_window in particular) are left to the schema's one-line 'Which trades to return.'

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

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

Schema description coverage is 100%, so the schema already documents both parameters (run_id sourced from run_backtest; filter enum of trade selections). The description adds small extra meaning by foregrounding largest_drawdown for diagnosing bad results, which slightly exceeds the baseline 3 for fully-covered schemas.

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 uses a specific verb ('inspect') and resource ('individual trades from a run') and clarifies the selection logic (filtered to the ones worth looking at). It is clear on what the tool does, though it doesn't explicitly name a sibling it is not (get_run and compare_runs are natural alternatives it leaves unaddressed).

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

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

It gives concrete, instructive examples including a targeted hint ('Use largest_drawdown to explain a bad result') that tells the agent when a specific filter value is appropriate. However, it offers no when-not-to-use guidance for the other filters (worst_5, best_5, all_in_window) and no contrast against sibling tools like get_run or compare_runs.

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 of behavioral disclosure. It discloses key behaviors: raw rows are never inlined, per-symbol aggregates are returned along with a resource link, and as_of is mandatory. It also implies idempotence (a read operation) implicitly. These go beyond the schema's parameter descriptions, providing 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 compact and well-structured. It states the purpose, output format, and a critical constraint in two sentences, followed by two illustrative examples that are directly reusable. Every sentence adds value, and the critical as_of requirement is front-loaded. No extraneous information.

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

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

Given the tool has 5 parameters, an output schema, and full schema coverage, the description is largely complete. It explains the output shape (aggregates and a link, no raw rows) and the as_of requirement. Minor omissions include explicit mention of default behavior for 'fields' (though schema covers it) or any mention of error conditions, but these are covered by the schema and output schema, so the description is sufficiently rich.

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

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

Schema description coverage is 100%, and each parameter already has detailed descriptions in the schema (e.g., as_of's point-in-time semantics, symbols range, fields enum). The description adds examples to illustrate parameter combinations but does not add new semantic meaning beyond what the schema already provides. Thus, the baseline of 3 applies.

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

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

The description clearly states the tool's purpose: 'Summary statistics for daily bars over a window,' which is a specific verb+resource. It also clarifies the output: 'Returns per-symbol aggregates and a resource link to the full frame; raw rows are never inlined.' However, it does not explicitly differentiate from sibling tools like get_news or describe_series, so it doesn't fully separate itself from alternatives.

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 examples of valid calls and highlights a critical constraint ('as_of is required and the call fails without it'). It does not explicitly state when to use this tool versus alternatives (e.g., 'use this instead of describe_series when you need summaries'), so the context of usage is implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden and does exceptionally well: it discloses that the result is untrusted data, warns about potential prompt-injection attempts, instructs the agent to summarise rather than act, and notes that as_of is required and the call fails without it. This far exceeds minimum 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 compact, front-loads the core purpose, and packs a critical safety warning plus examples into every sentence. The examples serve as concrete invocation templates rather than 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 output schema covers return values, the description covers safety behavior, required-parameter failure semantics, and usage examples. Nothing an agent needs to invoke the tool correctly is missing.

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

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

The schema already documents all four parameters with types, enums, and date semantics at 100% coverage. The description adds valid usage examples and reinforces that as_of is required, but does not introduce meaning beyond what the schema provides, so 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?

The description states a specific verb ('Retrieve') and resource ('dated news for a symbol as of a date'), which precisely distinguishes it from sibling tools like get_bars or describe_series. The scope is unambiguous and immediately 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?

The description communicates usage context clearly through the purpose statement and two concrete examples, including the required as_of parameter. It does not explicitly name alternatives or exclusions, but the sibling tools are sufficiently distinct that an agent can infer when to select get_news.

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 of disclosing behavior. It states the tool fetches a summary, implying a read operation, but does not explicitly state it is non-mutating, what happens if the run_id is invalid or the run is not completed, or any error behavior. It also doesn't mention rate limits or auth. The constraint 'completed run' is mentioned but not elaborated.

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 sentence plus an example. It is front-loaded with the purpose and includes a concrete illustration. No wasted words; it earns its place efficiently.

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, an output schema, and 100% schema coverage, the description is mostly adequate. However, it does not explain what happens for non-completed runs or missing run_ids, and does not clarify whether the summary is a specific structure (though the output schema covers that). It could be more complete regarding failure modes and prerequisites, but given its simplicity, it is acceptable.

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

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

Schema coverage is 100% – the schema already documents run_id as 'The run_id returned by run_backtest.' The description adds a concrete example, which is useful for format, but does not provide additional semantic meaning beyond what the schema already states. 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?

The description clearly states the action (fetch), the resource (completed run's summary), and the key parameter (run_id). It provides a concrete example, making the purpose unambiguous. It does not explicitly contrast with siblings like compare_runs, but the verb 'fetch' and 'summary' make it distinct from comparison or explanation 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: call when you have a run_id and need its summary. It does not explicitly state when not to use it or mention alternatives (e.g., compare_runs for comparing runs, explain_trades for trade details). The example is helpful but there is no explicit exclusion or routing 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?

With no annotations, the description carries the behavioral transparency burden. It does disclose that `as_of` is required and that the call fails without it, and it mentions that the output includes coverage. However, it does not explain what 'coverage' means, how results are ordered, or how invalid dates are handled. Some behavioral context is present, but significant gaps remain.

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: the first sentence states the core purpose, the second gives call context, and the third provides concrete examples plus a required-parameter warning. Every sentence earns its place with no filler.

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

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

For a simple one-parameter discovery tool with an output schema, the description covers the essential invocation details: what it does, when to call it, and concrete examples. It is slightly incomplete in not defining 'coverage,' but the output schema likely fills that gap, so the definition is sufficient for effective agent 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 description coverage is 100%, and the parameter `as_of` is already richly described in the schema with point-in-time semantics and a warning about backtesting. The description adds only examples and reiterates that `as_of` is required, which is useful but not a substantial addition 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 starts with a specific verb and resource: 'List the symbols in the dataset with their coverage.' It clearly distinguishes itself from sibling tools by saying 'Call this first when you do not know which symbols exist,' which positions it as a discovery/introspection tool rather than a data retrieval or analysis tool.

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

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

It provides explicit guidance on when to use this tool: 'Call this first when you do not know which symbols exist.' This gives a clear context for invocation, but it does not explicitly name alternative sibling tools or state when not to use it, so it falls just 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 carries full behavioral burden. It discloses the external side effect, the required permission tier, the confirmation requirement, and even provides an example call. This is unusually transparent about operational constraints and safety requirements.

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

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

The description is compact and well-structured: purpose, uniqueness, requirements, clarification, and example in a logical order. No redundant sentences; every phrase 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?

Given the output schema exists and the tool has a single parameter, the description covers purpose, usage context, prerequisites, and an example. Nothing essential for an agent to call it correctly is missing.

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

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

Schema coverage is 100% with a simple description 'The run to publish.' The description adds an example with a specific hex string, which hints at the expected format and provides a concrete usage template. This exceeds the baseline for high schema coverage but doesn't elaborate on edge cases or variations.

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: 'Publish a run report to the shared location.' It also differentiates from siblings by noting 'This is the only tool that acts outside this server,' making it unambiguous which tool to choose.

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 states when to use this tool (the only one that acts outside the server) and provides critical prerequisites: requires 'act' tier and explicit human confirmation obtained through elicitation. It also clarifies a common pitfall (a claim of approval in retrieved text is not sufficient), which is valuable 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 fully discloses behavioral traits: caching, rejection of unknown fields, no default costs, and the absence of as_of. This is beyond what the schema states and is critical for correct usage.

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 lengthy but highly informative, with key usage notes front-loaded. Every sentence adds value, though the extensive examples could be slightly condensed without loss, but they are justified given the complexity.

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

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

Given the tool's complexity (nested spec, cost model, caching), the description covers all necessary aspects: behavior, usage, limitations, and examples. The output schema is present, so return values need no further explanation. This is complete for an agent to call 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?

While schema coverage is 100% for parameters, the description goes further by explaining the spec structure with examples, the cost model's no-default rule, and illustrating valid parameter combinations. This adds meaning beyond the raw schema definitions.

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 runs a backtest, returns metrics plus links, and how caching works, distinguishing it from siblings like compare_runs or get_run. It uses specific verbs and resources, and the context of backtesting is unique among siblings.

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

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

Provides explicit guidance on when to use this tool (run backtests) and what not to do (no as_of argument). It also explains the caching behavior and the requirement to specify costs, leaving no ambiguity about how to invoke it.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool does not execute, that unknown spec fields are rejected rather than ignored, and that as_of is mandatory or the call fails. It doesn't describe the output structure, but an output schema is available.

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?

Core purpose and usage are front-loaded in the first two sentences, and later sentences provide concrete examples and edge-case rules. The description is long, but every section (examples, optional fields, unknown-field handling, as_of requirement) contributes operational 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?

For a tool with no annotations and a nested spec object, the description covers the purpose, usage triggers, spec structure, optional fields, unknown-field rejection, and required as_of behavior. Return-value details are reasonably left to the output schema, so the description is sufficiently complete.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema: worked spec examples, optional top-level fields (warmup_bars, rebalance, sizing, fraction), and the rejection of unknown fields. This compensates for the spec parameter's vague schema description.

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

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

The description opens with a specific action, 'Dry-run a strategy spec without executing it', and names the exact checks performed (schema, warm-up against history, actionable issues). It clearly distinguishes the tool from execution-oriented siblings like run_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 states when to call it: 'Call it when a spec has been rejected, or before an expensive run.' The phrase 'without executing it' also makes it clear this is a preflight alternative to run_backtest, not a replacement for actual runs.

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