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

Annotations declare readOnlyHint=true and destructiveHint=false, which is somewhat contradictory for a cancellation tool—cancelling a running task is typically a state-changing action. The description says 'Request cancellation' which implies it only requests, not guarantees, cancellation, aligning with readOnlyHint in a narrow sense. However, it doesn't disclose what happens to the delegation after cancellation, whether it's reversible, or any side effects. The description adds the 'queued or running' scope but not much else.

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

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

The description is a single, concise sentence that front-loads the action ('Request cancellation') and specifies the target ('queued or running in-memory delegation'). Every word earns its place, and there is no redundant information.

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

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

For a tool with one parameter and no output schema, the description is fairly complete. However, it doesn't explain what happens after cancellation (e.g., whether the task is removed from the queue, whether a result is returned, or how to check status afterward). Given the sibling tools include get_task_status and get_task_result, an agent might need to know what to expect after calling cancel_task. The description is adequate but leaves some behavioral 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 must compensate. The description mentions 'queued or running in-memory delegation' but does not explain the job_id parameter beyond what the schema provides (string, min/max length). The description adds no detail about what job_id refers to or how to obtain it, leaving the agent to infer from the name. Baseline 3 is appropriate because the schema is minimal and the description doesn't add meaningful parameter semantics.

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 ('Request cancellation') and a specific resource ('queued or running in-memory delegation'), which clearly identifies the tool's function. It distinguishes itself from siblings like delegate_task and get_task_status by focusing on cancellation, though it doesn't explicitly name those siblings.

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

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

The description implies when to use this tool: when a queued or running delegation needs to be cancelled. It does not explicitly state when not to use it or mention alternatives, but the context of 'queued or running' gives some guidance. It lacks explicit exclusions or alternative tool references.

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 a non-read, non-destructive mutation, so the description adds real value by revealing that the create is atomic and that the artifacts are validated before commit. This goes beyond what the structured annotations convey.

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

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

A single dense sentence that front-loads the core action and packs key constraints into a short phrase. There is no filler, repetition, or unnecessary explanation.

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

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

For a two-parameter tool with no output schema, the description conveys the essential workflow step and precondition, but it leaves parameter semantics mostly implicit and does not mention success or failure behavior. It is adequate but has clear gaps.

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

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

Schema description coverage is 0%, and the description does not explain job_id at all. 'Hash confirmation' loosely maps to expected_manifest_sha256, but the fields' exact roles and their relationship to the manifest are left implied, requiring the agent to infer 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 uses a specific verb ('create'), a concrete resource ('new artifact files'), and distinctive qualifiers ('atomically', 'validated', 'after preview and hash confirmation') that clearly separate it from sibling lifecycle tools like prepare_artifact, preview_artifact, and discard_artifact.

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 names the workflow precondition: use only after preview and hash confirmation. It does not list alternatives or state when not to use it, but the intended phase in the artifact lifecycle is clear enough for an agent to select it appropriately.

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=true, and destructiveHint=false. The description adds meaningful non-obvious context: the task is synchronous, bounded, and runs with an approved external model. It does not mention latency, cost, or return behavior, but those are secondary given the annotation coverage.

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 with no filler, and the most decision-relevant qualifiers — 'bounded,' 'synchronously,' and 'approved external model' — are front-loaded. Every word adds meaning and earns its place.

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

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

For a three-parameter tool with no output schema, the description is enough to convey a one-shot synchronous delegation, and annotations cover the safety profile. However, it leaves the agent to infer return behavior and does not explicitly differentiate this tool from asynchronous siblings like start_task and get_task_result.

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 parameter meaning. 'inline-text task' hints at the task parameter and 'approved external model' hints at profile, but max_output_tokens is not explained and no parameter is mapped concretely. The schema only provides structural constraints, not 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 ('Run') and resource ('one bounded inline-text task') with key qualifiers, especially 'synchronously' and 'approved external model.' It is clear about the tool's main function, but it does not explicitly distinguish it from siblings like start_task or get_task_result.

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?

'Synchronously' and 'inline-text' imply use for short, self-contained calls rather than asynchronous or file-based workflows. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named, so the intended usage is only implied.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, but the description says 'Discard' an artifact proposal, which is a mutating/destructive action on in-memory state. This is an annotation contradiction, even if committed files remain untouched.

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

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

The description is a single concise sentence that front-loads the verb and resource, then adds a useful scope caveat. Every word earns its place.

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

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

