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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered structurally. The description adds the notable behavioral trait 'conflict-aware preflight', but does not say what happens on conflict (abort vs. partial apply) or what permissions are required.

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; the destructive multi-file scope and the preflight behavior are both conveyed immediately.

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 described, but for a destructive, multi-file mutation with two fully undocumented required parameters, the description is far too thin. It omits the root/changes contract and the conflict-resolution behavior an agent needs to call it safely.

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 0% for both required parameters, and the description never explains what 'root' means or what shape each entry in the 'changes' array (arbitrary objects) must have. 'Multiple project files' only faintly hints that 'changes' is a collection of file modifications.

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 specific verbs (create, update, delete) plus the resource (project files) and scope (multiple), which lets an agent distinguish it from read-only siblings like read_file and list_directory. It does not name a sibling alternative explicitly, but the purpose 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?

There is no guidance on when to use this versus shell, run_python, or validate, and no stated preconditions (e.g., clean working tree, repo root requirement). Usage is only implied by the verb 'apply'.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered structurally. The description adds that both working-tree/staged state and arbitrary revision pairs can be inspected, but says nothing about untracked files, patch format, or rename detection.

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 tight sentence with zero waste, front-loading the primary capability. It is arguably too terse for a 3-parameter tool, but it is structurally 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?

An output schema exists so return values need not be explained, and annotations cover the safety profile. However, with three undocumented parameters (0% coverage) and a required path with no stated meaning, an agent cannot reliably construct a correct call from this definition.

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

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

Schema description coverage is 0% and the description never mentions base, head, or path. 'Compare two revisions' loosely gestures at base/head but gives no format or semantics (refs? SHAs?), and the required path parameter is entirely 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?

States a specific verb (inspect/compare) and resource (working-tree/staged changes, revisions), making it distinguishable from siblings like git_log and git_show. It does not name any sibling explicitly, but the two operating modes are 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 two modes (working-tree/staged inspection vs. revision comparison) imply usage, but there is no guidance on when to pick this over git_show or git_log, nor any prerequisites. Usage is inferable 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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds a small amount of behavioral context ("recent" and "bounded"), but says nothing about ordering, how far back history goes, or whether it follows renames/merges.

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 short sentence with the scope constraint front-loaded and no filler. It is efficient, though the brevity tips into under-specification rather than pure economy.

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 described. However, with two parameters undocumented at 0% schema coverage, no usage guidance, and no differentiation from five sibling git tools, the definition is not complete enough for reliable selection and invocation.

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

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

Schema description coverage is 0%, so the description carries the full burden for the path and limit parameters, and it explains neither. "Bounded" hints at the limit parameter's effect, and "commit history" weakly implies path is a repository path, but the required path parameter's expected form (repo root? file? subdirectory?) is undefined.

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 gives a clear verb and resource ("Return ... commit history") with a scope qualifier ("bounded recent"), so an agent knows it is a history-listing read. It offers no differentiation from siblings like git_show, git_status, or git_diff, which an agent must infer on its own.

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 when-to-use guidance, no prerequisites, and no naming of alternatives such as git_show (single commit) or git_diff. The agent is left to guess which git-family sibling applies to a given request.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds 'bounded patch output', which is useful behavioral context, but 'bounded' is never quantified (no truncation limit or pagination behavior), leaving the added value incomplete.

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; the core operation and its output constraint are stated immediately.

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, and annotations cover the safety profile. However, with 0% schema coverage and an unquantified 'bounded' claim, the definition leaves an agent without enough detail to invoke the tool confidently.

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

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

Schema description coverage is 0% for both parameters. The description loosely implies the 'revision' argument but says nothing about 'path' (repository root? file path?) or what revision formats are accepted, so the two required parameters remain ambiguous.

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

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

States a specific verb (Show) and resource (one Git revision) with a scope qualifier (bounded patch output). It distinguishes itself from git_log/git_diff by implying a single-revision view, though it never explicitly names 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?

No when-to-use, when-not-to-use, or alternative guidance is given. The word 'one' hints at single-revision scope, but there is no signal about when to prefer git_show over git_diff, git_log, or read_file.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds the returned state categories (branch, dirty, staged, untracked), but with an output schema present this adds limited behavioral value beyond structured fields.

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

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

