Algo Trade Analytics

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety and repeatability profile is covered. The description adds useful context about the input source (closed trades) and output categories, but it does not disclose behavioral details such as computational cost, distribution shape, or failure modes when inputs are invalid.

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 single sentence is front-loaded with the primary verb and resource, and contains no filler. However, given the tool's 17-parameter complexity, the description is arguably too thin to be considered fully balanced, though economy itself is handled well.

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

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

With 17 parameters, no output schema, and only 47% schema description coverage, a one-sentence description is insufficient. It does not explain how the required parameters should be filled, what the return values look like, how protocolId relates to define_experiment_protocol, or what distinguishes this analysis from the many sibling analysis 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 description coverage is only 47%, and the description does not compensate for the many undocumented parameters such as symbol, timeframe, startDate, endDate, source, seed, iterations, or confidenceLevel. It only references protocolId, leaving the agent to infer the meaning and format of most required inputs.

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 ('Bootstrap'), names the resource ('closed-trade P&L'), and states concrete outputs ('confidence, drawdown risk, and top-trade dependency'). It also identifies the required orchestration context ('experiment protocolId'), which clearly differentiates it from sibling analysis tools like analyze_overfit_probability or analyze_parameter_robustness.

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 no guidance on when to choose this tool over alternatives. It does not state when a bootstrap confidence analysis is appropriate, how it relates to define_experiment_protocol, or when sibling tools like analyze_cost_sensitivity or analyze_overfit_probability should be preferred instead.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds genuinely useful behavioral context beyond annotations: maxVariants counts all executions including configured and zero-cost references, and worse-than-declared settings must be included. No contradiction with annotations.

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

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

Three dense sentences with no filler. The core action is front-loaded, the robustness requirement is stated, and the critical maxVariants caveat is placed at the end. Every sentence 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?

This is a complex tool with 13 parameters, only 38% schema description coverage, and no output schema. The description highlights key nuances but omits essential operational details: how the grid is constructed, how results are returned, what defaults apply, and how the required dates/symbol/source relate to execution. It is not complete enough for safe invocation.

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

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

Schema description coverage is only 38%, and the description does little to explain the many undocumented parameters. It clarifies maxVariants semantics and hints at costBps/slippageTicks as the imposed grid, but it does not compensate for the low schema coverage across 13 parameters, including required ones like source, timeframe, and date range.

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 ('Measure ... then test') and a distinct resource ('commission/slippage grid for the required protocolId'), making the tool's purpose clear. It is clearly distinguishable from cost-adjacent siblings like analyze_parameter_robustness or stress_test_candidate.

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: use this tool to evaluate cost sensitivity at actual configured costs and under imposed grids before claiming cost robustness. It does not explicitly name alternatives or when-not-to-use conditions, but the context is strong enough for an agent to select this over siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about bounded symbol/timeframe execution and transferability evidence, but does not disclose potential runtime cost, matrix limits, or what 'evidence' concretely contains.

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 with no filler and front-loads the core action. It is concise, though it packs several concepts together and could benefit from a second sentence for parameter guidance.

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

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

With 16 parameters, low schema coverage, no output schema, and many sibling tools, this description is not complete enough for reliable invocation. It leaves the caller guessing about required parameter combinations, matrix bounds, output shape, and the meaning of 'transferability evidence' in practical terms.

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 only 31%, so the description carries a heavy burden to explain parameters, but it only mentions protocolId and the symbol/timeframe matrix concept. It does not clarify the relationship between required singular symbol/timeframe and optional plural symbols/timeframes, nor explain maxScopes, minTrades, minProfitFactor, source, dates, or idempotency behavior.

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 action ('Run the same strategy across a bounded symbol/timeframe matrix') and identifies the resource (a required protocolId) and outcome ('report transferability evidence'). It is clear on its own, but it does not name or distinguish itself from the many analyze_* 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?

The phrase 'for a required protocolId' implies this tool is used after define_experiment_protocol and for cross-scope validation, giving some usage context. However, it does not explicitly say when to prefer this tool over siblings like walk_forward_candidate or analyze_market_coverage, nor does it 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. However, the description adds no behavioral detail beyond a purpose statement: it does not reveal what the output looks like, what data scope is examined, whether it returns examples, or any operational constraints.

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 concise sentence with no filler or redundancy. It front-loads the core action and then gives the purpose, making it efficiently scannable for an agent.

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

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

With ten parameters, five required ones, no output schema, low parameter documentation, and many similar sibling tools, the minimal description is not enough for reliable invocation. It fails to explain return values, required parameter semantics, or how this tool fits among the other analysis 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 description coverage is only 40%, leaving most parameters undocumented. The tool description contains no parameter-level guidance at all, so it fails to compensate for the low schema coverage. An agent must infer the meaning of required fields like symbol, timeframe, startDate, endDate, and 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 uses a specific verb ('Find') and a specific analytical resource ('recurring loss patterns'), with a clear downstream purpose ('drive the next falsifiable hypothesis'). This distinguishes it from sibling analysis tools that target other aspects such as risk management, trade features, or overfitting.

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 phrase 'to drive the next falsifiable hypothesis' implies a workflow context, but the description does not explicitly state when to prefer this tool over the many sibling analyze_* tools. There are no exclusions, alternatives, or conditions, so usage guidance remains 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is known to be non-destructive. The description adds that it detects moves and reports captures/misses, which is useful but not rich. It doesn't explain what 'clean directional moves' means or how the strategy's captures are determined, leaving some behavioral ambiguity.

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 that conveys the core purpose without wasted words. It is appropriately concise, though it sacrifices detail for brevity. The structure is acceptable but leaves out important 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 complexity (14 parameters, no output schema), the description is far too brief. It doesn't explain what constitutes a 'directional move', how captures/misses are measured, what output format to expect, or any operational details. An agent would need significant additional information to call this tool correctly and interpret results.

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

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

Schema description coverage is only 29%, with most parameters (symbol, timeframe, startDate, endDate, source, maxMoves, atrLength, windowBars, minAtrMultiples, cooldownBars) lacking descriptions. The tool description provides no parameter-level guidance, so it fails to compensate for the low schema coverage. The few described parameters (inputs, caseStudyId, researchRunId, mcpIdempotencyKey) are handled by the schema, but the majority remain ambiguous.

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: detect clean directional moves in the bar series and report which moves the strategy captured or missed. It uses a specific verb (detect, report) and identifies the resource (bar series, strategy moves). However, it doesn't explicitly distinguish itself from sibling analyze_* tools, though the unique focus on market coverage is implicit.

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

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

No guidance is given on when to use this tool versus alternatives. There is no mention of scenarios where this analysis is appropriate or exclusions. An agent would have to infer its usage from the name and 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds the CSCV method and the protocolId prerequisite, which is useful, but it doesn't disclose output characteristics or any operational requirements beyond that. With annotations present, this is adequate but not rich.

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

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

Two sentences with zero filler: the first front-loads purpose and method, the second gives workflow timing. Every phrase 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 12-parameter, 7-required tool with no output schema and 58% schema coverage, the description covers purpose, method, and workflow position but omits what the returned probability/result looks like and gives no guidance on the required data-locator parameters (symbol, timeframe, dates, source). It is adequate but leaves meaningful 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 description maps 'candidate configurations' to configs and 'required experiment protocolId' to protocolId, adding meaning beyond the schema. At 58% schema coverage, however, symbol, timeframe, startDate, endDate, and source remain undocumented in both the schema and the description, so the description does not fully compensate for the coverage gap.

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

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

The description names a specific verb ('Estimate'), a specific resource ('Probability of Backtest Overfitting'), a method ('combinatorially-symmetric cross-validation'), and scope ('across a set of candidate configurations'). This clearly differentiates it from siblings like analyze_parameter_robustness or walk_forward_candidate without needing to open their 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?

'Use after testing several parameterizations to check whether keeping the in-sample best generalizes out-of-sample' states when to use it with clear context. However, it names no alternatives or when-not-to-use conditions, even though siblings like walk_forward_candidate or evaluate_candidate perform related validation jobs.

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

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

Annotations already establish readOnly, idempotent, non-destructive, so the description does not need to restate safety. It adds output behavior by saying it 'flag[s] single-point overfit risk' and ties the analysis to a specific protocolId. It does not disclose return shape or stability criteria, but the annotations cover the safety profile and the description gives a reasonable behavioral summary.

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

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