The tool is simple, but the annotation contradiction leaves side effects unclear, and the description provides no parameter guidance for job_id. With no output schema, a bit more detail about expected behavior and parameter role would be needed for full completeness.

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

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

Schema description coverage is 0% for job_id, and the description does not mention the parameter at all. The parameter name is somewhat self-explanatory, but the description fails to compensate for the missing schema documentation by explaining how job_id selects the proposal to discard.

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 'Discard' and identifies the exact resource: 'uncommitted in-memory artifact proposal.' The clarifying clause 'committed files are untouched' further distinguishes it from commit_artifact and other artifact lifecycle 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 this tool should be used to abandon an in-progress artifact proposal, and the 'committed files are untouched' note gives some context. However, it never explicitly names alternatives or states when not to use this tool relative to sibling tools like commit_artifact or preview_artifact.

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=true, and destructiveHint=false, covering the safety profile. The description adds that the tool returns a completed result and audit metadata, which is useful but does not disclose behavior for incomplete or failed jobs, error conditions, or whether it waits. This is acceptable but not rich.

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

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

One clean, front-loaded sentence with zero filler. It states the core action and result immediately, earning every word.

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?

While the tool is simple (one parameter, no output schema), the description leaves important gaps: it does not explain where job_id comes from, what the result structure looks like, or what happens if the job is not yet complete. An agent may be able to infer some context from siblings like start_task, but the description alone is not fully adequate.

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

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

Schema description coverage is 0% and the description does not mention job_id at all. The only parameter is left entirely to the schema, which provides just a string type and length constraints. The description fails to compensate for the low schema coverage, offering no guidance on what job_id refers to or how to obtain it.

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

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

The description uses a specific verb 'Return' with a clear object: 'completed result and model/provider audit metadata.' This clearly distinguishes it from siblings like get_task_status (status vs. result) and start_task, so an agent can tell them apart without opening the schema.

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

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

The phrase 'completed result' implies this tool should be used after a task has finished, but there is no explicit when-to-use guidance or mention of alternatives like get_task_status. Usage is inferred rather than stated, so it meets the 'implied usage' bar but not higher.

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=true, and destructiveHint=false, so the safety profile is covered. The description adds that the resource is an asynchronous delegation job and that only status is read, not results, but it does not disclose non-blocking behavior or possible response characteristics.

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

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

A single, front-loaded sentence with no filler. Every word adds meaning, and the action-object structure is immediately scannable.

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

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

For a simple one-parameter read-only tool, the description is adequate but leaves some gaps: there is no output schema, so the return value is not described, and the relationship to get_task_result is not clarified. An agent could still call it correctly, but with less confidence than if these details were present.

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 never mentions job_id or explains how to identify the job. The parameter name and constraints are self-explanatory, yet the description does not compensate for the lack of 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?

The description uses a specific verb ('Read') and resource ('status for an asynchronous delegation job'), making the core purpose immediately clear. It distinguishes itself from get_task_result by focusing on status rather than result, though it does not explicitly name that sibling.

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 'asynchronous delegation job' implies this is used to poll or monitor a previously delegated task. However, there is no explicit guidance about when to use this instead of get_task_result or cancel_task, leaving the choice somewhat inferred.

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 context that results are metadata-only and concern in-memory proposals. It does not mention pagination, ordering, or response shape, but the safety profile is covered by annotations.

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

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

One sentence, front-loaded with the verb and resource, with no redundant or filler wording. Every word contributes to the meaning.

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

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

For a zero-parameter, read-only list operation, the description is sufficient to select and invoke the tool correctly. The absence of an output schema leaves exact metadata fields unspecified, but 'metadata' plus 'without returning their contents' sets a reasonable expectation for the result.

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 are zero parameters and 100% schema description coverage, so the schema already fully documents the input contract. The description adds no parameter detail, but none is needed for a no-parameter tool.

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

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

The description uses a specific verb and resource: 'List metadata for in-memory artifact proposals' and explicitly excludes returning contents, which clearly separates it from content-returning siblings like preview_artifact. The scope is immediately understandable.

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 'without returning their contents' implies this tool is for metadata-only needs and that another tool should be used when contents are required, but no sibling or explicit when-to-use condition is named. Usage guidance is present only implicitly.

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 specific items returned, which is useful, but it does not disclose any further behavioral details such as response format, ordering, or potential caveats. The mention of 'configured-but-unverified' hints at a status nuance but is not elaborated.

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

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

