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

No annotations are present, so the description carries the full burden of behavioral disclosure. The description states the action but does not reveal whether cancellation is irreversible, what happens to in-progress work, what status change results, or whether cancellation is synchronous. For a destructive mutation, this is a significant gap.

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

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

A single, front-loaded sentence with no filler. Every word earns its place, and the size is appropriate for a simple one-parameter tool.

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 minimally sufficient: it tells the agent what to pass (task_id) and what the effect is (cancel running task). However, it omits return behavior, error conditions, and side effects, and there is no output schema to compensate, leaving some ambiguity for a destructive operation.

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

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

Schema coverage is 100%, with task_id already described as 'Task ID to cancel.' The description adds no additional meaning beyond what the input schema already provides, so the baseline applies.

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

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

Uses a specific verb ('Cancels') with a clear resource ('coding-agent task') and adds the qualifier 'running' to limit scope. This distinguishes it from sibling tools like start_task, continue_task, and get_task.

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

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

The word 'running' implies it should be used for tasks that are currently active, but no explicit when-to-use or alternative guidance is provided. It does not mention behaviors for completed tasks or point to any sibling tool as a better fit in other cases.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the core action without explaining consequences such as whether the task must still be active, whether the follow-up triggers execution, or what happens if the session is already completed/canceled. The description adds little beyond what the tool name and schema already imply.

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, redundant phrasing, or irrelevant detail. It is front-loaded with the key verb and object, making it immediately scannable 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?

The tool is simple with two self-documented parameters, so a short description is acceptable. However, with no output schema or annotations, the description does not cover what the agent should expect after sending the instruction or whether there are task-state prerequisites. It is minimally viable but not fully complete for safe invocation in all scenarios.

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

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

Schema description coverage is 100%, so the schema already documents both task_id and instruction adequately. The description does not add extra meaning about formats, constraints, or relationships between the parameters, but it is consistent with the schema's meaning. This meets the baseline for fully documented schema parameters.

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

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

The description uses a specific verb ('sends') and a specific resource ('follow-up instructions to an existing task session'), clearly distinguishing it from siblings like start_task, cancel_task, and get_task. The word 'existing' and 'follow-up' make the tool's role obvious without needing to inspect 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 description implies that this tool is for continuing an already-created task session, which gives some usage context. However, it does not explicitly state when not to use it or mention alternatives such as start_task for new tasks or get_task/get_task_output for checking state. Usage guidance is inferred rather than explicit.

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

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

With no annotations, the description must carry behavioral disclosure. It does add useful context by stating the diff includes committed changes since the task base SHA and untracked files. However, it does not mention that the operation is read-only, how max_bytes truncation behaves, or what happens if both task_id and repository are supplied. These are meaningful behavioral gaps for a tool with no annotation safety hints.

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 primary action and resource, then adds the key scoping detail about committed changes and untracked files. There is no redundancy or irrelevant information.

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

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

The description covers the high-level purpose and diff scope well, and the schema documents all parameters. However, there is no output schema and no annotations, so the agent is left without explicit guidance on return format, truncation behavior, error cases, or interaction between task_id and repository. This is adequate but not fully complete for a tool with four optional 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 100%, so the baseline is 3. The description adds a little value by clarifying that the diff can come from a task workspace or a configured repository, which maps to task_id and repository. It does not elaborate on staged or max_bytes beyond what the schema already provides, which is acceptable given full schema coverage.

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

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

The description clearly states the tool returns a Git diff for either a task workspace or a configured repository, and it specifies the diff scope (committed changes since task base SHA and untracked files). This is specific enough to distinguish it from siblings like get_repo_status, which presumably returns status rather than diff 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 implies when to use this tool: when you need the actual Git diff for a workspace or repository. However, it does not explicitly contrast it with get_repo_status or other siblings, nor does it explain when one should prefer this over alternatives. The 'or configured repository' phrasing hints at mutually exclusive modes but does not explicitly state precedence or conflict behavior.

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

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