A single sentence, front-loaded with the verb and object and no filler. It could carry more detail, but it is efficiently structured.

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

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

Given the tool's complexity (25 parameters, no output schema, low schema coverage), a one-line summary is not enough for an agent to know expected return values, what 'stability' means, how overfit risk is determined, or what prior workflow steps are required. The description would need at least prerequisites, output semantics, and guidance across the analysis siblings to be complete.

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

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

Schema description coverage is only 24%, so the prose needs to compensate for 25 parameters; the only parameter it calls out is protocolId, and it merely labels it 'required' without adding semantics beyond the schema's own protocolId description. Required params like symbol, timeframe, startDate, endDate, and source are left entirely to the schema, so the description adds little to parameter understanding.

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 specific action 'Summarize' with a clear resource ('parameter-sweep stability') and names the required protocolId input. It is clear enough to differentiate from running a sweep, but it never refers to sibling analysis tools such as analyze_overfit_probability or analyze_bootstrap_confidence, so sibling differentiation is only implicit.

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

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

The description implies the tool is used when a protocolId exists and the user wants a stability/overfit summary, but it gives no explicit when-to-use guidance, prerequisites (e.g., run_parameter_sweep must have completed), or exclusions. No alternative tools are mentioned, so an agent would have to infer when this is preferable to analyze_overfit_probability or stress_test_candidate.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no behavioral context beyond the constraints implied by requiring a protocolId. It doesn't discuss side effects, performance, or data boundaries. With annotations carrying the safety weight, the description contributes minimal additional behavioral detail.

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

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

The description is extremely brief—one sentence—which is concise but grossly under-specified for a tool with 17 parameters. While there is no fluff, the structure is not 'appropriately sized'; it lacks necessary detail. The core action is front-loaded, but the overall terseness does not serve the agent's needs.

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 (17 parameters, 6 required, no output schema, low schema coverage), the description is woefully incomplete. It fails to explain the meaning of key parameters, the expected input format, or how the analysis results are delivered. An agent cannot correctly invoke this tool without additional external knowledge.

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 only 29%, meaning most parameters are undocumented within the schema. The description mentions 'protocolId' as required but does not explain any of the other 16 parameters, such as iterations, accountSize, riskPerTradePct, or maxDrawdownPct. The tool definition does nothing to compensate for the sparse schema documentation, leaving the agent clueless about parameter usage.

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 ('Analyze') and resource ('position sizing, drawdown limits, and risk-of-ruin') and mentions that it requires an experiment protocolId. This is clear and distinguishes it from other tool categories in the sibling list (e.g., analyze_bootstrap_confidence focuses on different aspects). However, it does not explicitly differentiate it from other analyze_* tools, so it's not a 5.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites beyond 'required experiment protocolId'. There is no mention of when not to use it or which sibling tools might be more appropriate for other analysis types. The usage context is entirely omitted.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the behavioral scope: it audits visible signal markers and order traces for skipped/duplicate/unfilled signals. It does not disclose details like whether it returns examples, how it handles missing data, or whether it requires a prior define_experiment_protocol call, though the protocolId parameter description hints at that.

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

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

The description is a single sentence that front-loads the core action and scope. It is concise and readable. It could add a bit more context about the required parameters, but it earns its place without 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?

For a tool with 12 parameters, 6 required, no output schema, and 42% schema description coverage, the description is somewhat thin. It tells the agent what the audit checks for but not what the output looks like, how to interpret results, or what the key parameters mean. The annotations cover safety, but the operational context is incomplete. The protocolId reference to define_experiment_protocol is helpful, but the rest of the required parameters (symbol, timeframe, startDate, endDate, source) are left unexplained.

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

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

Schema description coverage is only 42%, so the description should compensate for undocumented parameters. The description mentions protocolId implicitly ('for a required experiment protocolId') and the schema documents protocolId, inputs, caseStudyId, researchRunId, and mcpIdempotencyKey. However, parameters like symbol, timeframe, startDate, endDate, source, maxExamples, and duplicateWindowBars have no descriptions in the schema, and the tool description does not explain them either. The description adds the purpose of the audit but not the semantics of the date range, source, or duplicateWindowBars 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 states a specific verb ('Audit') and resource ('visible signal markers and order traces') and names the specific failure modes it checks for ('skipped, duplicate, or unfilled signals'). It also mentions the required protocolId. However, it doesn't explicitly distinguish itself from the many sibling 'analyze_*' tools, though the audit focus is fairly distinctive.

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 when to use it: when you need to audit signal markers and order traces for a protocol. It does not explicitly state when not to use it or name alternatives among the many analyze_* siblings. The context signals show 12 parameters and 6 required, but the description gives no guidance on how to choose this over analyze_trade_features or analyze_losing_trades, for example.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no additional behavioral context such as side effects, rate limits, or prerequisites, but it does not contradict the annotations.

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

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

The description is a single concise sentence with no filler, and the core action is stated first. It is efficient, though extremely brief given the tool's complexity.

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

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

With 20 parameters, no output schema, and no usage guidance, a one-sentence description is insufficient. The agent lacks information about expected return values, how parameters interact, and when this tool should be preferred over similar analytic siblings.

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

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

Schema description coverage is only 20%, so the description must compensate by explaining parameter meaning. It does not: no required parameter, optional filter, or configuration field is mentioned. The sole sentence adds almost no parameter-level guidance beyond the schema fields themselves.

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: 'Attribute trade outcomes to entry/exit features, sessions, and MAE/MFE excursions.' It identifies the core function and mentions distinctive analysis dimensions that set it apart from siblings like analyze_losing_trades or analyze_risk_management, though it does not explicitly name alternative 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?

There is no guidance on when to use this tool versus the many sibling analyze_* tools. The description implies a use case but does not provide selection criteria, exclusions, or alternatives, leaving the agent to infer relevance.

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?

Adds meaningful behavior beyond the annotations: queued jobs refund the reservation in full, while running jobs stop at the next trial checkpoint and charge only completed work. This billing/execution nuance is not present in the annotations and materially helps an agent predict consequences. No contradiction with readOnlyHint, idempotentHint, or destructiveHint.

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

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

Two tightly packed sentences: the first states the purpose, the second explains the caveats. No filler or repetition; every clause earns its place.

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

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

For a simple single-parameter cancellation tool, the description covers the key operational outcomes (queued vs running). It does not mention how to retrieve jobId or what happens if the job is already completed, though the idempotentHint partially mitigates repetition concerns. The low complexity keeps this close to 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 has zero parameter description coverage and the tool description never mentions jobId or how to obtain/validate it. The parameter name makes the meaning inferable, but the description does not compensate for the lack of schema-level documentation as required by the low 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?

States a specific verb ('Cancel') and a specific resource ('one of your background research jobs'), which clearly differentiates from sibling tools like ata_cancel_research_task and ata_cancel_research_workflow. The phrase 'background research jobs' pins the scope precisely.

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

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

Provides clear context that this tool is for cancelling background research jobs, not tasks or workflows, and clarifies behavior for queued versus running jobs. It does not explicitly name alternative tools or state when not to use this one, but the resource type alone gives adequate selection guidance.

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

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

Annotations already declare idempotentHint=true and destructiveHint=false, so the description doesn't need to restate those. The description adds the 'durable' and 'MCP task-compatible facade' context, which is useful. It does not disclose what happens to the underlying job, whether cancellation is graceful or forceful, or whether it is safe to call on a completed job, but the idempotent hint partially covers that.

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

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

A single sentence that is front-loaded with the action and resource, and includes the key distinguishing qualifier ('MCP task-compatible facade'). No wasted words.

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

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

For a single-parameter cancellation tool with idempotentHint=true, the description is mostly sufficient. However, with no output schema and no explicit statement of what the response contains or what state the job transitions to, an agent has to infer the result. The sibling set includes ata_cancel_research_job and ata_cancel_research_workflow, so a bit more differentiation would improve 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 description coverage is 100%, so the schema already documents taskId as the MCP task id / durable jobId. The description adds no additional parameter meaning beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb ('Cancel') and resource ('durable ATA research job'), and adds the qualifier 'through the MCP task-compatible facade' to distinguish it from the raw job-cancellation siblings. It is clear what the tool does, though it doesn't explicitly name the sibling it differs from.

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 this is the MCP-facade variant for cancelling ATA research jobs, which hints at when to use it versus ata_cancel_research_job or ata_cancel_research_workflow. However, it does not explicitly state when to prefer this tool over those alternatives or mention any prerequisites (e.g., job must be running).

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 adds the meaningful behavioral detail that cancellation is 'terminal until the client or user explicitly resumes it,' which the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true) do not convey. This clarifies the lifecycle consequence and implicitly points to the sibling ata_resume_research_workflow, adding value beyond the annotations.

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

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