A single sentence that is informative and front-loaded with the action 'List'. It efficiently enumerates the items without redundancy, though the compound phrase 'configured-but-unverified guardrail expectation' is a bit dense. Overall, it is concise 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?

Given the simplicity (no parameters, no output schema), the description covers the main content but leaves some ambiguity. The final listed item, 'configured-but-unverified guardrail expectation', is vague and could benefit from clarification. Without an output schema, it would be helpful to specify the shape of the response, which 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, so the baseline is 4. The description adds no parameter information because none is needed; the schema is empty and covered at 100%. The description correctly focuses on the output content instead.

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 'List' and the specific resources: approved model/provider profiles, privacy policy, server/plugin versions, and configured-but-unverified guardrail expectation. This is a precise enumeration that distinguishes it from sibling task- and artifact-oriented tools without ambiguity.

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

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

The description provides no guidance on when to use this tool versus alternatives. It merely states what it lists, with no mention of typical use cases, prerequisites, or explicit exclusions. For example, it doesn't mention that this is for checking configuration state or that task-specific status should use get_task_status instead.

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

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

Annotations already assert readOnlyHint=true and destructiveHint=false; the description reinforces this by saying it reads inputs and stages artifacts "in memory." It adds the qualifiers "explicitly approved" and "validated," but doesn't explain what validation entails, whether previous staged artifacts are replaced, or whether any in-memory state is visible to other tools.

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 11-word sentence with no filler or redundant clauses. It is compact and front-loads the read action, though the terse style sacrifices detail in a way that hurts overall 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 tool with 4 parameters, 0% schema coverage, and no output schema, this description is inadequate. It does not explain the role of the required task/profile parameters, the shape of outputs, how input_paths relates to "approved text inputs," or what the prepared artifact looks like when subsequently previewed or committed.

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?

Input schema description coverage is 0%, so the description must compensate for a 4-parameter tool. It offers only vague conceptual hints: "text inputs" could map to input_paths and "artifacts" to outputs, but task and profile are entirely unexplained, and no formats, defaults, or constraints are 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?

"Read explicitly approved text inputs and stage new validated artifacts in memory" clearly identifies the action (read + stage) and the resource (text inputs/artifacts). The phrase "in memory" helps distinguish from persistent siblings like commit_artifact, though it doesn't 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?

No guidance is provided about when to use this tool versus preview_artifact, commit_artifact, or start_task. The only implicit signal is "explicitly approved" and "in memory," which suggests a pre-commit preparation step, but there are no explicit conditions, prerequisites, or exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the 'without writing files' detail, which confirms non-destructive behavior and clarifies the scope, adding value beyond the annotations. It does not cover potential side effects like hashing costs, but for a read-only preview, that's minor.

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 zero waste, front-loading the core purpose and the non-writing constraint. It's concise and efficient, fitting for a simple tool with one parameter.

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

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

Given the tool has one parameter, no output schema, and annotations cover the safety profile, the description is nearly complete. It tells the agent what it does and what it doesn't do. The only missing piece is an explicit note that job_id refers to an in-memory artifact job, but that's inferable from the name. It's comprehensive for its simplicity.

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 needs to compensate. It mentions 'content hashes' but not what those are for, and 'job_id' is only defined by its type and length constraints, not its meaning. The description gives no semantic detail about job_id, so it doesn't add much beyond the schema's minimal info. Baseline 3 is appropriate because the description is present but doesn't enrich parameter understanding.

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

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

The description states a specific verb ('Preview') and resource ('in-memory artifact proposal') and clarifies what it does not do ('without writing files'), which distinguishes it from sibling tools like commit_artifact or prepare_artifact. It is clear enough, though it doesn't explicitly differentiate from list_artifact_jobs, but that is less related.

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

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

The description implies the tool is used for previewing before writing, but it doesn't explicitly state when to use it versus alternatives like prepare_artifact or commit_artifact. It gives a sense of the use case (preview before committing) but lacks explicit guidance on when not to use it.

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

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

Annotations already cover read-only and non-destructive behavior. The description adds meaningful behavioral context beyond annotations: synchronous execution, file count/size caps, UTF-8 requirement, and the fact that this call cannot be continued with send_followup.

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 dense sentences convey the action, scope, constraints, and a key follow-up limitation without redundancy. The most important information is front-loaded.

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

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

