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

The description goes beyond the destructiveHint annotation by specifying exactly what gets replaced ('the entire managed target strategy directory') and the safety step taken ('after rechecking every preimage hash'). It also communicates a prerequisite ('trusted local CLI approval record') that is not present in the annotations or schema.

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 compact: two short sentences that front-load the core constraint and then state the destructive behavior. Every sentence earns its place and there is no redundant or filler 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?

The description covers the destructive behavior and a prerequisite, but for a 4-required-parameter tool with zero schema descriptions, it leaves the agent without enough information to construct valid arguments. It does not reference sibling tools like prepare_strategy_changes that likely produce the required IDs, and it does not explain how idempotency_key or change_token should be obtained.

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 provides no explanation of any of the four required parameters (change_set_id, change_token, approval_id, idempotency_key). The parameter names are self-descriptive at a surface level, but the description adds nothing about their origin, format, or relationship to other tools.

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

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

The description clearly identifies the action ('Apply') and the resource ('strategy changes'), and adds an important scope constraint: 'only an exact change with a trusted local CLI approval record.' However, it does not explicitly distinguish itself from sibling tools like apply_strategy_repair or prepare_strategy_changes, so the differentiation is implied rather than named.

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 'Apply only an exact change with a trusted local CLI approval record' gives clear context about when this tool is appropriate: for exact, pre-approved changes only. It does not name alternatives or state when not to use it, so it stops short of a full 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?

Given that annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, the description adds value by explicitly stating that the old validation capability is invalidated. This is a meaningful behavioral side effect not captured by the annotations, though further side-effect detail is sparse.

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, focused sentence with no filler or repetition. It is concise but somewhat under-specified; it states the core action and side effect without 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?

With seven required parameters, zero schema descriptions, and no usage guidance, this description is far from complete for an agent to invoke the tool safely. The output schema reduces the need to explain return values, but the operational context and parameter semantics are still major 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%, so the description carries the full burden for explaining the seven required parameters. It only weakly hints at 'exact-hash' and 'validation', leaving draft_id, relative_path, content, expected_revision, and idempotency_key semantically unexplained.

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 ('apply') and names a concrete operation ('exact-hash repair') with a clear side effect ('invalidate the old validation capability'). This distinguishes it from siblings like apply_strategy_changes and validate_strategy_draft, though 'exact-hash repair' remains somewhat domain-specific jargon.

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 about when to use this tool versus alternatives such as apply_strategy_changes or validate_strategy_draft. No prerequisites, exclusions, or context for choosing this tool are provided, leaving the agent to guess based on the name alone.

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 safety profile is covered. The description adds useful scope by identifying what is audited, but it doesn't explain what 'audit' entails operationally or what the outcome reflects beyond the product-boundary check.

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

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

The description is a single well-structured sentence with no filler. The verb and resource are front-loaded, and every word contributes to the overall 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?

With zero parameters, read-only annotations, and an output schema present, the description covers the essential invocation context. The main gap is the lack of usage guidance or expected output semantics, but the low parameter complexity and available annotations make the description reasonably 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 tool has zero parameters, so there is no parameter burden for the description to carry. Schema description coverage is effectively complete, and the description adds no parameter-level detail because none 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 names a specific verb ('Audit') and a distinct resource ('source imports and dynamic execution') with a stated criterion ('against product boundaries'). It is clear enough to distinguish from siblings, though 'product boundaries' is somewhat vague and could use one clarifying phrase.

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 about when to use this tool compared to siblings like validate_strategy_spec, inspect_dataset, or doctor. The description implies an auditing use case but provides no explicit when-to-use or exclusionary 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 destructiveHint=true and idempotentHint=true. The description adds critical context beyond annotations: 'terminates the worker and candidate processes.' This discloses the concrete destructive effect, which is valuable for an agent deciding whether to invoke this tool. 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 description is extremely brief—two short sentences. The first sentence states the purpose, and the second adds the key destructive detail. It's front-loaded and efficient, though it could arguably include a bit more context without becoming bloated.

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 an output schema, so return values are covered elsewhere. The description covers the core action and the destructive effect. However, it doesn't explain the idempotency_key parameter's role or what happens if the job is already completed, which are relevant for a cancellation tool. The annotations cover safety, but the parameter semantics gap remains.

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 provides no explanation of what job_id or idempotency_key mean or how they should be formatted. The parameter names are somewhat self-explanatory, but the description adds zero value beyond the schema. With 0% coverage, the description should compensate but doesn't.

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 ('queued or running product job'), which clearly distinguishes it from sibling tools like start_strategy_run and get_run_status. It doesn't explicitly name a sibling alternative, but the action is unambiguous.

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

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

