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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the description carries a lighter burden. It usefully identifies the staging-area target, which is the core behavioral effect and is not encoded in any structured field, but it omits what forms the 'files' argument accepts (paths, globs, directories) and doesn't clarify that nothing is committed.

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 eight-word sentence with no filler and the effect front-loaded. It is efficient, though the brevity edges toward under-specification rather than genuine conciseness.

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 mutating tool with zero parameter documentation, no output schema, and a dense ecosystem of sibling git operations, the description does too little. It never explains the staging concept, how it relates to git_commit or git_reset, or what the caller learns about success.

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, so the description must compensate, and it does not. 'File contents' gestures vaguely at 'files' but gives no path syntax or multi-file semantics, and 'repo_path' is entirely unaddressed.

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?

Names a specific verb ('Adds') and resource ('file contents') plus the destination ('staging area'), which is enough for an agent familiar with git to distinguish it from git_commit and git_reset. However, it never explicitly contrasts itself with any sibling, so the differentiation is inferred from domain knowledge rather than stated.

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 contains no when-to-use guidance: no mention that it precedes git_commit, no note that git_reset unstages, and no statement about selecting subsets of files. An agent must rely entirely on prior git knowledge to sequence this tool against its 11 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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context beyond the word 'List', such as return format, filtering behavior, or handling of remote branches.

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

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

The description is short and front-loaded with the core action. However, it is under-specified for a tool with required branch_type and optional commit filters, so it is not appropriately sized to support reliable invocation.

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 rich input schema and annotations reduce the description's burden, and no output schema is present. Still, the description omits the key distinction between local, remote, and all branches and the contains/not_contains filtering capability, leaving the agent to infer these entirely from the schema.

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 all four parameters are documented in the schema. The description adds no parameter meaning beyond what the schema already provides, making the baseline score of 3 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 clear verb and resource: 'List Git branches'. It distinguishes the tool from write-oriented siblings like git_create_branch and git_checkout by using 'List', but it does not explicitly differentiate among the several read-only siblings such as git_status and git_log.

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

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

There is no guidance on when to use this tool versus alternatives. The description gives no conditions, no exclusions, and no mention of related tools like git_create_branch or git_log.

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, destructiveHint=false, idempotentHint=false, and openWorldHint=false. The description adds no behavioral context beyond that, such as effect on uncommitted changes, working tree state, or whether the operation can fail on dirty state. It does not contradict annotations, but it adds little value.

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

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

'Switches branches' is extremely concise but under-specified for a tool with two required parameters and no schema descriptions. It is front-loaded but not appropriately sized for the complexity, so it reads as incomplete rather than efficiently 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?

The annotations provide a basic safety profile, and no output schema exists. However, the description leaves out any explanation of the required parameters, usage context, or behavioral side effects, making it too thin for a non-read-only Git 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 0%, and the description does not mention either required parameter (repo_path or branch_name). With two undocumented required parameters, the description must compensate but provides no semantic detail.

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+resource: 'Switches branches.' It identifies the core operation but does not distinguish it from sibling tools like git_create_branch or explain the repo_path/branch_name scope. This fits the rubric for a clear purpose without 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?

The description provides no when-to-use guidance, no conditions, and no mention of alternatives among the many sibling git tools. It only implies usage through the phrase 'switches branches,' which is not enough for explicit selection 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?

The annotations already declare that this is a mutating, non-idempotent, non-destructive, closed-world operation. The description adds no behavioral context beyond that, such as required git identity configuration, whether staged changes are required, or what happens if the working tree is clean.

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 single sentence is short, but it is under-specified rather than concise. Every word is vague and no useful 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 two-parameter mutation tool with no parameter descriptions, no output schema, and only generic annotations, the description is far too thin. It omits essential information about how to call the tool correctly and what the parameters mean.

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 mentions neither parameter. It does not explain that repo_path specifies the repository and message provides the commit message, leaving both required parameters completely undocumented.

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

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