With no annotations, the description carries the behavioral burden. 'Returns structured Git status' implies a read-only operation and hints at the return shape, but it does not disclose edge-case behavior, failure modes, or what happens when both/neither parameter is supplied.

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 key information—what is returned and for what targets—is front-loaded and every word contributes 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?

The tool is simple (two optional params, no output schema), and the description covers the core purpose. However, it omits behavior when no parameter is provided or both are provided, and does not orient the agent relative to the sibling diff/list tools.

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

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

Schema description coverage is 100%, so parameters are already documented. The description adds little beyond the schema, only reaffirming that the status applies to either a task workspace or a repository root. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Returns'), resource ('structured Git status'), and scope ('task workspace or configured repository'), making the tool's function clear. It does not explicitly differentiate from siblings like get_diff, but the name and object are sufficiently 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 provides clear context about the two target modes (task workspace vs configured repository), which is implied by the parameters. However, it gives no explicit guidance on when to prefer this tool over siblings like get_diff, nor any exclusions or prerequisites.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read-only retrieval operation, but does not mention possible states, error behavior, permissions, or what 'concise metadata' includes.

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 clear sentence with no wasted words. It front-loads the action and result, making it easy for an agent to parse quickly.

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 tool with full schema coverage, the description is minimally viable. However, the absence of an output schema and any behavioral details leaves gaps about what state values exist and how the response is structured.

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

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

Schema description coverage is 100%, and the parameter description clearly states that task_id is the task identifier to query. The description adds no extra semantic detail, which is acceptable given the schema already covers the single parameter adequately.

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 ('Returns') and names the resource ('task state and concise metadata'), making the tool's basic purpose clear. It is distinguishable from the sibling get_task_output, which presumably returns full output, though this distinction is not stated 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?

No guidance is provided about when to use this tool versus alternatives like get_task_output, start_task, or cancel_task. The intended context is only implied by the tool name and description rather than 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?

Because no annotations are provided, the description carries the full burden of behavioral disclosure. It does add transparency by stating that output is bounded and paginated, which signals truncation and the need for cursor-based iteration. However, it omits edge-case behavior such as invalid cursors, empty output, task completion requirements, or whether the call is safe/read-only.

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

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

The entire description is a single front-loaded sentence with no redundant words. It states the return action, the resource, the output bound, and the pagination capability in order of importance, making it highly efficient.

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 three-parameter read tool, the description plus schema covers the basic call shape, but the absence of an output schema and any mention of the response format leaves a gap. In particular, the agent is not told how the cursor is obtained or used across pages, which is essential for effectively consuming a paginated 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 100%, so the baseline is 3; the schema already explains cursor as a byte offset and max_bytes as a byte limit. The description's 'pagination cursor support' adds contextual meaning but no additional syntax or format details, which is acceptable given the schema's completeness.

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 ('Returns'), a concrete resource ('task output'), and crucial qualifiers ('bounded', 'pagination cursor support') that immediately distinguish this tool from sibling get_task and the other agent-management tools. Even without opening the schema, an agent can understand what this tool does and how it differs from related 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 a clear use case—fetching potentially large task output in bounded chunks using a pagination cursor—but it never explicitly says when to choose this over get_task or other siblings. No alternatives or when-not-to-use conditions are mentioned, so the agent must infer the routing decision.

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?

No annotations are provided, so the description should disclose behavior. It indicates this is a read-only listing operation and mentions 'local availability', which is a useful behavioral trait. However, it does not explain what 'availability' means in practice (e.g., statuses, offline agents, error conditions), leaving some ambiguity.

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

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

The description is a single concise sentence that conveys the core purpose and an additional qualifier ('local availability') with no redundant wording.

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

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

