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 declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, so the safety profile is covered. The description adds nothing beyond that: it doesn't say whether HEAD moves to the new branch, what happens if the branch already exists, or whether the working tree is touched — the exact behavioral facts an agent needs for a mutation 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?

A single front-loaded sentence with no filler. It is terse without being padded, though it is arguably under-specified rather than truly 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?

For a non-idempotent mutation with no output schema and two undocumented parameters, the description leaves out the essentials: whether the branch is checked out, behavior on existing branch names, and what the response reports. Only the base_branch semantics are covered, and those come 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 coverage is only 33%; base_branch is well documented in the schema, but repo_path and branch_name have no description in either place. The description doesn't compensate — it says nothing about what repo_path should point to or any constraints on branch_name.

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+resource (creates a branch) and adds the important detail that the base can be a branch or commit. It doesn't explicitly distinguish itself from siblings like git_branch (likely listing) or git_checkout, leaving that inference to the agent.

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_branch or git_checkout, nor whether the new branch becomes the active one. The agent must guess whether this behaves like 'git branch <name>' or 'git checkout -b'.

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 nothing beyond that about output format, size of diffs, or behavior on missing refs; with annotations carrying the safety burden, this is adequate but thin.

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 well-formed sentence with the core capability front-loaded and the revision-range syntax appended as a useful clarification. No filler, though the parenthetical could be tightened further.

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 read-only inspection tool with no output schema, the description covers the essential purpose and target syntax. It leaves gaps on repo_path expectations, the meaning/effect of context_lines, and how this differs from staged/unstaged diff siblings, so an agent still needs to inspect the schema and guess at selection.

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. It partially does: the 'main..feature' and 'main...feature' examples clarify the 'target' parameter's syntax and the two-dot/three-dot distinction, which the schema does not convey. However, 'repo_path' and 'context_lines' (including its default of 3) receive no explanation, leaving roughly a third of the parameters 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?

Uses a specific verb ('Shows differences') plus resource ('branches or commits', revision ranges) and gives concrete target syntax examples, so the agent knows exactly what the tool returns conceptually. It does not explicitly distinguish itself from the sibling git_diff_staged and git_diff_unstaged, which is the only thing separating 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?

There is no statement of when to use this tool versus git_diff_staged, git_diff_unstaged, git_show, or git_log, all of which overlap in the diff/inspection space. The agent must infer the selection rule from the description alone.

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 the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description adds real value beyond them: it discloses that a dirty working tree is refused, that conflicting merges abort, and that the repository is left unchanged on failure. It stops short of describing the success state in detail (index update, merge commit creation beyond the fast_forward_only note) and says nothing about the returned result.

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

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

One dense sentence with the core action front-loaded and the conditional/failure behavior following immediately; no filler, and each clause carries distinct information.

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

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

For a three-parameter mutation tool with no output schema, the description covers the critical behavioral risks (dirty tree refusal, conflict abort, unchanged repo). The remaining gap is minor: repo_path's expected value and what the tool returns on success are left implicit.

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 67%: source_branch and fast_forward_only are already documented in the schema, and repo_path is undocumented in both places. The description reinforces fast_forward_only's meaning (default fast-forward, false allows divergence) but adds no new syntax or format detail, so the schema is still doing most of the work.

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 verb and resource ("Merges a branch into the current branch") and names the target scope explicitly, so an agent can distinguish it from siblings like git_checkout or git_create_branch without opening the schema.

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

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

Usage is implied by the operation (merge a branch when you want its commits on the current branch), and the default fast-forward behavior is stated, but there is no explicit when-to-use/when-not guidance and no mention of alternatives such as rebasing or checking out before merging.

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 readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral detail beyond them: what the output contains (fetch and push URLs) and that credentials embedded in URLs are masked as <redacted>, which matters for how an agent interprets results.

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 tight sentences with no filler: the first states what is listed, the second discloses the redaction behavior. The core purpose is front-loaded and the caveat follows logically.

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

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

With no output schema, the description properly compensates by stating what is returned, and it flags the redaction behavior an agent would otherwise misinterpret. For a single-parameter read-only tool, nothing an agent needs to call and interpret it correctly 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?

There is one parameter at 100% schema coverage, so the schema already documents `repo_path` as 'The path to the Git repository.' The description adds nothing further about the parameter, which is acceptable given the schema does the work, but it means no extra meaning is contributed.

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 pairs the specific verb 'lists' with the precise resource 'the repository's remotes with their fetch and push URLs,' and anchors it to a well-known equivalent (`git remote -v`). That framing makes it unmistakably distinct from every sibling tool, which all concern diffs, commits, branches, merges and logs.

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 `git remote -v` analogy gives an agent a clear mental model of when this tool applies (inspecting configured remotes), and no alternatives among the siblings serve that purpose. It stops short of explicit when-not guidance, but there is little ambiguity to resolve for a single-purpose read tool.

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.