Two sentences with zero wasted words: the first states the action and scope, the second adds the single most important behavioral caveat. Both sentences earn their place and the key action is front-loaded.

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

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

For a simple one-parameter tool with no output schema, the description covers purpose and the critical terminality behavior. However, given the sibling context containing two other cancellation tools and a resume tool, it is missing an explicit pointer distinguishing workflow-level cancellation from job/task-level cancellation, which an agent would need to route correctly.

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

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

Schema description coverage is 0%, so the description carries the full burden for parameter semantics, but it never explains workflowJobId beyond what the property name implies. The field name is self-descriptive and it is the only required parameter, but the description adds no information about its origin, format, or relationship to the workflow.

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 ('Cancel') and a specific resource ('platform-managed research workflow'), which clearly conveys the action. The qualifier 'platform-managed' and the word 'workflow' conceptually differentiate it from the sibling tools ata_cancel_research_job and ata_cancel_research_task, though it never names them explicitly.

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

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

There is no guidance on when to choose this tool over ata_cancel_research_job or ata_cancel_research_task, nor any mention of prerequisites or where the workflowJobId comes from. The second sentence describes the consequence of cancellation, not the conditions that should lead an agent to invoke this tool.

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

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

Annotations already convey readOnlyHint, idempotentHint, and destructiveHint, and the description does not contradict them. It adds some context with 'configured' and 'safe ... readiness metadata,' but no substantial behavioral disclosure beyond what annotations already 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?

The description is a single front-loaded sentence with no filler or repetition. It efficiently communicates the purpose without wasting 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?

With zero parameters, complete annotations, and no output schema, the description provides enough information to invoke the tool safely. The phrase 'safe Alpaca market-data readiness metadata' is slightly vague about the exact contents of the returned metadata, but this does not block correct usage.

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

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

The tool takes zero parameters and schema description coverage is 100%, so there are no parameter semantics for the description to clarify. Baseline 4 applies for a zero-parameter tool.

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 uses a specific verb 'Return' and names the resources: 'configured MCP actor-user context' and 'safe Alpaca market-data readiness metadata.' It clearly states what the tool does, though it does not explicitly distinguish itself from siblings like ata_health or ata_mcp_usage_status.

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

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

No guidance is provided for when to use this tool versus alternatives such as ata_health or inspect_market_context. The description only states what is returned and does not mention exclusions, prerequisites, or alternative routing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe-read nature is covered. The description adds that the return value is a summary plus evidence maturity, but gives no further behavioral context such as edge cases or limit behavior. This is adequate but not rich.

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

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

The description is a single front-loaded sentence with no filler. It states the core action and resource immediately, and every word contributes to the tool's 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?

There is no output schema and parameter coverage is incomplete, yet the description offers only a high-level statement of return content. It omits what 'limit' does, what the returned summary structure looks like, and how the agent should handle absent evidence or unknown case studies.

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, but it only references 'case study' for caseStudyId. The 'limit' parameter is entirely unexplained, including what it limits or how it affects results, leaving an agent without meaningful guidance for one of the two 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 uses a specific verb ('Return') and identifies a clear resource ('Algo Agent research notebook summary and evidence maturity') scoped to a case study. It is distinguishable from siblings like ata_get_research_notebook because it specifically says 'summary' and 'evidence maturity,' though it does not explicitly name the sibling it differs from.

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 no guidance on when to use this tool versus alternatives such as ata_get_research_notebook or ata_get_research_task_result. No context, prerequisites, or exclusion criteria are provided, leaving the agent to infer usage from the name and sibling list.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only that the return value is a prompt template for tool-only clients, which is mild context but does not disclose error behavior or template content. No contradiction with annotations.

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

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

Single sentence with no filler, and the verb and object appear immediately. It is appropriately sized for a simple read-only getter and every word 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, read-only, idempotent getter with rich annotations, the description is mostly adequate. However, it omits the meaning of `name` and does not refer the agent to ata_list_prompts for discovering valid prompt names, leaving a small but real gap.

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

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

Schema description coverage is 0% and the description never mentions the `name` parameter; only the schema's property name suggests it identifies the prompt. With low coverage, the description should compensate by explaining valid values or pointing to a way to discover them, and it does not.

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 clear verb ('Return') and resource ('one ATA MCP prompt template'), and the singular wording distinguishes it from the sibling ata_list_prompts. It is unambiguous, though it does not explicitly name the sibling alternative.

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 phrase 'for tool-only clients' provides a hint about target usage, but there is no explicit when-to-use guidance, no exclusions, and no mention of the obvious alternative ata_list_prompts for listing available prompts. An agent cannot reliably decide when this tool should be selected.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds minimal behavioral context, such as the contract being 'current' and the recommended usage timing, but it mostly describes output contents rather than deeper behavioral traits.

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

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

A single sentence that front-loads the purpose, lists the key return elements, and ends with a crisp usage instruction. There is no fluff, restatement of the tool name, or redundant warm-up.

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 communicates what the tool returns and when to use it, and annotations cover the safety profile. However, with no output schema and no explanation of the optional parameters, an agent wanting to select a summary level or scope the contract to a case study or research run has no guidance.

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

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

Schema description coverage is 0%, and the description does not mention any of the three parameters: caseStudyId, summaryLevel, or researchRunId. The omission is partially mitigated by self-explanatory parameter names and the summaryLevel enum, but the description provides zero direct compensation for the missing schema documentation.

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 ('Return') and names a clear resource ('current MCP research contract'), then enumerates what it contains: binding, evidence maturity, allowed/blocked tools, and platform handoff. This distinguishes it from sibling getter tools like ata_get_evidence_maturity or ata_get_research_plan.

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 tells the agent when to use the tool: 'Use after context loss or before expensive tools.' It does not name alternative tools or state when not to use it, but the provided context is clear and actionable for a read-only retrieval tool.

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

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

Annotations already convey readOnlyHint=true, idempotentHint=true, and destructiveHint=false negative behavior. The description adds positive behavioral context beyond annotations: it reveals polling semantics, the list behavior when jobId is omitted, and the fact that the result is included once the job succeeds. No contradiction with annotations.

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

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

The entire description is one front-loaded sentence that packs purpose, parameter behavior, and return payload into a compact form. Every phrase earns its place, with no filler or repetition of the title.

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

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

For a read-only polling tool, the description covers the main action, the optional jobId behavior, and return fields (status, progress, credits, result). However, it does not clarify the undocumented caseStudyId and researchRunId parameters, nor define what 'recent jobs' means. With no output schema, a bit more detail on list-mode ordering or job lifecycle would make it complete, but it is still adequate.

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 50%: jobId and includeResult have descriptions, but caseStudyId and researchRunId do not. The tool description enriches jobId ('omit to list recent jobs') and hints at includeResult's effect ('full tool result once it succeeds'), but it adds no meaning for the two undocumented parameters, leaving the agent to guess their purpose.

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 ('Poll') and a clear resource ('background research job') and names the exact data returned: status, progress, credits, and the full tool result. It also distinguishes the list mode ('omit jobId to list recent jobs') from the single-job polling mode, making its purpose unambiguous relative to sibling tools like workflow or task status.

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 clearly states when to use the tool: poll a background research job, or omit jobId to list recent jobs. It gives concrete invocation context, though it does not explicitly say when not to use it or name alternative sibling tools (e.g., ata_get_research_workflow_status).

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior; the description adds useful context with 'bounded' (implies size limits) and 'sanitized' (implies redaction). It does not detail pagination or output shape, but the annotations lower the bar.

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

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

A single front-loaded sentence that communicates the resource, scope, and contents without redundancy. Every phrase 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 read-only getter with six optional parameters and no output schema, the description gives the general purpose and contents but omits whether one of caseStudyId/researchRunId is expected, limit defaults, and the meaning of the boolean flags. Adequate but with clear gaps.

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

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