The description implies usage for queued or running jobs, which gives some context. However, it doesn't explicitly state when not to use it (e.g., for completed jobs) or mention alternatives like get_run_status for checking state first. The 'queued or running' qualifier provides partial 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 readOnlyHint=true and destructiveHint=false, and the description's 'Compare' is consistent with a non-mutating operation. It adds context that the comparison covers canonical metrics and provenance under comparison-profile-v1, but it does not describe output behavior, errors, or side effects; the annotations cover 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?

The description is a single sentence with no filler, front-loading the action ('Compare') and the subject. It is appropriately brief for a simple tool, though the brevity contributes to the under-specification of usage and parameters.

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 comparison tool with two self-named parameters and an output schema, the description covers the core purpose. However, it leaves 'comparison-profile-v1' and 'canonical metrics' undefined and provides no guidance on how this differs from related run tools, so an agent may lack enough context to know when it is the right call.

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 says nothing about left_run_id or right_run_id. The parameter names and titles are self-explanatory, but the description does not compensate for the missing schema descriptions or explain what 'left' and 'right' mean in this comparison.

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'), names the resource ('strategy runs'), and specifies the object ('canonical metrics and provenance') plus the profile version. It is the only compare tool among the siblings, so an agent can likely distinguish it from get_run_result or inspect_strategy, though it does not explicitly call out 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?

No guidance is given on when to choose this over siblings such as get_run_result, render_strategy_report, or audit_independence. It implies comparison between two runs, but there is no 'use this when...' or 'for X use Y instead' statement, so the agent must infer usage.

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

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

Annotations are all false and carry little positive information, so the description must carry the behavioral burden. It does add useful context: drafts are private, each call produces a new draft ID, and strategy_spec must satisfy a named contract. However, it does not disclose side effects, permissions, or failure 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?

The description is short and front-loaded. Every sentence earns its place: core purpose, schema contract, and non-idempotency. There is no filler, repetition, or restatement of the tool name.

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?

An output schema exists, so return values need not be explained. The required strategy_spec parameter is constrained via the contract URI, and the tool's creation behavior is clear. However, scaffold_profile is left unexplained, and no pointer to update/validate siblings is provided. This is adequate for basic calls but incomplete for full parameter understanding.

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

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

Schema description coverage is 0%, so the description must compensate. It meaningfully constrains strategy_spec by pointing to the strategy-spec-v1 contract URI, but it never explains scaffold_profile, its values, or its effect on the created draft. One of the two parameters is therefore entirely undocumented.

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

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

The description opens with a specific verb and resource: 'Create a private single-test or Python-bundle draft.' It also adds that each call creates a new draft ID, which helps distinguish this creation tool from siblings like update_strategy_draft and get_strategy_draft.

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 explicit guidance about when to use this tool versus update_strategy_draft, validate_strategy_draft, or prepare_strategy_changes. The non-idempotent creation behavior is implied, but no alternatives or prerequisites are stated, so the agent must infer usage on its own.

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 useful behavioral context beyond the annotations: it states the output is immutable and that identical inputs yield the same derived dataset ID, which concretizes the idempotentHint. 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 short, front-loaded, and every sentence contributes meaningful information. There is no filler or repetition of the tool name.

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 required nested typed_params object and the lack of any schema commentary, the description is not complete enough for an agent to know what parameters to pass for each supported profile. The output schema may cover return values, but the input side still has a critical documentation 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?

With 0% schema description coverage, the description must compensate. It does explain transform_profile_id values and expected_manifest_hash requirements, but it leaves typed_params completely unspecified even though it is a required free-form object. source_dataset_id is also only implied by its name, so the most ambiguous parameter has no semantic guidance.

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 ('Run one product-owned tabular transform') and makes the output clear ('new immutable dataset'). This clearly separates it from sibling tools like register_dataset or preview_dataset, and the supported profiles add further specificity.

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 the tool by listing supported profiles and requiring an exact manifest hash, but it does not explicitly state when not to use it or point to alternatives. Usage context is inferable rather than directly stated.

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 and destructiveHint=false, so the safety profile is covered. The description adds the three focus areas, but does not explain what running a diagnostic entails or what kind of output to expect beyond what the output schema presumably provides.

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, focused sentence that front-loads the action verb and immediately names the objects of diagnosis. It contains no filler, repetition, or 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 zero-parameter, read-only diagnostic with safety annotations and an output schema, the description identifies the domain well enough to guide usage. It could be slightly richer about the nature of the diagnostic, but the output schema likely covers return details.

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 input schema fully documents the input surface. The description correctly adds no parameter-specific details, matching the baseline for zero-parameter tools.

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

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

