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

Beyond the destructiveHint annotation, the description explains the exact overwrite condition: existing destinations are not overwritten unless overwrite=true. This gives the agent concrete knowledge about when the destructive behavior occurs, though it does not describe error behavior or permissions.

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

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

The description is two short sentences with no filler. The core action is front-loaded, and the critical overwrite constraint is stated immediately after, making the definition easy to parse and act on.

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 of this complexity, the description plus schema and annotations are sufficient for correct invocation. The agent knows what the tool does, the scope, the required parameters, and the only non-obvious behavior (overwrite gating). No output schema is needed to make the call 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?

The schema already documents source and destination including workspace-relative paths and the parent directory requirement. The description compensates for the undocumented overwrite parameter by clarifying that it is required when the destination already exists, giving the agent the missing semantic context.

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, 'Copy a regular file', and scopes the operation to the configured workspace root. This clearly differentiates it from sibling tools like move_file, rename_file, and delete_file because copying preserves the original and is restricted to regular files.

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

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

The description states a clear use context: copying regular files inside the workspace. It also provides a key prerequisite/condition: existing destinations require overwrite=true. It stops short of a 5 because it does not explicitly name alternatives such as move_file or rename_file for related operations.

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

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

The description adds useful behavioral boundaries beyond the annotations: the directory is always created below the workspace root, and parent-directory creation only happens when recursive=true. This gives the agent a meaningful safety model for where the operation takes effect.

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

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

Two short sentences deliver the core purpose, the scope constraint, and the key option. Every word earns its place without repetition or padding.

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 creation tool with full schema coverage and no output schema, the description is sufficient. It tells the agent what is created, where it is created, and how to enable recursive creation; nothing essential 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?

Schema coverage is 100%, so the schema already documents both path and recursive. The description reinforces the recursive behavior in prose, but it adds no substantive meaning beyond the schema definitions, so the baseline of 3 is appropriate.

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

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

The description clearly states a specific action ('Create a directory') and a resource ('below the configured workspace root'), which distinguishes it from sibling file and git tools. Unlike names like 'process', it leaves no ambiguity about what the tool does.

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

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

The description gives clear context: this creates a directory, and 'recursive=true' handles missing parents. It does not explicitly name alternatives or exclusion conditions, but the sibling list makes the intended use apparent and no other sibling overlaps with this operation.

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 mark the tool as destructive, so the description adds value by spelling out the two key behavioral constraints: non-empty directories need recursive=true, and the root can never be deleted. It does not contradict the annotations and gives the agent the safety-relevant details it needs.

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

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

Two short sentences with no filler. The core delete action and scope come first, followed by the single most important usage condition, so an agent gets the critical information 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?

For a simple destructive directory tool, this description is complete: it states what is deleted, the path scope, the recursion requirement, and an absolute safety exclusion. With annotations covering the destructive nature and the schema fully documenting parameters, an agent has everything required to invoke 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 coverage is 100%, with both parameters already described. The description enhances this by attaching a condition to `recursive` (required for non-empty directories) and reinforcing that `path` is interpreted relative to the workspace root, which is behavior the schema alone doesn't fully convey.

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

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

The description opens with a specific action and resource ('Delete a directory'), defines the exact scope ('below the configured workspace root'), and clarifies the one condition that changes behavior (recursive on non-empty directories). This makes it clearly distinct from sibling delete_file and other workspace tools.

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

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

It provides actionable usage conditions: non-empty directories require recursive=true, and the workspace root is permanently excluded from deletion. It stops short of explicitly naming alternatives such as delete_file for files, but the resource type and conditions make the appropriate context 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=false and destructiveHint=true, so the destructive nature is known. The description adds the workspace-root boundary and regular-file restriction, which is useful, but it does not disclose whether deletion is permanent, what happens on non-existent paths, or how directory paths are handled.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes meaning: delete, regular file, configured workspace root.

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 destructive tool, the description plus annotations and schema provide enough to call it correctly: target type, scope boundary, and destructive intent. It lacks explicit failure-mode or irreversibility notes, but these are largely covered by the annotation and the tool's 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 100% and the single `path` parameter is already described as 'Workspace-relative file path'. The description reinforces 'below the configured workspace root' but adds little semantic detail beyond the schema.

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

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