A single, front-loaded sentence that contains no filler. Every word earns its place by naming the verb, the output structure, and the key state components.

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?

Annotations fully cover safety and mutation behavior, and the output schema means return values need not be explained. However, the required path parameter is undocumented in both schema and description, leaving a meaningful gap 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 only parameter, path, has 0% schema description coverage and is not mentioned at all in the description. An agent must infer that path means a repository or working-tree path; the description does nothing to compensate for the absent schema 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?

States a specific verb (Return) and resource (structured Git state) and enumerates the state categories: branch, HEAD-related dirty, staged, and untracked. This distinguishes it from siblings like git_diff, git_log, and git_show, which deal with diffs, history, and object inspection respectively.

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 by naming the returned state categories, but it gives no explicit when-to-use guidance, no when-not-to-use exclusions, and no routing to alternatives such as git_diff or shell. For a status-inspection tool among several Git siblings, this is adequate but under-guided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the 'absolute path' requirement and hints that results are bounded, but says nothing about pagination, truncation behavior, or what happens when depth/limit are hit.

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. It is efficient, though the brevity shades into under-specification rather than tight editing.

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-value explanation is not required, and annotations cover the safety posture. Still, for a 3-parameter tool with 0% schema coverage and no usage guidance, an agent lacks enough to call depth/limit intelligently; 'absolute' and 'bounded' partially compensate.

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 compensate: depth (default 2) and limit (default 200) are never explained, nor is 'path' defined beyond the implicit absolute-path constraint. 'Bounded' gestures at the two numeric params but gives no semantics for them.

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 gives a specific verb and resource ('List ... directory') and adds meaningful qualifiers: absolute path requirement and 'bounded' enumeration. It does not, however, differentiate itself from sibling navigation tools like read_file or search_code, 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 statement of when to use this tool versus read_file or search_code, and no mention of prerequisites or exclusions. The agent is left to infer that listing a directory is the right choice for inspecting a folder's contents.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that this targets a LocalForge background child process, but says nothing about failure modes (e.g. what happens if the process has already exited).

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 tight sentence with the resource and scope front-loaded and 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?

Output schema exists so return values need not be described, and annotations cover the safety profile. However, for a tool whose only parameter is undocumented, the description leaves a real gap about how to identify the target process.

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 single required parameter process_id has no description anywhere. The description implies process_id identifies the process but gives no format, origin, or example of how to obtain a valid id.

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: reading the status of a background child process. It is naturally distinguishable from the sibling process_stop, though it doesn't explicitly name that alternative or clarify scope versus work_status.

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

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

No guidance on when to use this versus process_stop or where the process_id comes from. Usage is only implied by the tool name and the phrase 'background child process'.

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, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered structurally. The description adds scope value by noting it targets 'LocalForge background child process', implying it won't touch arbitrary PIDs, but it says nothing about whether the stop is graceful or forced, or what happens on an invalid/already-dead id.

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, front-loaded sentence with zero filler. It is efficient, though the brevity edges into under-specification given the surrounding gaps.

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 needn't be described, and annotations cover the mutation profile. Still missing is how to obtain a valid process_id and how this pairs with process_status, which an agent needs to invoke the tool correctly in sequence.

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 single parameter process_id carries no description in the schema. The description does not explain where process_id comes from (e.g., process_status or a launch call) or its expected format, so the only required argument is effectively 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?

States a specific verb (Stop) and resource (LocalForge background child process), which is unambiguous about the action. However, it never differentiates itself from the sibling process_status tool or clarifies the relationship between the two, so an agent must infer the division of labor.

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 stop a process versus checking it first with process_status, nor any prerequisite such as how a process is started or when stopping is appropriate. Usage is only weakly implied by the tool name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the content scope (structure + Git + docs + handoff) but says nothing about output size, cost, truncation, or how the bundle is assembled. Below the bar annotations set, but not empty.

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 beyond the mildly vague "high-signal." Nothing extraneous; the scope is stated immediately.

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, and annotations cover safety. However, for a composite read tool with an undocumented `depth` control and no routing guidance against overlapping siblings, the definition is only minimally sufficient.

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 both parameters, and it mentions neither. The required `path` and especially the `depth` parameter (default 2, presumably traversal/recursion depth) are left undefined, which is a real gap for a tool whose output scope depends on depth.

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 clear verb ("Return") and enumerates the resource bundle: project structure, Git state, docs, and work handoff. This reads as a composite/aggregator, which is somewhat distinguishable from single-purpose siblings like git_status or work_status, but the description never says it aggregates or how it differs. "High-signal" is an unquantified qualifier that doesn't sharpen 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?