The description 'Records changes to the repository' essentially restates what the tool name git_commit already implies, rather than specifying a verb and resource with distinguishing detail. It does not mention that it creates a commit from staged changes using the provided message, so an agent cannot easily differentiate it from sibling tools like git_add or git_reset.

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. It does not state that changes must be staged first, nor does it mention any prerequisites or relationship to sibling tools such as git_add or git_status.

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 disclose the key traits (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the description only needs to add context. It adds almost none: it never says whether the new branch is checked out afterwards, what happens when branch_name already exists (relevant given idempotentHint=false), or how the base branch defaults.

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 verb and resource front-loaded and no filler. It is efficient, though its brevity edges toward under-specification rather than true conciseness.

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 mutation tool with 3 undocumented parameters, no output schema, and only hint-level annotations, the description leaves too much unspecified: checkout behavior, default base resolution, and collision handling. An agent can guess the mechanics but is not fully equipped.

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. It conveys only that base_branch is optional; repo_path and branch_name remain completely undocumented, and the default-base behavior for the optional parameter is left 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 (creates) and resource (new branch) plus the notion of an optional base branch, so an agent immediately understands the operation. It does not, however, distinguish itself from siblings like git_branch or git_checkout, which is the only thing keeping it from a 5.

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

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

The description gives no when-to-use guidance, no prerequisite (e.g. a clean repo, existing base branch), and no pointer to alternatives such as git_checkout for switching branches or git_branch for listing them. Usage must be inferred entirely from the 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 safety is covered. The description adds nothing beyond that — no output format, no size/pagination caveats, no note that the working tree is untouched.

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

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

A single tight, front-loaded sentence with no filler. It is appropriately sized, though brevity here borders on under-specification rather than 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?

For a three-parameter tool with 0% schema coverage and no output schema, the description leaves key information missing: target syntax (branch vs commit range vs SHA), the meaning of context_lines, and the shape of the diff output.

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. The description only loosely gestures at the "target" parameter (branches or commits) and says nothing about repo_path or the context_lines default of 3, so it fails to compensate for the undocumented 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?

States a specific verb and resource ("Shows differences") and scopes it to branches or commits, which partly separates it from the unstaged/staged diff siblings. However, it never names those siblings, so the agent must infer the distinction.

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 "between branches or commits" hints at the comparison scope but gives no explicit when-to-use, when-not-to-use, or routing advice against git_diff_unstaged, git_diff_staged, git_show, or git_status.

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 a closed world, so the safety profile is fully covered without the description. The description adds no further behavior (output format, behavior with nothing staged, pagination), so it is adequate but contributes little.

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, front-loaded sentence with zero filler. It is appropriately sized, though it is so terse that it omits useful detail rather than trimming 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 simple read-only diff tool with full annotation coverage and no output schema, the essentials are inferable, but the description never mentions what the diff looks like, how paths are interpreted, or what happens when nothing is staged. Minimum viable rather than complete.

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

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

Schema description coverage is 0% for both parameters, so the description must compensate and does not: neither repo_path nor context_lines (default 3) is explained, and there is no hint about path format or what context lines do. Only the obvious reading of the names carries any 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?

States a specific verb ('Shows') and resource ('changes that are staged for commit'), which is precise enough to separate it from git_diff_unstaged by the staged/unstaged qualifier. It does not explicitly name the sibling, so it stops short of a 5.

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

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

There is no when-to-use statement, no prerequisite (e.g. must have staged changes), and no mention of alternatives like git_diff_unstaged or git_status. The 'staged for commit' phrasing faintly implies a pre-commit review context, but nothing is stated explicitly.

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, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds only the scoping qualifier ('working directory, not staged'); it says nothing about output format, whether context_lines truncates output, or behavior on a clean tree. With annotations carrying the load, a 3 is appropriate.

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

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

A single front-loaded sentence with no filler; the defining scope constraint appears immediately. It could have used a few more words productively (alternatives, parameters) but nothing is wasted.

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

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

For a read-only, non-destructive diff tool with complete annotations and no output schema, the purpose statement is sufficient to call it correctly. However, the entirely undocumented parameters (repo_path required, context_lines default) leave a real gap that a slightly longer description could have closed.

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% — neither repo_path nor context_lines has any documentation in the schema — and the description mentions no parameters at all. It does not explain that repo_path is the repository to inspect or what context_lines controls, so it fails to compensate for the coverage gap, though both parameters are conceptually self-explanatory to a git-literate agent.

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 ('Shows') plus a precise resource scope ('changes in the working directory that are not yet staged'), which implicitly separates it from git_diff_staged and git_diff. It is clear, but it never names the sibling it is contrasted with, so differentiation requires the agent to reason about the git workflow rather than being told.

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

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

The scope phrase 'not yet staged' implies when this tool is appropriate, but there is no explicit when-to-use guidance, no mention of git_diff_staged or git_diff as alternatives, and no prerequisite (e.g. valid repo_path). Usage is inferable but not 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that — no ordering, no default limit behavior, no filtering semantics — so it earns no credit for extra disclosure.

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?

It is a single short sentence with no filler, which is structurally clean, but the brevity reflects under-specification rather than disciplined concision. Nothing is front-loaded because there is nothing else to load.

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 4-parameter tool with a defaulted max_count, timestamp filtering, and no output schema, five words are far from sufficient. The agent lacks any sense of what the log entries contain, their ordering, or how the filters interact.

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 only 50%: start_timestamp and end_timestamp are well documented in the schema, but max_count (default 10) and repo_path have no descriptions anywhere. The description does nothing to compensate for those gaps, so it falls below the 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 gives a verb ('Shows') and a resource ('commit logs'), so the basic operation is inferable, but it essentially restates the tool name git_log and offers no differentiation from siblings like git_show or git_diff. An agent cannot tell from this text how it relates to those alternatives.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as git_show for inspecting a single commit. The agent must infer usage purely from the 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 destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description contributes one real behavioral fact - that the reset is unscoped ('all') and index-only - but says nothing about whether working-tree edits are preserved or how that differs from a hard reset.

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 five-word clause with zero filler and the scope caveat ('all') front-loaded. It is efficient, though so terse that it borders on under-specification rather than crispness.

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 one-parameter, no-output-schema tool this is roughly the minimum viable: the effect on the index is stated and annotations cover safety. Missing is any hint about repo_path's expected form and whether unstaging leaves working-tree changes intact.

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 repo_path, so nothing compensates for the undocumented parameter. The name 'repo_path' is fairly intuitive, which keeps this above a 1, but format or example guidance is absent from both sources.

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 ('unstages ... staged changes') and makes the 'all' scope explicit, so the agent knows it cannot be limited to one file. It does not name or contrast itself with siblings like git_add or git_diff_staged, so it stops short of a 5.

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

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

There is no statement of when to reach for this tool versus git_add, git_diff_staged, or a hard reset, and no exclusions or prerequisites. Usage must be inferred entirely from 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, idempotentHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the useful `<revision>:<path>` addressing form, a genuinely behavioral detail, but says nothing about output shape (diff vs. blob vs. metadata) or how large/binary content is 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?

A single, front-loaded sentence with no filler. The verb leads and the two scoping modes (whole commit vs. sub-path) follow 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?

With safety annotations present and no output schema, the remaining burden is explaining what comes back and how args combine. The description covers the two addressing modes but leaves 'repo_path' unexplained and gives no hint of the return format, so it is adequate but incomplete.

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 two parameters, so the description carries the burden. It clarifies the `<revision>:<path>` syntax for 'revision', which the bare schema string type does not, but 'repo_path' is left completely undocumented in both places.

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 ('Shows') and resource ('contents of a commit, or of a file or directory'), making it clear this is an inspection tool. It separates itself implicitly from git_diff/git_log by scoping to a named revision, though it never names a sibling 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?

There is no when-to-use guidance and no mention of alternatives like git_log or git_diff. An agent must infer from the resource scope alone that this is the tool for reading historical content rather than working-tree changes.

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 without the description. The description adds only a minimal restatement of scope ('working tree'), giving no insight into what the output contains or whether it reflects staged vs unstaged state.

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, front-loaded sentence with no filler. It is efficient, though its brevity contributes to the gaps in the other dimensions rather than being purely a virtue.

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

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

With strong annotations covering safety and no output schema to explain, the definition is nearly complete for a simple read tool. The remaining gap is the undocumented required repo_path parameter, which an agent must guess at.

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 repo_path is entirely undocumented in both schema and description. The description says nothing about how the repository location is specified, so an agent gets no help on the one required input.

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 ('Shows') and resource ('working tree status'), which an agent can map directly onto git status. It does not distinguish itself from siblings like git_diff_unstaged or git_diff, but each sibling is semantically distinct enough that confusion is unlikely.

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 git_diff or git_diff_staged, nor any note about prerequisites. The agent is left to infer usage entirely from the name.

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