The description covers input constraints and the no-follow-up behavior, but does not state what the response contains or any error/output behavior. With no output schema and no parameter-level explanations, an agent lacks full information for a correct invocation.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It clarifies input_paths somewhat (explicitly named files, size limits) and task implicitly, but gives no explanation for profile or max_output_tokens.

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 ('review') and resource ('explicitly named UTF-8 text or source files under the locked workspace root'), with clear constraints on count and size. The word 'Synchronously' differentiates it from asynchronous siblings like start_file_review.

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: it is synchronous, limited to 1-100 files, and cannot be continued with send_followup. However, it does not explicitly state when to choose this tool over alternatives such as start_file_review or send_followup, so usage guidance is only 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 provide readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds 'bounded follow-up,' which is redundant with the message maxLength in the schema. It doesn't disclose any additional behavioral traits like side effects, return format, or error cases. No contradiction with annotations, but minimal added value.

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

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

The description is a single sentence with no filler. The core action is front-loaded, and it conveys the essential purpose without unnecessary elaboration.

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

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

For a tool with only two simple parameters and no output schema, the description covers the basic purpose but omits explicit usage guidance (when to call vs. siblings) and parameter semantics. It is minimally adequate but leaves the agent to infer critical context from names and annotations.

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

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

Schema description coverage is 0%, so the description must compensate for explaining the parameters. It does not explain job_id at all and only hints at message size via 'bounded,' which is already in the schema. The agent gets no additional meaning about what these parameters represent or how they should be used.

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

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

The description states a clear verb ('continue'), a resource ('a completed delegation'), and a qualifier ('bounded follow-up'). It distinguishes itself from siblings like delegate_task (initial delegation) and get_task_result (retrieval) by focusing on a follow-up action. No ambiguity or tautology.

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 clearly indicates this is for a completed delegation, implying it should be used after delegate_task has finished, not for initiating new tasks or retrieving results. It doesn't explicitly name alternatives or exclusions, but the context makes the timing and purpose 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, so the safety profile is covered. The description adds meaningful behavior beyond annotations: it restricts input to 1-100 explicitly named UTF-8 text/source files and retains an exact hashed snapshot in memory for later send_followup calls. This stateful follow-up behavior is valuable context not available from the schema or annotations.

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

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

One dense sentence that front-loads the action, states the key constraints, and discloses the follow-up snapshot behavior without filler. Every clause adds useful information and nothing is redundant with the schema.

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 adequate for a basic first call: it states the file constraints, follow-up capability, and safety. However, important operational context is missing: how to retrieve the initial review result, whether the call returns a task handle, how to choose a profile, and what counts as 'explicitly named' (e.g., no globs or directories). With no output schema to fill these gaps, completeness is only moderate.

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 0% description coverage, so the description must carry parameter meaning. It only clarifies input_paths semantics (explicitly named UTF-8 files, 1-100) and says nothing about how to write task, what profile affects, or how max_output_tokens behaves. The enum and bounds in the schema help marginally, but most parameters remain 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 states a specific verb and resource ('Start a follow-up-capable review') and adds precise input constraints (1-100 explicitly named UTF-8 text/source files). It hints at a paired lifecycle by mentioning send_followup and the hashed snapshot, but it never directly contrasts the sibling review_files, so the differentiation is implied rather than explicit.

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

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

The description implies this tool is for reviews that need follow-up ('follow-up-capable ... for send_followup'), so an agent can infer when to select it. However, it does not explicitly say when not to use it or name the one-shot alternative review_files, leaving the routing decision partially 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?

The annotation readOnlyHint=true directly contradicts the description's 'Start a task' which implies a state-changing operation (creating a job). The description does not clarify this mismatch or disclose any other behavioral traits such as asynchronous execution, side effects, or permissions beyond the immediate-return note.

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 core purpose and immediate behavior. It is concise, free of fluff, and structured to be easily parsed by an agent.

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

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

For a tool with three parameters and no output schema, the description omits critical details about parameter semantics and the nature of the task. It does mention the immediate return with a job ID, but the lack of parameter explanations and the annotation contradiction make the description incomplete for reliable 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?

With 0% schema description coverage, the description should explain the parameters (profile, task, max_output_tokens) but does not. It adds no meaning about what each parameter represents or how they relate to the task execution, leaving the agent without sufficient information to populate them correctly.

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 (start), the resource (bounded external-model task), and the immediate outcome (return with a job ID). It is specific and not tautological, giving an agent a precise understanding of what the tool accomplishes.

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

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

The description provides no guidance on when to use this tool versus its siblings (e.g., delegate_task, get_task_result). There are no conditions, exclusions, or alternative routing hints, leaving the agent to guess the appropriate selection context.

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