No when-to-use or when-not-to-use guidance. The tool overlaps heavily with siblings (git_status, git_log, work_status, list_directory, read_file), yet the description gives no signal for preferring this bundle over those targeted calls. Usage must be inferred entirely.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The word 'allowed' hints at an allowlist/deny behavior but never states what happens on a disallowed path, and encoding/binary handling is unaddressed.

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 padding. It is efficient, though arguably under-specified rather than maximally concise.

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

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

An output schema exists, so return values need not be described, and annotations cover safety. Still, with three parameters at 0% schema coverage, the description leaves the line-range contract and the 'allowed' restriction undefined for an agent to call it 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% across three parameters, so the description carries the burden — but it only obliquely gestures at 'line range'. It never clarifies whether start_line/end_line are inclusive, whether both must be supplied, or what counts as an allowed path.

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 concrete verb ('Read') and resource ('text file') plus an optional line-range mode, which is enough for an agent to distinguish it from list_directory, search_code, and apply_patch. It stops short of naming siblings or comparing to search_code for content lookup.

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 when-to-use context and no exclusions: nothing tells the agent when to prefer read_file over search_code or shell, nor whether a line range is required versus optional. The only usage signal is the implied 'allowed' restriction.

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, openWorldHint=true, readOnlyHint=false and non-idempotency, so the safety profile is covered structurally. The description adds genuine value by introducing a restricted 'safe mode' versus an unrestricted 'dev' mode, but it never explains what safe mode actually restricts, whether dev mode runs unsandboxed, or what side effects persist.

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, and the scope (what runs) precedes the mode distinction. It is efficient rather than bloated, though its brevity comes at the cost of the missing detail noted elsewhere.

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 an arbitrary-code-execution tool with destructive and open-world annotations, five undocumented parameters, and only implied mode semantics, the description is well short of complete. The existence of an output schema removes any obligation to describe return values, but the input contract and mode behavior remain undefined.

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 five parameters, so the description must carry the load and largely does not. It only hints at the 'mode' parameter's two values and says nothing about 'root', 'code', 'purpose', or 'timeout_seconds', leaving four parameters with no documented meaning anywhere.

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 ('Run Python') and names two operating modes, so an agent knows this executes Python code rather than merely reading or analyzing it. It fails to differentiate from the closely related sibling 'shell', which is also an arbitrary-code-execution tool, 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?

The dev-vs-safe split implies a choice criterion ('automation' vs 'restricted analysis'), which is the main usage decision for this tool. However, it never states when to prefer run_python over sibling 'shell' or when validation via 'validate' should precede execution, and no prerequisites are given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the scoping constraint to an absolute directory, which is useful context, but says nothing about result limits, matching behavior, or symbol mode semantics.

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 efficient sentence with the scope constraint front-loaded. No waste, though it is arguably under-specified rather than optimally concise.

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

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

An output schema exists, so return values need not be described, but with 0% schema coverage and 5 parameters the description should explain mode values, file_glob, and max_results. For a search tool with multiple knobs, the definition leaves an agent guessing about half its inputs.

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, yet it only implies the 'path' (absolute directory) and 'query' parameters. It mentions text or symbols, loosely mapping to 'mode', but leaves file_glob and max_results entirely unexplained in both schema and description.

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

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

The description gives a specific verb ('Search') plus the resource ('text or symbols') and the scope ('below an absolute project directory'), so an agent can identify the operation immediately. It does not differentiate itself from siblings like git_diff or git_log, which search different resources, so a 4 rather than 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 statement of when to use this tool versus alternatives, no prerequisites, and no guidance on choosing between text and symbol modes. The phrase 'below an absolute project directory' hints at the required scope but stops short of usage guidance.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true, and non-idempotency, so the agent knows this is an unsafe, side-effecting operation. The description adds only the non-interactive requirement and cwd path constraint; it does not explain permissions, timeout behavior, or what background execution implies, leaving the safety profile to 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 efficient sentence with the key scoping constraint front-loaded after the verb. It wastes no words, though the terseness is part of the under-specification problem rather than good restraint.

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 needn't be described, but for a 9-parameter destructive execution tool the definition is far too thin: no parameter semantics, no usage routing, and no operational context. The definition leaves too much for the agent to infer.

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?