Schema description coverage is only 17%, so the description must compensate, but it only loosely maps to caseStudyId/researchRunId and says nothing about limit or the include* flags. The schema's own description covers only includeCandidateScriptSource.

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 ('Return') and a distinct resource ('Algo Agent research notebook'), and enumerates contents (journal records, evidence, maturity, lessons, recent run items). This clearly differentiates it from sibling getters like ata_get_research_plan or ata_get_research_task.

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 no when-to-use or when-not-to-use guidance and names no alternatives. It only says the notebook is 'for a case study or research run,' leaving an agent to infer when to call this versus the many related getter tools.

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

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

Annotations already indicate read-Only, idempotent, non-destructive behavior. The description adds that it is derived from multiple sources, but does not explain whether the plan is dynamically computed or static, or how it reflects task progress updates. With annotations covering the basic safety profile, the description adds moderate value.

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 that conveys the core purpose and data sources, without unnecessary words. It is front-loaded with the main action ('Return the current methodology task plan').

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 retrieval tool with three parameters and no output schema, the description should clarify the expected content of the plan and how parameters influence it. It lacks guidance on what constitutes a 'task plan' and how it relates to research runs or case studies, leaving the agent to guess.

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 description coverage and no parameter documentation in the description, the agent has to infer that 'limit' controls result count and that caseStudyId/researchRunId filter the plan. The description does not explain how these parameters affect the returned plan, which is a significant gap.

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

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

The description clearly states the tool returns the current methodology task plan, specifying its sources (case-study ledger, research notebook, evidence maturity, MCP task-progress notes). This distinguishes it from siblings like ata_get_research_notebook or ata_get_evidence_maturity, which would return individual components.

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 it's used to retrieve the current plan, but does not explicitly contrast with sibling tools that might also return plan-like information (e.g., ata_plan_case_study_hardening). No guidance on when to use this versus other getters or planning tools is provided.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description aligns by saying 'Return'. It adds useful context that the result is a projection rather than the raw job payload, but it does not describe not-found behavior, latency, or the concrete shape of the projection. This is adequate but not rich.

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

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

A single, front-loaded sentence with no filler. Every phrase earns its place and the key qualifiers ('MCP task-compatible', 'status projection', 'durable', 'one') are packed in without unnecessary elaboration.

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 low-complexity getter with full schema coverage and safety annotations, the description is mostly sufficient. However, with no output schema, it leaves the concrete fields of the 'status projection' unspecified, and the missing sibling differentiation weakens an agent's ability to confidently select it. Slightly more detail on the returned projection or a pointer to the job-status sibling would make it 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% and both parameters have descriptions (taskId is the durable jobId; includeJob adds the raw payload), so the description does not need to add parameter detail. It reinforces 'durable ATA research job' but adds no meaning beyond the schema, so the baseline of 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 a specific verb ('Return') and names a precise resource ('MCP task-compatible status projection') scoped to a single durable ATA research job. It is not a tautology, but it does not explicitly contrast with sibling ata_get_research_job_status, so the agent must infer the difference from the 'projection' wording.

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 phrase 'MCP task-compatible status projection' implies this tool is for obtaining an MCP-compatible status view, and the one-job scoping implies a single taskId. However, it gives no explicit when-not-to-use guidance or alternative routing relative to ata_get_research_job_status or ata_get_research_task_result, leaving selection partly to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description carries a lighter burden. It adds the useful behavioral constraint that the job must be completed and that the result is 'MCP task-compatible,' but it does not disclose what happens for incomplete jobs, error behavior, or the response envelope.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes either to what the tool returns or the precondition that the job is completed.

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

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

For a simple read-only getter with full schema coverage and safety annotations, the description is largely sufficient. The absence of an output schema makes the vague phrase 'MCP task-compatible final result' a minor gap, and there is no discussion of the not-yet-completed case, but the agent still has enough to invoke 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 description coverage is 100%, so the parameter semantics are already fully documented in the schema. The description adds no additional meaning about taskId or includeJob beyond what the schema provides, making the baseline score of 3 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 ('Return') and a clear resource: the final result of a completed durable ATA research job. It is distinctly a result-retrieval tool, but relies on the phrase 'final result' rather than explicitly naming how it differs from sibling tools like ata_get_research_task or ata_get_research_job_status.

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

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

Usage context is implied by the word 'completed': the tool is for finished research jobs, not in-progress ones. However, there is no explicit when-to-use guidance, no exclusion of alternatives, and no mention of when to prefer a sibling getter such as ata_get_research_task or ata_get_research_job_status.

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

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

Annotations already convey readOnly, idempotent, and non-destructive behavior, so the description carries a lower burden. It usefully adds that this targets platform-managed workflows and is scoped to the bound case study, but it does not disclose response shape, status meanings, or pagination behavior. No contradiction with annotations.

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

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

One tightly constructed sentence with no filler. The primary use case is front-loaded, and the secondary mode is appended in a single clause.

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

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

For a read-only polling tool, the two main usage modes are stated and the annotations cover safety. However, with no output schema and two parameters lacking meaningful description, an agent cannot fully determine the role of researchRunId or whether caseStudyId must correspond to the bound case study. Slightly incomplete for a 4-parameter tool.

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

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

Schema description coverage is only 50%, and the description only adds meaning for workflowJobId (via its omission behavior) and 'bound case study' context for caseStudyId. researchRunId remains completely unexplained, and includeResult's behavior is only stated in the schema, not the description. The description does not compensate enough for the undocumented 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 uses specific verbs ('Poll', 'list') and identifies the exact resource ('platform-managed research workflow') and the key selector (workflowJobId). It clearly distinguishes the two invocation modes and does not merely restate the title.

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 usage conditions: pass workflowJobId to poll a specific workflow, or omit it to list recent workflows for the bound case study. It does not explicitly mention when to prefer sibling tools like ata_get_research_job_status, but the core call pattern is unambiguous.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only behavior is fully covered. The description adds context about what the returned pattern is for, but does not add further behavioral details such as output format or edge cases. This matches the lower bar set by strong annotations.

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

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

A single, front-loaded sentence states the verb, resource, and purpose without any filler or repetition. Every phrase 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 zero-parameter, read-only retrieval tool with annotations covering safety and idempotency, the description is complete. An agent knows what it will get and why it would call this tool, and there is no missing behavioral or schema information that would prevent correct invocation.

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

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

The tool has zero parameters and schema description coverage is 100%, so the schema leaves nothing undocumented. The description does not need to explain parameters, and the baseline of 4 for parameterless tools 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 names a specific verb ('Return'), a specific resource ('Pine Script webhook output-router pattern'), and the purpose (generating Algo Trade Analytics and TraderPost payloads from one strategy script). This clearly distinguishes it from the unrelated research/analysis siblings in the tool list.

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 conveys clear context: use this tool when you need the router pattern to generate ATA/TraderPost payloads from a single strategy script. It does not explicitly state when not to use it or name alternatives, but no sibling tool appears to offer this pattern, so the guidance is adequate.

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 annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by disclosing the specific return content—server health and available read-only tool names—but does not go further into details like auth requirements, rate limits, or output structure.

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, direct sentence with no filler. It front-loads the action and immediately states the result, making it easy for an agent to parse.

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

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

For a zero-parameter, read-only health tool, the description is sufficient: it states what the agent will receive. It does not specify the exact shape of the health payload, but the annotations cover behavioral safety, and there is no output schema requirement to satisfy.

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 accepts zero parameters, so there are no parameter semantics to clarify. Baseline 4 applies because there is no parameter information needed and no schema coverage concerns.

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 action verb ('Return') plus a clear resource ('admin MCP server health and available read-only tool names'), making its purpose unambiguous. It also differentiates itself from sibling tools by focusing on server-level health and tool discovery, rather than research workflows or analytics.

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 usage context is implied by the word 'health': an agent would call this to check server status and enumerate read-only tools. However, it does not explicitly describe when to use it over alternatives or any preconditions, leaving the guidance mostly inferential.

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

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

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds useful context about actor scoping and the compact output nature, which goes beyond the annotation fields and helps the agent predict what the call will return.

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

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