The description states the specific verb 'Delete' and resource 'a regular file', with the bound 'below the configured workspace root'. It also distinguishes itself from delete_directory by specifying 'regular file' rather than directories.

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 intended use is implied by 'regular file', which suggests this tool is for files and not directories, but the description does not explicitly name alternatives like delete_directory or state when not to use it. The scope is clear, but routing between siblings is left to inference.

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

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

Annotations already indicate this is not read-only and not destructive. The description adds that only explicit files are staged and flags are disallowed, which is useful context but does not disclose behavior like index state changes, error handling, or interaction with untracked files.

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

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

Two tightly written sentences with no filler. The core action is front-loaded, and the important limitation on Git options is stated in a single follow-up sentence.

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 two-parameter tool with annotations covering safety and an output schema absent, the description plus input schema provides enough for correct invocation. Minor missing context like default staging behavior or success response is not critical for this 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 description coverage is 50%; the 'files' parameter lacks a description in the schema, but the tool description clarifies that paths must be repository-relative. The repo_path parameter is already described in the schema, so the description adds partial but not complete parameter-level meaning.

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

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

Description uses a specific verb ('Stage') and resource ('explicit list of repository-relative files'), clearly distinguishing this tool from siblings like git_status or git_commit. It also adds a scope constraint, making its purpose unambiguous.

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

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

The description states that only an explicit file list is accepted and that arbitrary Git options are not allowed, giving clear input-shape guidance. It does not explicitly name alternative tools or exclusion conditions, but no other sibling provides staging functionality, so the guidance is sufficient.

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

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

Annotations already mark this as destructive and non-read-only. The description adds meaningful behavioral detail: it rewrites local history, affects only the message, excludes staged and working-tree changes, and does not contact a remote. This is strong supplementary context beyond the annotations.

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

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

Two tightly written sentences front-load the core purpose and scope. Every clause adds useful information: what is rewritten, what is excluded, that history is rewritten locally, and that no remote is contacted.

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 tool with no output schema, the description covers the key facts needed to invoke it correctly: the scope, the exclusion of staged and working-tree changes, and the local-only behavior. It is nearly complete, though it could briefly note that the commit's hash will change as a result of rewriting history.

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 documents repo_path and its default, but the required message parameter has no schema description. The tool description clarifies that the message is the rewritten commit message, which adds some meaning, but it does not fully compensate for the schema's omission of message 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 names a specific verb and resource: rewriting only the most recent local commit message. It also explicitly excludes staged and working-tree changes, which sharply distinguishes it from related commit tools like git_commit.

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

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

The description clearly indicates when to use this tool: to change only the latest local commit message without including other changes. It also states the operation does not contact a remote, giving useful context, though it does not explicitly name alternative tools or when-not-to-use conditions.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the scoping behavior (local/remote/all) but does not disclose potential remote network access or output format. With annotations carrying the safety burden, this is adequate but minimal.

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 zero filler. 'List local, remote, or all Git branches' efficiently conveys purpose and parameter scope in just six words.

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

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

For a simple read-only tool with two optional parameters, one enum, and an existing safety annotation, the description plus schema is largely sufficient. The only notable omission is the lack of any output format hint, though a branch-list result is fairly intuitive. No explicit default behavior is stated, but the schema covers the 'local' default.

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

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

The description explicitly names the branch_type enum values ('local, remote, or all'), adding meaning to the undocumented branch_type parameter. The repo_path parameter is already described in the schema, so the description's main added value is clarifying the branch_type 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 ('List') and a clear resource ('Git branches'), and explicitly names the three scope options: local, remote, or all. This unambiguously distinguishes the tool from sibling git tools like git_status or git_log, none of which list branches.

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

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

The description clearly signals when to use this tool: any time branches need to be listed. Because no sibling tool performs branch listing, exclusion guidance is unnecessary. It does not explicitly describe when not to use it, but the unique resource makes the context 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?

The description adds meaningful behavioral context beyond the readOnlyHint=false and destructiveHint=false annotations: it is local, operates only on staged content, and has no remote interaction. It does not list failure conditions such as missing staged changes or Git user configuration, but the core behavioral boundaries are disclosed.

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

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

