validate_research_protocol

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

With no annotations provided, the description bears the full burden and does substantial work: it declares the operation read-only and static, limits scope to 'one exact saved Pine strategy version', lists all audit checks, and discloses non-actions. It stops short of describing the result/verdict format or whether the validation outcome is persisted, which is meaningful for an adoption-decision 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?

Three sentences with zero filler, purpose front-loaded in the first sentence, the audit checklist packed efficiently into the second, and the non-goal exclusions isolated in the third. Each sentence earns its place and the structure makes scanning easy.

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 12 parameters, nested objects, no annotations, and no output schema, the description is rich on purpose and inputs but silent on what the agent receives back — there is no return-value or verdict-structure hint, and failure behavior is unstated. Since the tool exists to inform adoption decisions, the absence of output expectations is a notable gap that the description could not offload to annotations or an 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 must compensate, and it does: nearly every audit dimension maps to parameter groups (minimum trades → minimum_trades, explicit costs → costs, forming-bar use → closed_bars_only, candidate multiplicity → candidate_ids, definition changes after OOS access → definition_frozen_at/definition_last_changed_at, IS/OOS and future windows → windows). Observed_trades is the one parameter not conceptually referenced, and the description doesn't explain how to structure nested objects beyond the schema, but the compensation is strong.

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

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

The description states a specific verb and resource ('Validate a frozen strategy-research protocol before adoption decisions') and enumerates the exact audit dimensions (IS/OOS overlap, future windows, forming-bar use, candidate multiplicity, minimum trades, explicit costs, restart-difference evidence, definition changes after OOS access). It also distinguishes itself from siblings by explicitly listing what it is not ('does not run a backtest, inspect the chart, or prove non-repainting'), which differentiates it from run_backtest, get_chart_context, and repainting audit 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 gives clear when-to-use context ('before adoption decisions') and explicit when-not-to-use exclusions (does not run a backtest, inspect the chart, or prove non-repainting). However, it never names an alternative sibling to route the agent to when those non-goals are actually needed, so the guidance stops at exclusion rather than active redirection.

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