The description is a single, front-loaded sentence with no filler. Every phrase contributes meaning: action, resource, actor scope, and output shape.

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, optional-parameter listing tool, this may be minimally usable without further detail. Still, the lack of any parameter descriptions and the absence of an output schema leave meaningful gaps about filtering behavior and the exact structure of the returned data.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented limit, status, and symbol parameters. It only vaguely references 'scope fields' and 'compact counts,' which does not clearly explain what each parameter controls or how they should be used.

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

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

The description names a specific action (list), a concrete resource (case studies), and a distinguishing scope ('for the configured actor user'). It also hints at the returned shape ('compact counts and scope fields'), which separates it from sibling tools like ata_load_case_study.

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 makes it clear that this tool is for listing case studies, so the basic use case is implied. However, it does not explicitly say when to prefer this over related tools such as ata_list_resources or ata_load_case_study, nor does it state any exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the scoping detail that only templates for clients without native MCP prompt support are listed, but it does not describe the return shape or empty-list behavior; without an output schema that would have been useful.

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

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

The description is a single front-loaded sentence with no wasted words. It states the action, resource, and target audience 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 zero-parameter, read-only list operation with annotations covering safety and idempotency, the description is complete enough. An agent knows exactly what the tool returns conceptually and when to call it.

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 and schema description coverage is 100%, so there is no parameter burden for the description to carry. The baseline of 4 applies because no parameter-level clarification is needed.

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 ('List'), names the resource ('ATA MCP prompt templates'), and adds an audience qualifier ('clients that cannot use native MCP prompts') that distinguishes it from native MCP prompt mechanisms. It also contrasts naturally with sibling ata_get_prompt (list vs. retrieve).

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 clearly indicates when to use the tool: for clients that cannot use native MCP prompts. It does not explicitly name alternatives or exclusions, but for a simple zero-parameter list tool the context is sufficient.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to restate those. It adds useful context beyond annotations: the reports belong to the bound actor and the tool cannot link reports to a case study, clarifying an important boundary.

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

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

Two sentences with no filler. The core action, report types, and filters appear first, followed by a one-sentence behavioral caveat. Every phrase 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 five-parameter tool with no schema descriptions and no output schema, the description covers the main purpose and filter dimensions but omits limit behavior and linkedOnly specifics. The 'scope and summary' phrase gives some return intuition, but an agent would likely need to inspect the schema further to use all parameters confidently.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It maps type, symbol, and linked case study filters in words, but does not explicitly explain limit or linkedOnly semantics, nor any defaults or constraints. It compensates partially, not fully.

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

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

The description names a specific verb and resource: 'Find the bound actor's saved analysis reports' and enumerates the report types (alerts-vs-fills, backtesting-vs-alerts). It also differentiates the tool from a linking action by explicitly stating the agent cannot link reports to a case study.

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

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

It states the intended context: read-only discovery so the agent can surface reports for the USER to attach. It also gives an exclusion by saying the agent cannot link reports itself. It does not name alternative sibling tools explicitly, but the usage context is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a bit of context with 'durable' and 'task-compatible facade,' hinting that this returns task projections rather than raw jobs, but it does not explain behavior such as ordering, pagination, or the meaning of the projection.

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 concise sentence and gets to the action immediately. It is not bloated, and the opening word 'List' is an appropriate front-loaded verb. However, some phrasing like 'MCP task-compatible facade' is jargon-heavy and could be clearer without adding 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 tool with six optional parameters, low schema description coverage, and no output schema, the description leaves too much unspecified: return shape, default limit behavior, filtering semantics, and how this relates to other ATA job/task tools. The annotations clarify safety but not usage or results, so the definition is only minimally adequate.

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 only 17%, with five of six parameters undocumented. The description does not compensate: it mentions 'recent' but does not clarify limit, jobType, activeOnly, caseStudyId, or researchRunId. The only parameter described in the schema, includeJobs, carries the explanatory burden alone.

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

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

The description names a specific resource ('recent durable ATA research jobs') and a clear action ('List') through a distinctive 'MCP task-compatible facade.' This is more specific than a tautology and gives some sense of scope, though it does not explicitly differentiate itself from sibling tools like ata_get_research_task or ata_list_research_reports.

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 no guidance on when to use this tool versus the many sibling list/status tools. It only implies that this is for recent durable jobs, but does not mention alternatives, exclusions, or when a different tool like ata_get_research_task or ata_get_research_job_status would be more appropriate.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds modest context by mentioning the skill:// methodology guidance, which hints at resource types, but does not disclose output format, pagination, or how the listing relates to ata_read_resource.

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 that front-loads the action and object, then adds a clarifying example. There is no filler or redundancy; every word carries meaning.

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 parameterless list tool with annotations covering safety and no output schema, the description is reasonably complete. It names the resource category and a specific scheme, though it could optionally mention that the result is a list of resource identifiers for use with ata_read_resource.

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 baseline is 4. The description adds value by scoping the resource types ('guidance and manifest resources', 'skill:// methodology guidance'), which helps the agent understand what the listing will contain.

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 clear verb ('List') and a specific resource ('ATA MCP guidance and manifest resources'), further clarified by 'including skill:// methodology guidance'. It distinguishes from sibling list tools like ata_list_prompts and ata_list_case_studies by focusing on 'resources', though it does not explicitly name 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?

There is no guidance on when to use this tool versus other list tools or ata_read_resource. The description only states what it does, leaving the agent to infer that it is for discovering resources, and provides no explicit when-not or alternative routing.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description does not contradict them. It adds useful behavioral context by specifying actor-user scoping and the included related data. The 'configured actor user' prerequisite is not explained, but the added scope outweighs that gap.

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

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

The description is a single, front-loaded sentence that states the operation first and then lists the included data with no filler. Every clause contributes useful 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?

The core operation is clear and adequate for a simple read-only load, but important context is missing: what 'configured actor user' means, what limit applies to, and what the response contains beyond the listed items. Since there is no output schema and no parameter documentation, these gaps make the description only minimally complete.

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

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

Schema description coverage is 0%, so the description must compensate for explaining caseStudyId and limit. It does not: caseStudyId is only inferable from its name, and limit's meaning (likely capping included versions or reports) is never clarified. The description adds no real semantic value beyond the bare property names.

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 and resource ('Load one case study') and enumerates the loaded content (recent versions, trials, promotions, linked reports). It is clearly distinct from list-style siblings like ata_list_case_studies, but it does not explicitly disambiguate from the near-identically named sibling load_case_study.

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

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

No usage guidance or alternative routing is provided. The description never states when to use this tool versus ata_list_case_studies, compare_trials, or load_case_study; the intended choice must be inferred from the phrase 'Load one case study.'

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

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

Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds a valuable behavioral guarantee beyond annotations: it will not expose token secrets or raw tool arguments, which is important safety context for an agent deciding whether to invoke this 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, front-loaded sentence with no filler. The main capability comes first, and the non-exposure clause adds useful safety context without bloat.

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 is simple and annotations cover its safety profile, but the description leaves parameter semantics largely to inference and offers no usage guidance relative to sibling tools. It names the return content well, but an agent would still need to guess what 'scope' and 'windowDays' mean in practice.

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

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

Schema description coverage is 0%, so the description carries the full burden of parameter explanation, but it only loosely references 'recent metered usage' and never explains scope, windowDays, or recentLimit. The enum and numeric bounds are visible in the schema, but the description adds little semantic meaning beyond what the parameter names already imply.

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 ('Return') and names a concrete resource: 'MCP-visible credit balance and recent metered usage for the bound actor'. It also adds an explicit non-goal ('without exposing token secrets or raw tool arguments'), which further distinguishes the tool's purpose from broader account or health queries.

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 use—checking one's own metered usage and credit balance—and scopes it to the 'bound actor'. However, it does not name sibling alternatives or explicitly state when not to use this tool, stopping short of the highest bar for usage guidance.

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

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

Annotations already supply readOnly, idempotent, and non-destructive hints. The description adds useful behavioral context by stating that this tool does not execute and that execution is deferred to client-called tools. It does not detail plan side effects or evidence-gate semantics, but it does not contradict the annotations.

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

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

The description is two sentences with a clear front-loaded action and a useful clarifying second sentence. There is no wasted text, though it is not maximally informative.

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

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

With no output schema and zero parameter documentation, the description leaves an agent without enough information to invoke the tool correctly. The annotations help cover safety and idempotency, but the missing parameter semantics and unknown output structure are significant gaps.

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

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