The description is two tight sentences with no filler. The main purpose is front-loaded, and the exclusions are stated immediately afterward, making the tool behavior easy 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 relatively simple commit tool, the description covers the essential preconditions and boundaries: staged changes, local-only, no remote interaction. It does not describe the return value or commit hash, but this is a minor gap for a straightforward 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 description coverage is 50%: repo_path is described in the schema, but message has only length constraints and no semantic description. The tool description does not explain the message parameter or add meaning beyond its name, so the agent must infer that it is the commit message.

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 ('Create'), the resource ('local Git commit'), and the precondition ('already staged changes'). It also distinguishes itself from staging and remote operations, so an agent can tell it apart from sibling tools like git_add without opening schemas.

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

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

It explicitly says the tool works on already staged changes and does not stage files or contact a remote, which provides clear usage context. It does not explicitly name git_add as the staging alternative, so the agent must infer that relationship, but the guidance is still strong.

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 safe read-only nature is established without the description. The description adds the workspace-root boundary, which is useful behavioral context, but it does not describe the output format or behavior when no changes are staged. With annotations covering the safety profile, a score of 3 is appropriate.

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

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

The description is a single, front-loaded sentence with no wasted words. It states the operation, the resource, and the scope constraint compactly, 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 read-only tool with one optional parameter, the description is complete: it specifies what is shown, where it applies, and how the path is interpreted. No output schema exists, but the standard nature of a staged Git diff means the return behavior is well understood. Annotations cover the safety profile, and no critical usage detail 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?

Schema description coverage is 100% and the sole parameter repo_path is already documented as 'Workspace-relative repository path; defaults to .' The description reinforces the workspace-relative concept but does not add meaning beyond what the schema already provides, so the baseline 3 applies.

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

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

The description uses a specific verb ('Show') and a specific resource ('staged Git changes') and clearly distinguishes this tool from its sibling git_diff_unstaged by the 'staged' qualifier. The phrase 'for a repository below the configured workspace root' also adds scoping clarity.

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

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

The description makes the tool's scope clear: it operates on staged changes rather than unstaged ones, which is the key selection signal among the sibling diff tools. It does not explicitly name alternatives or state when not to use it, but for a simple diff utility the context is sufficiently 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 description does not need to restate safety. It adds the workspace-root scoping constraint, which is useful, but it does not describe output format, whether untracked files are included, or behavior when no changes exist.

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 wasted words. The core action and object are front-loaded, and the scoping constraint is expressed efficiently.

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

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

For a simple read-only tool with one optional parameter and a complete schema, the description is nearly sufficient. It does not explicitly route to git_diff_staged or clarify untracked-file behavior, but annotations and schema cover the main safety and parameter needs.

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 schema already documents repo_path as workspace-relative with a default of '.'. The description adds a subtle but meaningful constraint: the repository must be below the configured workspace root, which enriches the parameter's intended value.

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 ('Show') and a specific resource ('unstaged Git changes'), which clearly identifies what the tool does. 'Unstaged' implicitly distinguishes it from the sibling git_diff_staged, but the sibling is not named explicitly.

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

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

The phrase 'for a repository below the configured workspace root' gives a clear scope constraint, but there is no explicit guidance about when to choose this tool over git_diff_staged or git_status. Usage context is implied by 'unstaged' rather than spelled out.

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

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 workspace-root scoping constraint, but does not disclose ordering, pagination, or output format, which would add further behavioral context.

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 primary action and object are front-loaded, and the workspace-root constraint is stated concisely. 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 simple read-only list tool with two optional parameters, the description, schema, and annotations together are largely sufficient. No output schema exists, so the description could have specified return fields, but 'show recent commits' implies the output type and the missing detail is not critical for correct invocation.

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

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

Schema description coverage is 50%: repo_path has a description, while max_count does not. The tool description adds no parameter-level meaning beyond the schema, though max_count's name plus default/min/max constraints make it reasonably self-explanatory.

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 ('Show') and resource ('recent Git commits'), clearly indicating the tool's function. It is distinguishable from sibling git tools by its focus on commit history, though it does not explicitly name or contrast any alternative.

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

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