For a parameterless list tool, the description is sufficient to understand what it returns. However, the lack of output schema and absence of details about the return structure or meaning of 'availability' means the agent may not know what data fields to expect. Still, this is a simple tool and the description covers the essentials.

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 carries no semantic burden. The description does not need to explain parameters, and the absence of parameter documentation is not a gap. Baseline 4 is appropriate for a parameterless 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 states a clear verb ('Returns') and resource ('configured coding agents') and adds the scope 'local availability', which differentiates it from sibling tools like list_repositories. It is specific enough to be understood, though it does not explicitly contrast with 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 its use case: retrieving available coding agents. It does not state when to prefer this over list_repositories or other sibling tools, but given the tool name and description, the intended context is reasonably inferable.

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

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

With no annotations, the description carries the burden of behavioral disclosure. The word 'Returns' indicates a read-only operation and 'safe metadata' suggests no side effects. However, it does not explain what 'safe metadata' includes, whether the result set is sorted, or what happens if no repositories are configured. Basic transparency is present but shallow.

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 short sentence with no filler. The key verb 'Returns' is front-loaded, and the object of the return is specified. Every word earns its place.

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

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

For a zero-parameter, no-output-schema listing tool, the description covers the essential purpose. It could be more explicit about the return format and the meaning of 'safe metadata', but the tool is simple enough that an agent can call it confidently without additional context.

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

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

The tool has zero parameters, so there is no parameter semantics burden for the description to carry. The baseline of 4 applies because no parameter documentation is needed; the description is sufficient for calling the tool with an empty object.

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 names the verb ('Returns') and the resource ('configured repository aliases and safe metadata'), which distinguishes it from sibling tools like list_agents and get_repo_status. The phrase 'safe metadata' is slightly vague, but the core purpose is unmistakable.

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 alternatives. It does not mention prerequisites, when it should be preferred over list_agents or get_repo_status, or any exclusions. The usage context is left entirely 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says the profile 'runs' but does not disclose whether execution is synchronous, whether it produces artifacts or side effects, whether a task must be active, or how results are returned.

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, readable sentence that front-loads the action and includes helpful examples. It is appropriately concise, though it omits behavioral details that would make it more complete.

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

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

With no output schema and no annotations, the description should explain how verification output is obtained and whether the run is asynchronous or blocking. It does neither, leaving an agent uncertain about what happens after the command is invoked.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds minor value with profile examples and the workspace/repository context, but it does not clarify the relationship between task_id and repository beyond what the schema already states.

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 ('Runs') on a specific resource ('configured verification profile') and gives concrete examples such as test and lint. It is clearly distinguishable from siblings like start_task or get_repo_status, 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 examples 'e.g. test, lint' and the mention of 'task workspace or repository' give useful context for when to invoke the tool. However, it does not explain when to prefer task_id versus repository, nor does it point to alternatives like get_task_output for retrieving results.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states that a task starts. It does not say whether the task runs asynchronously, whether a task ID is returned, what side effects occur in the workspace, or how the result can be obtained afterward.

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, front-loaded sentence with no filler. Since the input schema already documents all parameters and enums, keeping the description short is appropriate.

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 that starts an external coding-agent task and has no output schema or annotations, the description is incomplete. It omits critical context such as return behavior, async execution, how to reference the started task later, and the need for repository/agent aliases to be configured beforehand.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level meaning beyond what the schema already provides; it only loosely echoes the 'repository workspace' concept without clarifying alias configuration or relationships between parameters.

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

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

The description uses a specific verb ('Starts') and a concrete resource ('coding-agent task in a configured repository workspace'). This clearly distinguishes it from sibling tools like cancel_task, continue_task, get_task, and get_diff, since 'start' signals a new task rather than a status or follow-up operation.

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 on when to use this tool versus alternatives. The description does not mention prerequisites such as listing agents/repositories first, nor does it clarify that this tool is for new tasks while continue_task is for resuming existing ones. The agent is left to infer usage purely from the verb 'Starts'.

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