Schema description coverage is 0% for the four parameters, and the description provides no semantic guidance for limit, maxSteps, caseStudyId, or researchRunId. The only weak connection is the phrase 'case study' hinting at caseStudyId, but this does not compensate for the complete absence of parameter documentation.

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 ('Plan') and resource ('case study hardening') and clarifies the tool's scope as methodology and evidence-gate steps. It is not a tautology, and the added distinction that execution happens separately helps separate it from execution-oriented 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?

The description conveys the key context that this tool only plans, and that execution happens when the client calls credit-metered research tools. However, it does not explicitly name when to prefer this over related siblings such as ata_get_research_plan or ata_start_research_workflow, nor does it state any exclusion conditions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds 'guidance or manifest resource' context and 'tool-only clients,' but it does not disclose behavior such as error handling, whether the resource must exist, or the shape of the returned data.

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

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

The description is a single front-loaded sentence with no filler. Every word contributes to identifying the tool's action, target, and access mechanism.

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

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

For a simple read operation, the description is minimally adequate, and annotations cover the safety profile. However, with no output schema and no parameter format details, an agent is left to guess at return semantics and URI source, making it incomplete for confident invocation in a large sibling set.

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

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

Schema description coverage is 0%, and the description only repeats that the resource is selected 'by URI' without explaining URI format, how to discover valid URIs, or what kinds of URI values are accepted. Since schema coverage is low, the description was expected to compensate but does not.

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 ('Read'), a resource ('ATA MCP guidance or manifest resource'), and the selection mechanism ('by URI'). It is clear enough to distinguish from the sibling tool ata_list_resources, though it does not explicitly name that alternative.

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 no explicit guidance on when to use this tool versus alternatives such as ata_list_resources or ata_get_prompt. There is only a weak implication that it should be used when a URI is already known; no exclusions or sibling routing are provided.

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

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

With readOnlyHint=false and idempotentHint=false, the append action is consistent with annotations and adds useful detail: each call appends a bounded note to an active notebook and is visible in the platform ledger. It does not cover failure modes or duplicate behavior, but annotations already establish the safety profile.

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

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

Two sentences with no filler; the verb+resource is front-loaded and the usage guidance occupies the second sentence. Every sentence 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?

Despite clear purpose and timing, the tool has 11 parameters, no output schema, and no parameter descriptions. The description leaves the agent without guidance on which optional identifiers to supply, how status/detail/summary relate, or what the call returns.

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

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

Schema description coverage is 0% and the description names none of the 11 parameters, including the three required fields. Even the status enum and optional relationship parameters (gateId, trialId, researchRunId, evidenceId) receive no semantic explanation.

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 and object: 'Append a bounded methodology task-progress note to the active Algo Agent research notebook.' It names the exact artifact and context, and this action is distinct from sibling get/start/cancel/analysis 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?

It gives an explicit call-window: 'Use after planning or gate work,' and explains the purpose ('so the platform ledger can show what the external MCP client did'). It does not state exclusions or alternatives, so it stops short of a 5.

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

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

The description adds context beyond annotations by detailing the specific status contents returned, such as missing gate, protocol trial counts, and platform handoff guidance. It is consistent with the readOnlyHint, idempotentHint, and destructiveHint annotations. It does not discuss error conditions or absent bound runs, but the safety profile is already covered by annotations.

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

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

The description is a single front-loaded sentence starting with 'Return' and packs seven concrete pieces of information without padding. The list is somewhat dense, but it is efficient and free of 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 helpfully lists the return contents, which matters because there is no output schema, and the annotations cover the read-only safety profile. However, it lacks any explanation of the input parameters and does not provide enough routing context among the many sibling status and workflow 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 description coverage is 0%, and the description does not mention caseStudyId or researchRunId at all. The description fails to explain how these optional parameters influence the returned bound run or workflow status.

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 clear verb ('Return') and enumerates specific resources: bound research run, case study, active hypothesis/protocol, protocol trial counts, missing gate, next required tool, and platform handoff guidance. It clearly communicates what the tool does, but it does not explicitly distinguish itself from the near-identical sibling ata_get_research_workflow_status.

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

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

The description implies the tool is for checking workflow status and knowing the next required tool, but it does not state when to prefer this over sibling status tools such as ata_get_research_task_status or ata_get_research_job_status. No exclusions or alternative routing guidance is provided.

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

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

Annotations already convey readOnly=false and idempotent=true; the description adds the key behavioral fact that resuming creates a new durable workflow job rather than continuing the old one in place. It does not explain side effects on the original job, but that is partially covered by destructiveHint=false.

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

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

A single sentence that front-loads the action and adds the key qualification; no filler or repetition of schema information.

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

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

For a two-parameter workflow-control tool this is mostly adequate, but it leaves open what the call returns, how the new job is tracked, and what 'needs-review' means operationally. Since there is no output schema, these gaps matter for an agent deciding whether the call succeeded.

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

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

Schema description coverage is 0% and the description does not mention workflowJobId or idempotencyKey. workflowJobId is inferable from the tool name, but idempotencyKey gets no semantic explanation, and the description fails to compensate for the lack of parameter documentation.

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

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

The description names a specific action ('Resume'), a specific resource ('platform-managed research workflow'), and the condition ('stopped or needs-review'), and adds that it runs as a new durable job. This clearly distinguishes it from sibling start/cancel/status tools even without schema inspection.

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 intended scope: workflows that are stopped or need review. The 'Resume' verb and sibling names make the contrast with start/cancel/status evident, though it does not name an alternative tool outright.

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 discloses key behavioral traits: it is a durable background job, returns a jobId, requires polling, and mentions credit reservation/settlement. This adds significant context beyond annotations, which only indicate non-readonly and non-idempotent. The credit behavior is particularly valuable and not inferable from annotations.

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

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

The description is compact and informative, front-loading the purpose and key behavior. It includes the essential polling instruction and credit detail without redundancy. Minor redundancy with the tool's title but acceptable for a 3-sentence description.

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

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

This is a complex tool with a nested input object and multiple parameters. Without an output schema, the description should clarify what the caller receives (jobId) and how to get results, which it does. It also mentions credit behavior and idempotency as context. Missing explicit instructions on when to use each heavy tool, but that is tool-specific; the job wrapper is described adequately.

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 covers toolName with examples and description, input as nested object, and idempotencyKey. Description adds the critical nuance that input is exactly what you would pass synchronously, which is not obvious from the schema alone. However, caseStudyId and researchRunId are undocumented in the description)Skip, but schema coverage at 60% is moderate, so the description partially compensates. Given the nested input object, the clarification is valuable, so 4 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 tool starts a heavy research tool as a background job, explicitly lists the supported heavy tools, and distinguishes it from blocking calls. It also mentions the jobId and polling tool, making the purpose unambiguous and differentiated from siblings like ata_start_research_run or walk_forward_candidate.

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 it (for heavy research tools) and references the alternative to a blocking call implicitly. It names the polling tool for follow-up. However, it does not explicitly state when not to use (e.g., for lightweight operations), but the context is clear enough for an agent.

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

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