The description uses the concrete verb 'Diagnose' and specifies three distinct resources: package dependencies, configured roots, and Backtrader runtimes. This clearly distinguishes the tool from sibling tools focused on datasets, strategies, runs, and catalog operations.

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

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

The scope implies use for diagnosing environment, dependency, root, and runtime health, but the description does not state when to use this tool over alternatives or when not to use it. No explicit conditions or exclusions 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=true, the description adds substantial behavioral context beyond annotations: the snapshot is bundled and immutable, default returns are limited to counts/hashes/provenance, entry_count reports 1155 records, and pagination exposes total/has_more/truncated. No contradictions 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?

The description is concise and front-loaded with the primary purpose, then default behavior, then optional paging, then the alternative. There is minor wasted or malformed text in 'provenance (extensions.' which reads as an incomplete parenthetical, slightly hurting clarity.

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

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

For a read-only tool with an output schema, the description covers the essential context: default vs paged behavior, parameter ranges, pagination semantics, and the sibling tool to prefer for queries. Nothing critical is missing 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?

The schema provides parameter names and defaults but 0% description coverage. The description compensates by explaining include_entries behavior, limit range (1-100), offset paging, and pagination output fields. It could be slightly more explicit about the exact meaning of each parameter, but the core semantics are conveyed.

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: 'Read the bundled immutable strategy catalog snapshot.' It clearly describes what the tool returns (counts, hashes, provenance, or paged entries) and differentiates it from sibling search_strategy_catalog by naming that alternative 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 gives clear context on default usage versus paged entry retrieval and explicitly says 'Prefer search_strategy_catalog for queries.' It does not exhaustively enumerate exclusions, but the main alternative and the conditions for choosing it are clearly stated.

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 and non-destructive behavior, and the description adds valuable operational constraints: tail_bytes is capped at 25000 and absolute paths in log content are redacted. These details go beyond the annotations and help set agent expectations about limits and data privacy.

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 focused sentences with no filler. The core action is stated first, followed by actionable usage guidance and key constraints. 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?

The tool is a simple read operation with an output schema available, so the description does not need to explain return values. The annotations cover safety, and the description provides usage timing, parameter limits, and redaction behavior, making it complete for an agent to select and invoke correctly.

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

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