Nine parameters with 0% schema description coverage, yet the description mentions only cwd (and only to require an absolute path). Root, command, args, executable, shell, env, background, and timeout_seconds are completely undocumented in both schema and description.

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

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

States a specific verb and resource: 'Run a non-interactive local command'. The 'non-interactive' qualifier implicitly distinguishes it from run_python and interactive terminal use, but it never names a sibling or explicitly contrasts with the other execution 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 only guidance is the constraint that commands are non-interactive and that cwd must be absolute. There is no statement of when to use this over run_python, apply_patch, or git_* tools, and no exclusion of cases where shell is the wrong choice.

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 destructive, open-world, non-idempotent behavior, so the safety profile is known. The description adds that it performs a baseline-to-post-command scope check, but does not explain what scope means, what commands can affect, or permission requirements.

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 is concise, but it is too sparse for a 5-parameter destructive tool. It lacks front-loaded critical details such as what the validation checks, leaving the agent under-informed.

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 safety annotations, the description does not explain the validation logic, command execution semantics, or any parameters. For a complex, destructive tool with 0% schema description coverage, it is not complete enough.

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 0% for 5 parameters. The description mentions 'explicit commands' and implies a root/scope, but gives no meaning for denied_patterns, allowed_patterns, timeout_seconds, or root. It fails to compensate for the lack of 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 that it runs commands and performs a scope check, but 'validate' is broad and the description doesn't clarify what is being validated or how it differs from sibling tools like shell or run_python. The purpose is only partially 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?

No when-to-use guidance, no alternatives, and no conditions for selecting this over siblings. Usage is only implied by the description.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds the useful scope detail that it reads TASK/RESULT handoff files, but says nothing about freshness, locking, or whether it reflects in-progress writes.

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 compact sentence with no filler and the resource stated up front. It is arguably under-specified rather than wasteful, but structurally it is clean.

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 described, and the tool is a simple read-only single-parameter call. Still missing: the meaning of 'root' and any routing cue versus work_update/process_status, leaving the definition minimally viable.

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 single required parameter 'root' has 0% schema description coverage and is never mentioned in the description, so neither source explains what root denotes (workspace path, project root, task id?). With one undocumented parameter, 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 gives a specific verb ('Read') plus a concrete resource ('TASK/RESULT handoff files and status summary'), so an agent can tell what it returns. It does not, however, explicitly differentiate itself from the similarly-named sibling work_update or the status-oriented process_status.

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

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

There is no when-to-use or when-not-to-use guidance. The pairing with work_update (a write counterpart) and process_status (another status tool) is never mentioned, so the agent must infer which status reader to pick.

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 cover the safety profile (destructiveHint=true, idempotentHint=true, readOnlyHint=false), so the agent knows this overwrites state. The description adds only the 'local ignored' qualifier and does not say what gets destroyed, whether existing task/result/checkpoint content is replaced, or where the handoff file lives.

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. It earns its place, though the terse jargon-heavy phrasing limits how much the agent actually extracts.

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 described, and annotations carry the safety profile. The gaps are the undocumented root parameter and the absent usage context, which for a destructive 3-param mutation tool leaves the definition only marginally sufficient.

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

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

Schema description coverage is 0%, so the description must compensate, and it only partially does. 'task, result, or checkpoint' loosely implies the target parameter's allowed values, but 'root' and 'content' are left entirely unexplained in both schema and description.

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

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

States a specific verb (update) and resource (the local ignored handoff), and enumerates the content kinds (task, result, checkpoint) that map to the target parameter. It is distinguishable from the sibling work_status, though 'local ignored handoff' is domain jargon an agent may not fully parse.

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 call this versus the sibling work_status (read) or any other tool. No prerequisites, no conditions, no exclusions are given; the agent must infer that a write is appropriate from the verb alone.

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