Annotations already indicate this is a write operation (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds the key behavioral fact that it creates a persisted ResearchRun bound to the MCP session, and that it is a prerequisite for other write tools. However, it doesn't disclose what 'bind' means for session lifecycle, whether repeated calls create multiple runs, or what the response contains. With annotations covering the basic safety profile, a 3 is appropriate.

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

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

Two sentences with no filler. The core action and the critical prerequisite are front-loaded. Every word 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 9-parameter creation tool with no output schema and no parameter documentation, the description is too thin. It explains the tool's role in the workflow but leaves the agent guessing about parameter semantics, return value, and side effects. The prerequisite context is valuable, but the overall completeness is inadequate for correct invocation.

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

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

Schema description coverage is 0%, and the description mentions none of the 9 parameters. The schema itself provides names and types but no semantic meaning (e.g., what 'metric' is for, what 'objectivePrompt' should contain, how dateRangeStart/End are formatted). With 9 parameters and zero coverage, the description must compensate but does not. This is a significant gap.

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

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

The description states a specific verb ('Create and bind') and resource ('persisted Algo Agent ResearchRun for this MCP session'), and it distinguishes itself by noting it is 'Required before write-capable research journal tools.' This clearly differentiates it from siblings like ata_start_research_job or ata_start_research_workflow, though it doesn't explicitly name those 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 gives clear context: this tool must be used before write-capable research journal tools. It implies a sequencing prerequisite but does not explicitly state when NOT to use it or name alternative tools like ata_start_research_job or ata_start_research_workflow. The 'Required before' phrasing provides strong usage guidance, but exclusions are absent.

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

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

The description goes well beyond the basic annotations by disclosing that the workflow can save scoped research lessons unattended, that it never permits editor changes or promotion claims, and that it returns a workflowJobId to poll via ata_get_research_workflow_status. This is meaningful behavioral context that the annotations alone do not 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?

Three tight sentences: the first delivers the action and core inputs, the second states the key behavioral caveat, and the third gives the expected return and next step. There is no filler, and the most important information is front-loaded.

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

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

For a 12-parameter tool with a nested scope object and no output schema, the description provides a useful return contract and polling route, plus important safety guardrails. However, it does not disambiguate this tool from sibling start/run/resume/cancel workflow tools, and it leaves several optional parameters under-documented, so the overall picture is adequate but incomplete.

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

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

Schema description coverage is only 33%, and the description does not sufficiently compensate. It names high-level input categories like scope, gate policy, search-family hints, and creative brief, but leaves important parameters such as minBaselineImprovement, requiredPromotionState, researchRunId, and caseStudyId semantically unexplained. The budgetCredits language largely repeats the schema's own 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 clearly identifies the specific action ('Start') and resource ('platform-managed Algo Agent research workflow') and lists the primary inputs. It does not explicitly differentiate itself from sibling start tools like ata_start_research_job or ata_start_research_run, so it falls just short of a 5.

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

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

The description implies usage via the phrase 'platform-managed research workflow' and gives conditional guidance for autonomousResearchStateWrites, but it never explains when to choose this tool over ata_start_research_job, ata_start_research_run, or ata_resume_research_workflow. There are no exclusions or alternative routing, so usage guidance is only implicit.

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

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

Annotations declare readOnlyHint=true and idempotentHint=true, and the description's 'Deterministically validate' aligns with these. The description adds context about 'current evidence maturity' and the final answer's claims, but it does not disclose behavior like what happens on invalid states, whether it returns a boolean or detailed report, or any rate limits. Since annotations cover the safety profile, a middle score is appropriate; the description could add more behavioral detail but does not contradict the annotations.

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

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

The description is a tight, two-sentence block that leads with the core purpose and then gives a specific directive. Every word contributes to understanding the tool's role. There is no fluff or redundancy, and the structure is front-loaded with the key validation action before the usage instruction.

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 8 parameters but only 2 required, and the description covers the main workflow trigger. However, there is no output schema and the description does not mention what the tool returns (e.g., a validation status, error message, or updated state). Since the tool is a gate, knowing the return format would help the agent act on the result. Still, the description and schema together cover parameter usage well, so it is largely complete for a read-only validation tool.

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

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

Schema description coverage is 100%, so the schema already explains each parameter. The description goes beyond the schema by providing a strategic mapping for the 'state' parameter ('Request production_candidate for paper-ready, trade-ready, production-ready, or execution-validated language'). This adds practical semantic meaning that helps the agent choose the correct enum value, which is genuinely useful and not present in the schema.

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

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

The description states a specific, deterministic validation action on readiness/promotion states, listing the exact claims it gates ('research-validated, risk-validated, paper-ready, production-ready...'). This clearly distinguishes it from the analysis and research-management siblings, which perform different tasks. The verb 'validate' and resource 'readiness state' are unambiguous and tied to a concrete workflow.

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 explicit when-to-use guidance: 'Call this before saying a strategy is research-validated...' It also provides a concrete mapping instruction for when to request production_candidate. This is direct, actionable, and leaves no ambiguity about when to invoke the tool, satisfying the 'when to use' criterion without needing to enumerate 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?

Annotations are all false and provide little guidance, so the description carries the burden of behavioral disclosure. It does communicate that the action mutates state by closing a branch and that the branch may be abandoned. However, it does not explain side effects, whether closure is reversible, or what statuses are recorded, leaving meaningful 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?

One tight sentence that front-loads the action and outcome. Every part earns its place, and there is no redundant restatement of the tool name or schema content.

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

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

For a tool with 8 parameters, no output schema, and sparse annotations, the description gives the core scenario but omits details about how the statuses should be supplied, what closing implies for the research run, and what a successful closure returns or confirms. The schema fills many gaps, but the overall definition is only minimally complete for such a state-changing lifecycle action.

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 75%, so descriptions already exist for rationale, protocolId, caseStudyId, hypothesisId, researchRunId, and mcpIdempotencyKey. The tool description adds slight semantic value by implying that protocolId and hypothesisId default to active items and that statuses relate to evidence outcomes, but it does not meaningfully detail the status enums or the idempotency requirement.

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 ('Close') with a clear resource ('research hypothesis/protocol') and a precise condition ('after evidence supports, falsifies, or abandons the branch'). This clearly distinguishes it from creation and analysis siblings like create_research_hypothesis or analyze_signal_audit.

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 states when to use the tool: after evidence supports, falsifies, or abandons a branch. It also clarifies that it applies to the 'active or specified' hypothesis/protocol, giving enough context for correct selection among lifecycle tools. It does not explicitly name alternatives or exclusion cases, so it falls short of a 5.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, and the description's 'Persist' action is consistent with those. It adds useful behavioral context beyond the annotations: the lesson is durable, can guide future research, degrades to audit-only without evidence, and must follow a specific body format. No contradiction with the annotations.

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

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

Three sentences, each earning its place: the core action, the evidence requirement, and the audit-only fallback plus body format. It is front-loaded with the purpose and contains no filler or redundant restatement of schema 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 complex 12-parameter write action with no output schema, the description covers the essential invocation context: when to commit a lesson, what evidence to attach, how to format the body, and what happens without evidence. The schema supplies parameter-level constraints, and the destructiveHint annotation signals irreversibility, so the description does not need to repeat those.

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

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

The description adds meaning to key parameters by explaining that evidenceIds should come from the current run's journal and that body requires 'Why' and 'How to apply' lines. However, many parameters such as type, symbol, timeframe, caseStudyId, and mechanismFamily receive no explanatory coverage. With schema description coverage at 58%, the description helps but does not fully compensate for the gaps.

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

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

The description states a specific verb and resource: 'Persist a durable ResearchLesson after evidence supports, falsifies, or narrows a hypothesis.' This clearly distinguishes it from read-only siblings like recall_research_lessons. It does not explicitly name an alternative tool, but the write-vs-read distinction is clear from the wording.

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 a clear trigger condition: use after evidence supports, falsifies, or narrows a hypothesis. It also instructs the agent to include evidenceIds and warns that without current evidence the lesson is saved as an audit-only note. It does not list exclusions or explicit alternatives, but the conditions are sufficient for selection.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral details beyond a generic compare statement—no output shape, ordering, defaults, or side-effect context. It does not contradict the annotations, but it adds no beyond-annotation value.

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 with no filler. The main action is front-loaded, and the purpose clause adds useful context without redundancy.

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

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

With five optional parameters, no output schema, and only a one-line description, the agent is left to guess at parameter semantics and the nature of the comparison result. The annotations cover safety, but not input meaning or expected output, leaving a significant information gap.

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

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

Schema description coverage is only 40%, leaving topN, caseStudyId, and versionHashes undocumented in the schema. The description only loosely hints at 'case-study trials' and 'strategy variants' but does not explain what these parameters mean, how they interact, or what topN limits. It fails to compensate for the low schema 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?

The description uses a specific verb ('Compare') with a clear resource ('case-study trials or strategy variants') and a purpose ('before drawing a research conclusion'). It also stands apart from the many sibling analyze_* tools by naming a distinct comparison action.

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 a clear temporal usage context: use this before drawing a research conclusion. However, it does not explicitly state when not to use it or mention alternative tools, so it lacks exclusion 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?

The annotations already establish the tool is not read-only, not idempotent, and not marked destructive, but the description adds no behavioral context beyond 'Persist.' It does not disclose that an existing active hypothesis/protocol can be replaced via rebaseReason, nor the idempotency-key requirement, both of which are material for a mutating action.

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

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

The description is a single, front-loaded sentence with no filler. It states the essential purpose immediately and earns its place.

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

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

Despite a rich schema, this is a mutating 9-parameter tool with no output schema and no usage or side-effect guidance in the description. Important operational details like rebase behavior, run binding defaults, and idempotency requirements are left entirely to the schema, making the description incomplete for reliable tool selection and invocation.

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

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

Schema description coverage is 89%, so the schema carries the parameter documentation burden. The description adds little beyond restating that the hypothesis is falsifiable, which the statement parameter already says. This matches the baseline for high schema 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?

The description clearly states the verb ('Persist') and resource ('one falsifiable hypothesis'), and positions it as the thing the next candidate and protocol must test. It distinguishes the tool's artifact from related sibling tools like propose_strategy_candidate and define_experiment_protocol, though it does not explicitly name an alternative.

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 phrase 'that the next candidate and protocol must test' implies the tool is used early in the research pipeline, before defining a candidate or protocol. However, it gives no explicit guidance about when to prefer this over related tools, nor any exclusions or 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'Confirm' wording aligns with these. The description adds that the binding is 'persisted' and that objective/scope are returned, but it does not explain behavior on missing bindings, error cases, or side effects beyond what annotations convey.

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

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

The description is a single concise sentence with no filler. It front-loads the core action and return value, though the terseness contributes to the lack of usage and parameter guidance.

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 4 optional parameters and no output schema, the description is too thin. It names the return values but does not specify parameter roles, when to call it, or what 'confirm the persisted binding' means operationally, leaving an agent to infer critical calling context.

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

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

Schema description coverage is 75%, and most parameters already have meaningful schema descriptions. The tool description adds nothing about the parameters themselves; notably, it does not clarify the 'objective' parameter, which lacks a schema description and is also mentioned in the return value, creating potential ambiguity.

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 action ('Confirm the persisted ResearchRun binding') and the expected return ('objective and scope'), going beyond a restatement of the name. However, the term 'ResearchRun binding' is domain-specific jargon and the description does not explicitly distinguish this from sibling tools like ata_start_research_run or create_research_hypothesis.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description implies the tool is for confirming an existing binding, but it never tells the agent when to choose this over ata_start_research_run or ata_resume_research_workflow.

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

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

Annotations only say this is a non-read, non-destructive, non-idempotent write. The description adds meaningful behavior beyond that by warning that development-window dates must not be substituted because the protected data layer applies the development boundary during measurements, and by explaining scope inheritance. It does not fully disclose replacement/overwrite behavior involving rebaseReason, but nothing contradicts the annotations.

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

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

Three sentences front-load the purpose, then add the two most decision-relevant constraints. Every sentence contributes, 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 16-parameter write operation with sparse annotations and no output schema, the description covers the critical workflow link to hypothesisId, scope inheritance, and date handling. It is not exhaustive about edge cases such as replacing an existing active protocol, but the essential call path is clear.

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 50% schema description coverage, the description compensates by naming the key persisted concepts and adding specific semantics not in the schema: omit scope fields to inherit and never substitute development-window dates. It does not explain every optional field, but schema descriptions cover the remaining major 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 names a specific action, 'Persist', the resource (experiment protocol fields tied to hypothesisId returned by create_research_hypothesis), and the exact fields involved: market scope, split, metric, min trades, and rejection criteria. This clearly distinguishes the tool from sibling hypothesis-creation and experiment-closing 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?

It gives workflow context by requiring the hypothesisId from create_research_hypothesis and gives a scoping rule for durable workflows (omit scope fields to inherit, or repeat exactly). It lacks an explicit 'when not to use' or named alternatives, so it stops short of a 5.

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

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

Annotations already establish readOnly, idempotent, and non-destructive behavior, lowering the burden on the description. The description adds normative detail that the call should rely on protocol trade floors rather than per-call totalTrades, but it does not disclose return shape or any other behavioral outcome. With read-only idempotent tooling, 3 is appropriate.

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

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

Two sentences, no filler, with the operation front-loaded and the most important usage constraint in the second sentence. Every sentence 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 21-parameter tool with no output schema and low schema description coverage, this is too thin. There is no return-value or outcome guidance, no coverage of evaluationMode/training-split/objective semantics, and no mapping to sibling tools such as verify_candidate or walk_forward_candidate. The trade-floor guidance is useful but leaves most of the decision space undocumented.

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

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

The description adds real meaning for the constraints parameter and protocolId interaction: declare trade floors in the protocol and do not duplicate a per-call totalTrades constraint. However, schema description coverage is only 33%, and with 21 parameters, many others (evaluationMode, trainTestSplit, objectiveMetric/objectiveDirection, baselineInputs/candidateInputs) are left uncompensated by the 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 identifies the action ('Compare') and target ('candidate against baseline evidence') and names the central required input (protocolId). It is specific about trade-floor handling, but it does not name any sibling tools such as verify_candidate or compare_trials, so differentiating it from those alternatives is left to the agent.

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 clear context for when to call: a candidate evaluation requiring a protocolId, and it gives a concrete do/don't instruction about protocol trade floors vs per-call totalTrades constraints. It stops short of explicit 'use X instead' guidance or exclusions, so it is not a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description's 'Summarize' is consistent with those annotations and adds a small amount of behavior (it produces a summary). It does not disclose return format, fields, or any edge behavior, but given the annotations cover the safety profile, this is adequate but not rich.

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

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

The description is a single, front-loaded imperative sentence with no filler; it is efficient and easy to scan. It is slightly too sparse for a 7-parameter tool, but for what it sets out to convey, it is structurally concise.

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

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

The tool has 7 optional parameters and no output schema, yet the description does not explain what 'regime/coverage/scope' mean, what inputs select them, or what the returned summary contains. An agent would struggle to know what arguments to pass and what to expect back.

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

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

Only 43% of schema parameters have descriptions, and the description itself does not explicitly explain symbol, startDate, endDate, or timeframe. The words 'regime', 'coverage', and 'scope' loosely allude to the dimensions but provide no concrete parameter guidance. With low schema coverage, the description should compensate, and it does not.

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

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

The description names a specific verb ('Summarize') and a clear resource ('market context' broken into regime, coverage, scope). It does not explicitly differentiate this from the large set of analyze_* sibling tools, but the phrase 'before proposing experiments' adds meaningful orientation.

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: 'before proposing experiments'. It does not mention alternatives or when not to use it, so it is slightly shy of a perfect score, but the workflow context is clear.

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

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

Annotations already include readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description need not repeat safety. It adds useful context: 'Sources are omitted unless explicitly requested by version id or latest version.' This indicates that the tool may not include all sources by default兒, which is a behavioral nuance not in the annotations. However, it does not describe return format or pagination, but given the annotations, a 3 is appropriate.

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

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

The description is one sentence, concise, and front-loads the core purpose. It does not waste words. The sentence is clear and readable. It could arguably be more structured (e.g., bullet points) but is appropriately sized.

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 6 parameters, no output schema, and moderate complexity, the description provides enough to understand the primary function but lacks specifics on return values. For a read-only, idempotent tool, the missing details (like what the exact return structure is) are somewhat less critical, but an agent might be uncertain about what data will be included and how to handle the options. With annotations covering safety, a 3 is appropriate but there is room to clarify the effect of parameters like maxTrialsPerExperiment and versionSourceIds.

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 only 33%, so the description must compensate. The description does not provide detailed explanations for most parameters (caseStudyId, versionSourceIds, maxTrialsPerExperiment, etc.). It mentions that sources are omitted unless requested, which relates to versionSourceIds and includeLatestVersionSource, but does not clarify their meaning beyond the schema. The baseline 3 is appropriate because the description adds minimal value; the schema has some descriptions for researchRunId and mcpIdempotencyKey, but the other parameters are undocumented in both.

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 loads a case study summary and related data (versions, experiments, trials, evidence). The verb 'load' and resource 'Case Study' are specific. It distinguishes from siblings like ata_load_case_study and ata_list_case_studies by mentioning the active case study and version handling, though it doesn't name a sibling explicitly.

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

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

The description implies it is for retrieving case study related information, but does not explicitly state when to use it versus alternatives (e.g., when to use ata_load_case_study instead). It mentions optional parameters like versionSourceIds and includeLatestVersionSource, but does not give clear guidance on when to use them or when not to use this tool. It covers some usage context (e.g., 'Sources are omitted unless explicitly requested') but lacks explicit alternatives.