Schema description coverage is 0%, but the description compensates by explaining the meaning of tail_bytes through 'bounded tails' and the explicit cap of 25000. It also clarifies that job_id refers to the job whose private logs are being read. It does not detail formatting or defaults, but the core parameter semantics are communicated.

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 ('Read') with a clear resource ('bounded tails of a job's private log files'), making the tool's function immediately obvious. It is distinct from sibling tools like get_run_status or get_run_result, which deal with status and results rather than raw log content.

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 the tool: 'Use after a FAILED/TIMED_OUT/ORPHANED job to diagnose the cause before changing the strategy.' This is strong contextual guidance, though it does not name alternative tools or provide explicit when-not-to-use 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 and destructiveHint=false, and the description's 'Read' is consistent with that. It adds useful context about the return content and the success precondition, but it does not disclose behavior on failed jobs or any other edge cases.

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 with no filler. The action, object, and condition are all present and front-loaded, making it easy 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?

With annotations covering the safety profile, an output schema covering return shape, and one clearly named parameter, the description is mostly sufficient. The main gap is explicit guidance for failed jobs, but that is minor for a simple read-only retrieval tool.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It does not explain that job_id identifies the specific job whose run result should be read, leaving the only parameter to be inferred from its name and title.

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, 'Read', and names concrete outputs: 'normalized result and Markdown report'. Scoping it to 'a successful job' helps distinguish it from siblings like get_run_status and get_run_logs.

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?

'For a successful job' implies a precondition for using this tool, but it does not explicitly mention alternatives or when not to use it. An agent must infer that get_run_status or get_run_logs are better suited for checking status or diagnosing failures.

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, and the description builds on that by explaining the durable-state semantics, the derived polling fields, and the exact terminal-state vocabulary. This adds useful behavior beyond the annotation flags without contradicting them.

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 key action is front-loaded in the first line and the supporting facts (derived fields, terminal states, log sibling) are compactly grouped. Every sentence carries distinct information 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?

With an output schema present, the return-value details are not the description's job; it supplies the run-state vocabulary, polling fields, and a pointer to get_run_logs. It is complete for a simple single-parameter read operation, though it could have noted the source/format of job_id.

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?

There is one required parameter, job_id, and schema description coverage is 0%; the description never explains what job_id is, where it comes from, or its expected format beyond the schema's property name. The parameter is self-descriptive, but the description does not compensate for the lack of any schema-level 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?

Starts with a precise verb-resource pair: 'Read the durable state of a product-owned asynchronous run.' It also distinguishes itself from get_run_logs by noting that log_uri belongs to the log tool, and enumerates terminal states, so an agent can tell status from result/log tools.

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

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

The description provides clear usage context for polling a run: it is read-only, includes derived polling fields (elapsed_seconds, eta_bound), and points to get_run_logs as the sibling for log content. It does not explicitly list when-not-to-use conditions versus get_run_result, but the context is strong enough.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the 'private' scope and that the response includes 'exact file hashes,' but does not disclose more about permissions, errors, or availability.

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 meaning: 'Read,' 'private draft,' and 'exact file hashes' all add value.

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

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

With one required parameter, read-only annotations, and an output schema, the description gives enough context for basic invocation. It conveys the private scope and the hash-related return detail; mentioning potential access restrictions would improve completeness but is not essential.

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 explain draft_id beyond the schema's bare title. Although draft_id is a simple and arguably self-explanatory parameter, the low schema coverage means the description should compensate more than it does.

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 'Read' and the resource 'private draft,' and adds 'with exact file hashes' to specify the output detail. It does not explicitly distinguish itself from sibling tools like inspect_strategy, but the private-draft scope provides reasonable clarity.

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 about when to use this tool versus alternatives such as inspect_strategy, search_strategy_catalog, or get_catalog_snapshot. The only implied usage is reading a private draft, with no exclusions or 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 and destructiveHint=false, and the description adds meaningful context: the operation is confined to a local CSV and does not register it, plus it returns a bounded sample. This goes beyond the safety profile already encoded in 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 no filler: the core action and non-registration aspect are front-loaded, the return behavior is stated, and the intended workflow placement is given. 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?

Given simple parameters, strong annotations, and an output schema, the description covers the operation's purpose, safety, and workflow context. The main gap is parameter semantics: root_id and relative_path are not described, so an agent may not know how to construct valid arguments without further inference.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It mentions 'local CSV' generally but does not explain what root_id or relative_path mean, how they relate, or what formats are expected. The parameter names are somewhat self-explanatory, but the description does not compensate for the missing schema descriptions.

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

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

States a specific verb ('Inspect') and resource ('confined local CSV'), and explicitly differentiates from registration by saying 'without registering it'. It also names the return value (detected columns and bounded sample), so an agent can tell this apart from register_dataset and preview_dataset.

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

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

Explicitly says to use it before register_dataset to build an explicit column map, giving a clear workflow trigger. It does not enumerate when-not-to-use or name alternative tools beyond register_dataset, so it stops short of full 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 and destructiveHint=false, so the safety profile is covered. The description adds the key behavioral trait that no import occurs, which is valuable. However, it does not disclose what 'metadata' includes, whether expected_source_hash affects behavior, or what happens if the hash mismatches. With annotations covering safety, 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?

One sentence, front-loaded with the verb and resource, and the key non-import behavior is stated immediately. 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?

The tool has an output schema, so return values are presumably documented there. However, with 0% parameter coverage and a non-obvious optional parameter (expected_source_hash), the description leaves a meaningful gap: an agent cannot tell what the hash is for or when to provide it. For a read-only inspection tool this is adequate but not 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 the two parameters. It does not explain strategy_id beyond its name, and expected_source_hash is entirely unexplained—an agent cannot know its purpose or whether it is required for verification. The description adds no parameter-level meaning.

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 ('Inspect') and resource ('bundled or source-attached strategy metadata') and clarifies that it does not import the strategy. This distinguishes it from import-like operations, though it doesn't explicitly name a sibling alternative. The phrase 'without importing it' adds useful scope.

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

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

The description implies when to use this tool: when you need to inspect metadata without importing. However, it does not explicitly state when not to use it or name alternatives among the many siblings (e.g., get_strategy_draft, validate_strategy_spec). The context is clear 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?

Beyond the readOnlyHint annotation, the description discloses non-obvious behaviors: the 'active' pseudo-state expands to QUEUED/RUNNING/CANCEL_REQUESTED, unknown states cause enumeration of valid values, and pagination advances with offset while has_more is true. This gives an agent accurate expectations for edge cases.

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

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

The description is compact and front-loaded, with the core purpose in the first sentence and each subsequent sentence adding a specific, non-redundant usage detail. No filler or repetition exists.

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 is complete for a read-only list tool with an existing output schema: it covers filtering, state semantics, and the pagination loop. The only minor gap is explicit default-limit behavior, but the schema provides the default, so the information is accessible.

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, the description compensates well for state (pseudo-state semantics, unknown-state behavior) and offset (page-advance condition). Limit is not explicitly described, but its name and schema default convey its role; overall, parameter meaning is significantly enriched.

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

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

The description opens with a specific verb and resource ('List durable jobs') plus an explicit ordering ('newest-first'), immediately distinguishing it from sibling tools that operate on strategy runs, drafts, and datasets. No ambiguity remains about what this tool does.

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 operational context: how to filter by state, what the 'active' pseudo-state means, how to handle unknown states, and how to paginate using offset and has_more. It does not name alternative tools, but no sibling has an overlapping purpose, so explicit exclusions are unnecessary.

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, openWorldHint=false, and destructiveHint=false, covering the safety profile. The description adds only the fixed count of fourteen archetype/output-profile templates, but does not describe output behavior, ordering, or return structure. 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?

A single, front-loaded sentence with no wasted words. It communicates the verb, resource, and a meaningful constraint in under ten 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 zero-argument, read-only tool with an output schema, the description is nearly complete: it names the resource and fixed count. It lacks explicit usage-routing context, but nothing about invoking the tool is missing.

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

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

The tool has zero parameters and 100% schema coverage, so there are no parameter semantics to explain. The zero-parameter baseline of 4 applies, and the description appropriately does not attempt to document nonexistent 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?

States a specific action ('List') and a precise resource ('the fourteen archetype/output-profile scaffold templates'), adding detail beyond the title. This clearly distinguishes it from sibling tools like list_target_tree or get_catalog_snapshot.

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 explicit when-to-use or alternative routing, but the description implies that this tool is for retrieving scaffold templates for strategy archetypes/output profiles. The usage context is minimal and left mostly 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=true and destructiveHint=false, and the description adds that the read is 'confined' and returns relative-path to sha256 pairs, which are behavioral details not in the annotations. It does not disclose traversal edge cases (e.g., symlinks or hidden files), but the annotation safety profile lowers the burden.

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

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

Two short sentences carry all the content, with the core action front-loaded and the usage context in the second sentence. There is no filler or repetition of the schema field names.

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 an output schema present and read-only annotations, the description covers purpose and usage adequately. However, the complete absence of parameter semantics for both required arguments leaves an agent guessing about valid values for target_relative_dir, so the description is 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%, and the description never explains target_root_id or target_relative_dir beyond what their names already imply. There is no format guidance, relationship between the two parameters, or example, so the description fails to compensate for the schema 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 opens with a specific verb and resource: 'Read a confined target directory tree as relative-path to sha256.' It states both the scope and the output shape, and the reference to prepare_strategy_changes separates it from other read/list tools among the 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?

It explicitly says to use the tool before prepare_strategy_changes to construct expected_target_hashes preimages, giving a clear trigger condition. It does not spell out when not to use it or name alternatives, so it stops one step short of a full 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 provide idempotent and non-destructive hints, so the description adds valuable context about the no-write/no-approve boundary, the signed change token, and the printed local approval command. This clarifies the two-phase workflow 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?

The description is three tight sentences. The core behavior is front-loaded, followed by the most important output detail and the dependency on the approval command. 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?

The workflow and output are reasonably covered, and the output schema likely documents return details. However, the parameter contract is completely undocumented and there is no guidance about preparing the required hashes/validation token, leaving a meaningful gap for a six-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 0%, and the description does not explain any of the six required parameters. Terms like validation_token, expected_target_hashes, target_relative_dir, and idempotency_key are left to the agent to infer from names 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 states a specific action ('prepare an exact diff') and explicitly scopes what it does not do ('does not approve or write the target'). This clearly distinguishes it from apply_strategy_changes and other strategy tools.

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

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

The description implies when to use this tool by noting that apply_strategy_changes requires the approval created here. It provides a clear sequencing hint, though it does not explicitly say 'use this before apply_strategy_changes' or mention alternative tools.

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

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

Beyond annotations, the description discloses meaningful behavior: the output is a signed plan requiring local approval, the response includes the printed approval command, and a second approval is needed before execution. It also specifies the param_grid combination limit and that one approval covers the entire grid. No contradiction with annotations exists.

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

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

The description is compact and front-loaded. The core purpose appears in the first sentence, and the second sentence delivers targeted edge-case behavior. There is no filler or redundant restatement of the tool name.

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 approval workflow and parameter_sweep behavior are well covered, and the presence of an output schema reduces the need to describe return values. However, with eight parameters and zero parameter descriptions in the schema, the tool is not fully self-sufficient for an agent: critical fields like validation_token and runtime_id are left to inference.

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 explaining parameters. It only adds semantic value for run_profile_id and param_grid. Required parameters like draft_id, validation_token, and dataset_id, plus others like runtime_id and timeout_seconds, remain unexplained, leaving an agent to infer their meaning from names and types 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 states a specific verb and resource: 'Freeze exact run inputs and return a signed plan requiring local approval.' This clearly contrasts with sibling run execution tool start_strategy_run and communicates what makes this preparation step distinct.

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 establishes the tool as a prerequisite to start_strategy_run by stating that 'a separate execution approval is mandatory before start_strategy_run.' It also gives conditional usage guidance for the parameter_sweep profile. It does not explicitly name alternatives or when-not-to-use cases, 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 declare readOnlyHint=true and destructiveHint=false, and the description adds useful behavioral context: the dataset is immutable and the response includes a truncation_message that explains how to raise the limit or derive a filtered dataset. No contradiction exists.

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

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

The description is two tight sentences. The core purpose is front-loaded, and the second sentence adds exactly one valuable behavioral detail without any 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?

An output schema exists, so return values do not need to be spelled out. Combined with annotations, the description gives enough behavioral context for a read-only preview tool, though it misses sibling differentiation.

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 description coverage, so the description must carry meaning for the parameters. It partially explains limit by referencing a configured maximum and the truncation_message guidance, but dataset_id is left entirely to inference.

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

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

The description opens with 'Return a bounded preview of an immutable dataset,' which is a specific verb, resource, and scope. It clearly says what the tool does, though it does not explicitly distinguish itself from the sibling inspect_dataset.

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 preview_dataset instead of inspect_dataset, derive_tabular_dataset, or other siblings. The truncation_message note explains a follow-up behavior, not when or when not to select 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 provide readOnly=false, openWorld=true, idempotent=false, and destructive=false, and the description adds a meaningful safety boundary: 'Scans metadata and hashes only; corpus files are never imported or executed.' This clarifies exactly what the refresh operation does not do, which is valuable beyond the annotation set. No contradiction is present.

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, front-loaded with the primary behavior and conditional mode, followed by the key safety caveat. Every sentence carries useful information and there is no filler or repetition.

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

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

Given an output schema exists, return values need not be explained. The description covers the two modes and the no-execution safety property, but leaves expected_previous_snapshot_hash semantics unexplained and gives no usage guidance relative to sibling tools. For an agent calling this tool, the optimistic-concurrency parameter is a notable 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%, so the description must compensate. It does explain source_root_id and package_root_id semantically via the first sentence ('Refresh one AST root' vs 'rebuild both metadata corpora'), but expected_previous_snapshot_hash is left entirely to its parameter name, with no explanation of its concurrency or safety role.

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 ('Refresh one AST root, or rebuild both metadata corpora') and distinguishes two modes based on package_root_id. It is clear about the resource being operated on, though it does not explicitly differentiate it from siblings like get_catalog_snapshot or prepare_strategy_changes.

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. 'When package_root_id is set' describes an internal parameter condition, not a usage context or exclusion. The safety note about scanning metadata only implies a lightweight refresh, but no sibling tool is referenced.

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, but the description adds valuable context by explaining the mechanism: content is normalized and stored in an immutable content-addressed store, and identical content maps to the same dataset ID. This meaningfully clarifies retry and deduplication behavior beyond the annotation values. No contradiction with the annotations is present.

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

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

The description is three short sentences, each earning its place: the core action, the required column map, and the content-addressing behavior. It is front-loaded with the verb and resource, and contains no filler or redundant restatement of the tool name.

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

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

Given that the schema has zero parameter descriptions and there is a sibling tool for local registration, the description leaves important gaps. An agent still cannot determine what root_id and relative_path refer to or what 'confined CSV' means, which are necessary to invoke the tool correctly. The output schema exists, but that does not cover input parameter meaning.

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 meaning. It explains the column_map values by listing the canonical fields (datetime/open/high/low/close/volume/openinterest), but it says nothing about root_id or relative_path, which are required and non-obvious. The description compensates for only one of the three 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 opens with a specific verb and resource: 'Normalize a confined CSV into the immutable content-addressed store.' It also clarifies the purpose by noting that identical content maps to the same dataset ID. However, it does not explicitly differentiate this from the sibling register_local_dataset, so it stops 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 provides clear context and a prerequisite — it requires an explicit canonical column map with the listed fields. It does not, however, say when to prefer register_dataset over alternatives like register_local_dataset, nor does it state any exclusion conditions. Usage is implied rather than explicit.

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

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

Annotations already establish that this mutation is idempotent and non-destructive. The description adds useful behavioral detail: the set of accepted adapters, valid bar_operation modes, and the fact that invalid values are rejected with an enumeration of valid options.

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

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

The description is compact and front-loaded with the core purpose, followed by the key allowed values. The unexplained 'hash-bound' terminology costs some clarity, but no sentence is wasted.

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 an output schema and useful annotations, the open, nested data_spec parameter is underdocumented: an agent cannot confidently construct the DataSpec v1 or understand what 'one or more local feeds' requires. The description also fails to position the tool against the closely named register_dataset sibling.

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, the description is the only source of meaning for the data_spec object. It contributes adapter names and bar_operation values, but does not define the structure or semantics of a 'hash-bound DataSpec v1' or how multiple feeds are expressed, leaving a substantial 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 identifies a concrete action, registering local feeds, and the resource (a hash-bound DataSpec v1). The 'local' qualifier and the adapter list distinguish it from sibling register_dataset, though it does not explicitly contrast them.

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 tool's scope is implied by 'local feeds' and by listing the six accepted adapters, but there is no explicit when-to-use guidance, no exclusion criteria, and no mention of register_dataset as the alternative for non-local registration.

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, openWorldHint=false, and destructiveHint=false, so the description needs only to add context beyond those. It adds a success precondition and the output format behavior, but does not describe potential side effects, authentication needs, or response structure; the output schema likely covers return details.

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 conveys the core action and output options efficiently, even though the term 'canonical' could be clearer.

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 simple two-parameter read-only nature and the presence of an output schema, this is close to adequate for basic invocation. The main gaps are the undefined 'canonical result' terminology and the lack of explicit differentiation from sibling result/report tools, which is important given the 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%, so the description partially compensates by mapping 'Markdown or JSON' to output_format and connecting run_id to a successful canonical result. However, it does not clarify the exact run_id format or enumerate all valid output_format values beyond the two mentioned.

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 ('Render') and the resource ('a successful canonical result'), and it names the output formats (Markdown or JSON). It is not a tautology and is broadly distinguishable from siblings like get_run_result because it emphasizes formatting, though 'canonical result' is domain jargon that is not fully defined.

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 word 'successful' implies the tool should only be used when a successful canonical result already exists, giving an implicit usage condition. However, it does not explicitly name alternatives or state when to choose this renderer over related result/report tools such as get_run_result, compare_strategy_runs, or get_run_logs.

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?

Beyond the readOnlyHint annotation, the description reveals useful behavioral details: pagination metadata in responses, suggestions for empty results, and error behavior for unknown archetypes. This materially helps an agent anticipate edge cases.

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 main sentence front-loads the tool's purpose, and the two follow-up sentences describe response and error behavior. There is no filler or redundancy.

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

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

For a read-only search tool with an output schema and annotations, the description covers invocation mode, pagination, empty results, and invalid input handling. It provides enough context for an agent to select and call 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 0%, so the description must compensate. It explains that query is text search and archetype filters patterns, and offset is implied by pagination metadata. However, limit/offset semantics and valid archetype values are not explicitly defined, leaving partial 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 and resource: search deterministic built-in patterns by text and archetype. It clearly implies a filtered query over the catalog, which is distinct from snapshot/refresh siblings, 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 description gives clear context for when to use the tool: when searching built-in patterns by text or archetype. It does not explicitly exclude alternatives or mention get_catalog_snapshot for full listing, but the search trigger is stated directly.

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 behavioral detail beyond the annotations by disclosing that the tool consumes a local execution approval, launches an asynchronous durable job, and returns a job_id for polling. Nothing contradicts the annotations, which already mark the tool as idempotent and non-destructive.

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 carry the full purpose and the required follow-up workflow with no filler. The key action is front-loaded, and every clause adds operational value.

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

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

The description is incomplete for invocation because all four required parameters are undocumented in both the schema and the description, and prerequisite steps such as acquiring the run plan and approval are only implied. The output schema covers return values, but the parameter semantics remain a major 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?

The input schema has 0% description coverage for all four required parameters, and the description explains none of them. run_plan_id, run_token, approval_id, and idempotency_key receive no semantic meaning, so an agent cannot reliably determine what values to supply.

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

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

The description clearly states that this tool consumes an execution approval and launches a durable job, then returns a job_id. It differentiates itself from siblings like prepare_strategy_run, get_run_status, and cancel_strategy_run by naming the launch action and the resulting polling 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 provides explicit lifecycle guidance: poll get_run_status until a terminal state, then read get_run_result on SUCCEEDED or get_run_logs on failure. It does not explicitly state prerequisites or when not to use this tool, but the follow-up workflow gives clear operational 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?

The description goes beyond the annotations (readOnlyHint=false, destructiveHint=false) by disclosing that the operation uses optimistic concurrency and that stale values are rejected with a conflict error. This is valuable behavioral context not present in the annotations. It effectively communicates the concurrency mechanism and error behavior, though it does not detail side effects on the file or whether partial updates are allowed. Given the annotations already flag it as a write operation, the description adds meaningful transparency.

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

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

The description is extremely concise—two sentences—with the core action front-loaded. There is no fluff. It manages to convey the purpose and a critical behavioral detail (optimistic concurrency) in very few words. It could be slightly longer to cover parameters, but as a concise statement it is efficient and well-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?

With five required parameters, zero schema descriptions, and no output schema visible (though the signal says one exists), the description is insufficient for an agent to correctly invoke the tool. It lacks explanations of what a 'draft file' is, how to identify it via draft_id and relative_path, how to generate expected_revision and expected_file_hash, and what content format is expected. The description covers the concurrency aspect but leaves the rest to guesswork. This is a critical incompleteness for a tool with this many parameters.

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. It only implicitly references 'expected_revision' and 'expected_file_hash' through the phrase 'current revision and exact file hash', but it does not define them or any of the other three parameters (draft_id, relative_path, content). An agent would have no idea what format content should be in, what relative_path refers to, or how to obtain the expected values. This is a significant gap given no schema descriptions exist.

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 ('Update one editable draft file') and includes the key mechanism (optimistic concurrency). It is specific about the resource type (draft file) and distinguishes it from other draft-related tools like get_strategy_draft or validate_strategy_draft by focusing on the update action. However, it does not explicitly name any sibling tool or contrast with them, so it falls 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?

There is no guidance on when to use this tool versus the many sibling tools (e.g., create_strategy_draft, validate_strategy_draft, apply_strategy_changes). The description only explains what the tool does, not the conditions under which it should be chosen over alternatives. No exclusions or prerequisites are mentioned beyond the requirement of current revision/hash, which is more of a technical constraint than a usage 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?

It explicitly discloses that 'every call creates a new validation record and capability,' revealing side effects and non-idempotence beyond the annotations. The statement about parsing/compiling the AST without importing the candidate adds meaningful behavioral context. This is consistent with annotations, so no contradiction.

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

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

The description is compact, front-loaded, and contains no filler. The first sentence states the purpose and the second adds behavioral details, so both sentences earn their place.

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

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

With an output schema present, return values need not be described, and the side-effect behavior is covered. Still, the description omits any prerequisite context, such as where expected_revision comes from or how this differs from validating a spec, leaving a noticeable completeness 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 does not explain draft_id or expected_revision. draft_id is likely inferable, but expected_revision is not obvious; the 'hash-bound' phrase is only a weak hint. The description does not compensate for the schema 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 and resource: 'Statically validate a draft' and adds that it 'issue[s] an exact hash-bound capability,' which makes the core action clear. It does not explicitly differentiate from the similarly named sibling validate_strategy_spec, so it stops 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 provides useful context: validation is static and does not import the candidate, which implies it is safe to use for draft checks without executing code. However, it gives no explicit when-to-use or when-not-to-use guidance and does not mention alternatives such as validate_strategy_spec.

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 mark the tool as read-only and non-destructive. The description adds value by explicitly naming what is not created: 'no draft, token, or state record is created.' This gives concrete behavioral transparency beyond the annotation flags.

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

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

Two short sentences deliver the core purpose and the key side-effect guarantee. The information is front-loaded and every phrase earns its place with no filler.

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

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

Although an output schema exists and the tool is simple, the description leaves ambiguity about what a valid StrategySpec looks like and what 'against its immutable dataset' means operationally. The agent has enough to understand the high-level purpose but not enough to confidently invoke the tool with a correct payload.

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

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

The schema provides only a generic 'object' type with additionalProperties true and zero description coverage. The description mentions 'StrategySpec' by name but does not explain its required structure, fields, or how it relates to the immutable dataset. The description does not compensate for the schema's 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 uses specific verbs, 'validate' and 'canonicalize', against the 'StrategySpec' resource. It also distinguishes itself from draft-related siblings by explicitly noting that no draft is created, making the tool's role clear.

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 read-only note implies this tool is for validation without side effects, but there is no explicit statement about when to use this tool versus alternatives like validate_strategy_draft. The usage context is implied rather than spelled out.

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