The description implies usage when recent commit history is needed, but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives like git_show for individual commits or git_status for working-tree state, leaving selection to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, establishing this as a safe read. The description adds a genuinely useful behavioral guarantee: it will not invoke external diff helpers, which matters for an unattended agent that could otherwise hang on an interactive pager. It does not describe output format or size, but the safety profile is already covered.

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

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

A single sentence front-loads the core operation and immediately conveys the critical non-interactive behavior. There is zero filler or redundancy.

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

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

For a simple, read-only tool with a fully documented schema and existing safety annotations, this description is nearly sufficient. It could explicitly mention that output includes commit metadata/diff, but given the standard semantics of 'git show' and the rich schema, the gap is minor.

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%: both 'revision' and 'repo_path' are already well-described. The description adds no parameter-specific meaning beyond what the schema provides, so it meets the baseline but does not exceed 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 ('Show') and a precise resource ('one Git revision'), clearly distinguishing it from siblings like git_log (which lists multiple revisions) and git_diff_unstaged/staged (which show working-tree diffs). The modifier 'without invoking external diff helpers' further pins down its niche among the git tools.

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

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

The phrase 'one Git revision' implies this tool is for inspecting a single commit/tag/branch, but it does not explicitly state when to prefer this over git_log or git_diff_unstaged/staged. No alternatives are named and no exclusions are given, leaving some inference to the agent.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful context by specifying 'concise' and the workspace-root scoping, but it does not disclose return format or edge cases; given the annotations, this is adequate but not exceptional.

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

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

A single front-loaded sentence with no filler. Every phrase earns its place: 'Show', 'concise', 'Git working-tree status', and the workspace-root constraint all add essential meaning without waste.

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

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

For a low-complexity tool with one optional parameter, read-only annotations, and no output schema, the description is essentially complete. It tells the agent what it does, its scope, and its read-only nature; only minimal extra detail like output brevity or exit behavior could be added, but none is required for correct invocation.

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

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

The schema has 100% coverage and already describes repo_path as workspace-relative with a default of '.'. The description adds no additional parameter semantics beyond what the schema provides, so the 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 uses a specific verb ('Show') and resource ('concise Git working-tree status'), and clarifies that it applies only to repositories below the configured workspace root. It is distinguishable from sibling tools like git_diff or git_log, though it does not explicitly contrast itself with any 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?

There is no guidance about when to choose git_status over alternatives such as git_diff_unstaged or git_log. The description implies a general status check but provides no conditions, exclusions, or hints about when a different sibling would be more appropriate.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the workspace-root confinement, which is useful, but it does not disclose recursion behavior, hidden-file handling, or output structure. With annotations doing part of the work, 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?

The description is a single sentence with no filler or redundancy. It states the action and scope immediately, making it easy for an agent to parse.

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

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

For a simple one-parameter read-only tool, the description is close to sufficient. However, 'below the configured local workspace root' is ambiguous about whether it lists immediate children or recurses, and the absence of an output schema leaves return-format details unstated.

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%: the path parameter is fully described as a workspace-relative directory path defaulting to '.'. The description adds no additional parameter-level meaning, so the baseline of 3 applies.

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

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

The description uses a specific verb ('List') and a specific resource ('files and directories below the configured local workspace root'). This clearly distinguishes the tool from its siblings, which handle file content, mutations, and git operations.

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

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

The description gives no guidance on when to use this tool versus alternatives, no exclusions, and no context about typical workflows like exploring before reading or writing. The intended usage must be inferred from the tool name and sibling list.

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

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

The annotations already mark this tool as destructive (destructiveHint=true) and not read-only, so the description does not need to restate that. It adds useful behavioral context: the operation is limited to regular files and requires the destination to not already exist. The word 'move' reasonably implies the source disappears after success, although the description does not explicitly spell that out.

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 consists of two concise sentences with no filler. The primary action is stated first, and the critical destination constraint is given immediately after. 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 two-parameter tool with a clear schema and destructive annotations, the description is mostly complete: it names the operation, the scope, and the key precondition. It does not explicitly describe what happens to the source file after a successful move or how failures are reported, but these are relatively minor given the simple semantics and the existing schema/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 100%, so the baseline is 3. The description adds meaningful parameter-level meaning beyond the schema by specifying that 'The destination must not already exist,' which is an important overwrite/conflict constraint not present in the destination property description. This supplemental constraint justifies a score above baseline.

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 a specific verb and resource: 'Move a regular file to a new workspace-relative path.' It also adds scope by restricting to regular files and requiring a destination that does not already exist. However, it does not explicitly differentiate move_file from sibling tools like copy_file or rename_file, so it stops short of full sibling differentiation.

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 prefer move_file over alternatives such as copy_file, rename_file, or delete_file. The only usage-related information is the constraint 'The destination must not already exist,' which is a precondition rather than a selection criterion. An agent is left to infer how this tool fits among the file-operation siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavior beyond that: it only handles UTF-8 text files, restricts access to below the configured workspace root, and returns a SHA-256 hash rather than raw file content. This gives an agent important expectations for invoking the tool.

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

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

One sentence with no filler. The action, resource constraint, and return value are all present, and the most important information is front-loaded.

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

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

For a single-parameter, read-only tool with supportive annotations, this description is complete. It specifies the input scope, the file type limitation, and the return value (SHA-256 hash), so the agent knows what to expect and how to invoke the tool correctly.

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

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

Schema coverage is 100%, so the schema already documents the single 'path' parameter as a workspace-relative file path. The description adds the 'below the configured workspace root' boundary and UTF-8 requirement, but it doesn't significantly deepen parameter semantics beyond what the schema already provides.

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'), a specific resource ('a UTF-8 text file'), and a precise outcome ('return its SHA-256 hash'). It clearly differentiates this tool from siblings like list_directory and write_file, which serve different purposes.

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

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

The description clearly implies when to use it: when a file's content hash is needed, and only for UTF-8 text files within the workspace root. It does not explicitly name alternatives or state when not to use it, but the constraints are clear enough for selecting it over siblings.

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

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

With destructiveHint=true already in annotations, the description adds value by specifying the scope ('regular file'), the constraint 'The new name must not already exist,' and the same-directory limitation. These are behavioral details beyond the annotation flags, giving the agent a concrete precondition. It does not contradict the annotations, and the additional disclosure is meaningful without being exhaustive.

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

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

The description is two concise sentences with no redundant phrases. It front-loads the main action and constraint immediately, and every word contributes either to the operation, its scope, or its preconditions.

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 rename tool with annotations already covering the destructive profile and no output schema, the description is sufficient. It explains the operation, scope, and no-overwrite precondition, and the schema covers parameter details. Nothing essential is missing for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100%, with both 'path' and 'new_name' already fully described in the input schema. The tool description restates the constraint about not existing and clarifies 'without moving,' but it does not materially add to parameter meaning beyond what the schema provides. The baseline of 3 for high schema coverage 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 and resource: 'Rename a regular file without moving it to another directory.' This clearly distinguishes the tool from move_file by explicitly scoping it to same-directory renames, and the added constraint 'The new name must not already exist' further clarifies its exact operation. No ambiguity remains about what action is performed.

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 moving it to another directory' provides a clear boundary that signals when not to use this tool, implying cross-directory moves belong to a different tool. However, it does not explicitly name an alternative (e.g., move_file) or state 'use move_file when moving across directories,' so it falls between clear context and fully explicit routing.

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

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

Annotations already mark the tool as non-read-only and destructive, so the description goes beyond them by explaining the overwrite guard and optimistic concurrency protection via expected_sha256. It also clarifies the workspace-root confinement, which is useful safety context.

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 concise sentences with no filler. The core purpose is front-loaded, and the overwrite/concurrency caveats follow naturally without redundancy.

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

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

The description plus schema covers the essential behavior: writing a file, workspace-relative path, parent directory requirement, overwrite requirement, and optional SHA check. The absence of an output schema is acceptable for a write operation, and no critical guidance appears 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?

Schema description coverage is 75%, and the description compensates for the undocumented overwrite parameter by explaining when it is required. It also adds practical meaning to expected_sha256 by tying it to preventing lost updates.

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 (Write), a specific resource (UTF-8 text file), and a key scope constraint (below the configured workspace root). This clearly differentiates the tool from siblings like read_file, list_directory, and delete_file.

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

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

It gives concrete usage conditions: existing files require overwrite=true, and expected_sha256 should be used to prevent lost updates. It does not explicitly name alternatives, but the behavior is specific enough that an agent can decide when to use this tool.

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