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

With no annotations, the description carries the full burden, yet it discloses almost nothing beyond 'local' and the vague qualifier 'allowed'. It never states that an allowlist governs which subcommands will succeed, nor that remote operations fail, nor how results are returned.

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

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

It is a single front-loaded sentence with no filler, which is structurally fine. But the brevity comes at the cost of substance — it is under-specified rather than efficiently concise for a 4-parameter CLI wrapper.

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 with 4 parameters, a nested env object, no annotations, and no output schema, the description is far too thin. It omits the allowlist behavior, sibling routing, and any notion of what the call returns, leaving the agent to infer nearly everything.

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

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

Schema description coverage is 100%, so the schema already documents cwd, env, args, and the command allowlist caveat; baseline 3 applies. The description adds no additional parameter meaning beyond what the schema states.

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

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

States a concrete verb and resource ('Run ... git subcommand') scoped to local execution, which is clear enough to understand the tool. However, it gives no differentiation from the 26 sibling wrappers (git_status, git_commit, etc.), so an agent cannot tell from the description alone when this generic entry point is the right choice.

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 generic tool versus the dedicated per-subcommand siblings, which is the single most important routing decision here. The only restriction hint ('allowed') lives in the word choice and is expanded only in the schema, not in the description.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing about staging semantics, reversibility, or permissions. It is a bare restatement of the git command synopsis.

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 wasted words. Its brevity is efficient, though it borders on under-specification for a tool with no annotations.

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 no annotations, no output schema, and 26 sibling git tools, a one-line synopsis is not enough to route the agent correctly or explain staging behavior.

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

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

Schema description coverage is 100%, so the schema already documents paths, all, and cwd. The description adds no meaning beyond the schema, making the baseline 3 the correct score.

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 (add) and resource (file contents to the index), matching the canonical git operation. It is clear, but offers no differentiation from sibling staging/mutation tools like git_rm, git_mv, or git_restore.

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_reset or git_rm. The agent must infer everything from prior git knowledge.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the tool shows revision and author information; it does not disclose that it is a read-only operation, that it operates on line ranges, that it requires a git repository, or what the output looks like, leaving significant behavioral gaps.

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 is appropriately sized for a simple tool, though its brevity contributes to the gaps noted in other dimensions.

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?

Given the low complexity and full parameter schema coverage, the description does enough to allow invocation. However, with no annotations and no output schema, it should at least clarify the line-attribution nature and read-only behavior; the gaps are noticeable but not crippling for a simple git command.

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 both path and cwd are fully documented in the input schema. The description adds no parameter-level detail beyond what the schema already provides (e.g., no mention of line ranges or revision arguments), 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?

States a specific verb ('Show') and resource ('revision and author information for a file'), so the basic purpose is clear. However, it does not distinguish itself from siblings like git_log or git_show, and omits the per-line attribution that is git blame's signature, so it is clear but not fully differentiated.

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

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

No guidance on when to use this tool versus alternatives is provided. There is no mention of when git_log, git_show, or git_grep would be more appropriate, so an agent must infer usage from the name 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?

With no annotations, the description carries the full behavioral burden. It discloses the scope ('local repository') and implies a non-mutating operation via 'List', but it never states read-only status explicitly, does not explain what 'inspect' returns or how it differs from plain listing, and gives no side-effect or permission 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 short sentence with the core action front-loaded and no filler. It is efficient, though the extreme brevity is part of why behavioral and usage gaps remain.

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?

This is a simple two-parameter, no-required-arg tool with no output schema, so the description does not need to explain return values. However, with no annotations to lean on, it leaves 'inspect' undefined and omits any safety or scope detail that an agent would want before invoking it.

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% ('all' maps to git branch --all, 'cwd' is a working directory path), so the schema already does the heavy lifting. The description adds nothing about either parameter, but the baseline of 3 applies when the schema is fully documented.

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

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

The description gives a specific verb(s) and resource: listing/inspecting branches in the local repository. It implicitly separates itself from mutating siblings like git_switch and git_checkout by framing the action as read-oriented, but it never names those siblings to make the distinction explicit.

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, even though git_switch and git_checkout sit right next to it in the sibling list. The read-only framing of 'List or inspect' hints at intended use, but nothing steers the agent away from the branch-changing tools.

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

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

No annotations are provided, so the description carries the full behavioral burden. It omits checkout's key traits: restoring files can silently discard uncommitted local changes, switching branches can fail on a dirty working tree, and neither the failure mode nor the return output is described. For a potentially destructive tool with zero annotation coverage, this is under-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?

A single short sentence with no filler and the core behavior front-loaded. It is efficient, though its extreme brevity borders on under-specification rather than tight structure.

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 dual-mode tool (branch switching vs. file restoration) that overlaps heavily with git_switch and git_restore, with no annotations and no output schema, the description does far too little. An agent cannot determine which mode applies or when to prefer this over the more specific siblings.

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 ref, cwd, and create are all documented in the schema itself. The description adds no syntax or format detail beyond what the schema already provides, making the baseline 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 names a specific verb and resource ("Switch branches or restore working tree files"), so an agent immediately knows the operation. However, it does not distinguish git_checkout from the closely-named siblings git_switch and git_restore, which cover the same two behaviors. Clear purpose, but sibling differentiation is absent.

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. Given that git_switch and git_restore exist as siblings and appear to map directly onto the two capabilities described here, the absence of any routing or selection guidance is a notable gap.

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

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

With no annotations, the description carries the full behavioral burden. It is a mutation tool that creates new commits and can produce merge conflicts, but none of this is disclosed, nor are working-tree state requirements or reversibility. Only the one-line operation is stated.

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; the operation is stated immediately and 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 mutation tool with no annotations and no output schema, the definition is too thin: it omits conflict behavior, ordering of multiple revisions, and the effect on the working tree/HEAD. An agent cannot confidently invoke it in edge cases from this text alone.

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 revs, noCommit, and cwd are already documented in the schema. The description adds no parameter-level meaning (e.g., commit ordering for multiple revs), so 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 states a specific verb ('Apply changes') and resource ('existing commits'), which maps cleanly onto the well-known git cherry-pick operation. However, it does not distinguish this from siblings such as git_revert or git_rebase, which also move commit changes around, so the agent must rely on the tool name for 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?

No guidance is given on when to use cherry-pick versus alternatives like git_rebase or git_merge, nor any prerequisites (e.g., clean working tree). The name implies the use case but the description adds no explicit when/when-not context.

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

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

No annotations are provided, so the description carries the full burden. It conveys that only untracked files are affected (implying tracked files are safe), but omits that deletion is irreversible and cannot be recovered, which is the single most important behavioral fact for a destructive 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 zero filler. It is efficient, though arguably undersized for an irreversible delete operation.

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

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

For a parameterless-required destructive tool with no annotations and no output schema, the description is minimal but functional. It falls short of warning about irreversibility, which is essential context an agent needs before invoking it.

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 cwd, dryRun, and directories are already documented in the schema, including the safety-relevant dryRun default of true. The description adds nothing beyond the schema, 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?

States a specific verb ('Remove') and resource ('untracked files from the working tree'), which is enough to distinguish it from tracked-file operations like git_rm or git_restore. It does not name a sibling explicitly, 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives or the fact that this permanently deletes data. The agent is left to infer all usage context.

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

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

No annotations exist, so the description must carry the full behavioral load. It mentions staging implicitly but doesn't disclose that the operation mutates repository state, requires a staged index, or is irrevocable without reset. Key traits like write behavior and side effects are left unstated.

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

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

A single, front-loaded sentence that states the action and its dependency without any filler. Appropriate for a simple three-parameter tool.

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

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

For a mutation tool with zero annotations, no output schema, and no usage guidelines, the description is incomplete. It should disclose write behavior, prerequisites for staging, and perhaps how it interacts with sibling tools like git_add.

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%; every parameter is fully documented in the input schema, including defaults and constraints. The description adds no parameter-level meaning beyond the schema, 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 states a specific verb ('Create') and resource ('commit') with scope ('from staged changes'). It doesn't distinguish from siblings like git_add or git_reset, but establishes a clear, distinct purpose among the git family.

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

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

No when-to-use or when-not-to-use guidance is provided. The phrase 'from staged changes' implies changes must be staged first, but it doesn't explicitly tell the agent to use git_add or specify prerequisites or alternatives.

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

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

With no annotations, the description fully carries the behavioral burden, yet it discloses almost nothing beyond the verb pair. It does not say that writes mutate repository state, that unset removes a key (potentially destructive), which scope (local/global/system) is affected, or that the tool returns the value on read.

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 wasted words. It is efficient, though arguably too terse for a tool that both reads and mutates configuration.

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 dual-mode read/write tool with no annotations and no output schema, an agent is left guessing about return values on read and side effects on write/unset. The description should indicate the response shape and the scope of modification but does neither.

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 already documented in the schema, which sets the baseline at 3. The description's 'read or write' phrasing reinforces the value-omitted-means-read behavior, but adds no syntax, format, or scope details 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 gives a specific verb pair (read or write) and a clear resource (repository git configuration), which is enough to distinguish it from siblings like git_status or git_branch. It lacks any explicit differentiation from other config-like tools, but 'git configuration' is self-evidently unique in this sibling set.

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, nor any prerequisites such as whether a repository must exist or whether the target is local vs global config. The read/write distinction is implied only by the schema's value parameter, not stated as a usage rule.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Read' implies read-only, but it never states what is diffed by default (unstaged working-tree changes), whether output is truncated for large diffs, or how the result is formatted. For a no-annotation tool this is a significant gap.

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

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

A single front-loaded sentence with no filler. It is efficient, though the brevity borders on under-specification rather than genuine tightness.

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, no annotations, and three all-optional parameters, the description should clarify the default diff target and return format. It leaves the agent to guess what a zero-argument call produces and how the diff is returned.

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 cwd, ref, and staged each documented in the schema, so the baseline of 3 applies. The description adds nothing beyond the schema, not even the default unstaged behavior implied by staged defaulting to false.

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 ('Read') and resource ('git diff') scoped to 'the local repository'. It is unambiguous about the operation, but offers no differentiation from adjacent siblings like git_show or git_status, which could also surface change content to an agent unfamiliar with Git.

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 exclusions, and no mention of alternatives such as git_show (a specific commit's diff) or git_status (working-tree summary). 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?

No annotations are provided, so the description carries the full behavioral burden. It adds only the 'tracked files' scope, omitting pattern semantics, case sensitivity, whether it searches working tree or index, output format, and error behavior.

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?

Three words are waste-free and front-loaded, but the fragment is so terse that it under-specifies the tool. It is concise without being adequately informative for a search operation.

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 annotations, no output schema, and many git siblings, the definition lacks key details for correct invocation. It does not clarify what is searched (file contents vs paths), how the pattern is interpreted, or what results look like.

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 each of the three parameters documented. The description adds no parameter meaning beyond that, 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?

Specific verb 'Search' and resource 'tracked files' are present, but 'search' is ambiguous between filename matching and content matching. The description does not distinguish git_grep from siblings like git_ls_files or git_diff.

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

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

No when-to-use guidance, no when-not-to-use guidance, and no alternatives are named. The agent must infer from the tool name that this is for pattern-based content search rather than listing or diffing.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the tool reads commits but omits important details such as default commit limit (maxCount=10), pagination behavior, whether it returns commit metadata or just messages, and any authentication or repository state requirements. For a read-only operation, this leaves significant gaps.

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, clear sentence that front-loads the core action and scope. No wasted words 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?

Given no annotations, no output schema, and three parameters, the description is minimally adequate. It covers the basic purpose but lacks behavioral context, usage guidance, and return value details, which are important for an agent 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 description coverage is 100%, so parameters like cwd, oneline, and maxCount are fully documented in the schema. The description adds little beyond the schema, merely implying recent commits without explaining parameter effects or defaults. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Read') and resource ('recent commits from the local repository'), clearly differentiating from siblings like git_show or git_blame. The scope 'local repository' is a useful qualifier, though it doesn't explicitly name how it differs from git show or git status.

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

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

The phrase 'recent commits' implies the tool's purpose but provides no explicit guidance on when to use it versus alternatives like git_show or git_blame. No when-not-to-use conditions or prerequisite information is included.

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

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

No annotations are provided, so the description carries full disclosure burden. It doesn't state whether it's read-only, whether it respects .gitignore, or what the output format is. 'Other index information' is left unexplained.

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

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

A single efficient sentence with no waste. Purpose is front-loaded and there is nothing superfluous.

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 tool with no annotations and no output schema, the description is too thin. It doesn't explain index concepts, output shape, or relationship to sibling commands like git_status.

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 all three parameters fully. The description adds no parameter-level meaning, so 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?

States a clear verb (list) and resource (tracked files / index information). Adequately distinguishes from siblings like git_status and git_grep, though it doesn't explicitly name them. The 'index information' phrase is a bit vague beyond tracked 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?

No guidance on when to use this versus git_status, git_diff, or git_grep. A capable agent may infer it, but the description provides no explicit context or exclusions.

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

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

No annotations provided, so the description carries the full behavioral burden. It says nothing about conflict handling, fast-forward behavior, whether it can modify the working tree, or failure modes. 'Merge' implies a write operation, but the agent gets no confirmation of effects beyond the simplest reading.

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

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

A single short sentence with zero waste, front-loaded with the verb and resource.

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 3-parameter mutation tool with no annotations and no output schema, the description is minimal. An agent could invoke it, but lacks conflict/rollback context and the effect of noCommit, which the schema only names.

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%: ref, cwd, and noCommit are all documented in the schema. The description adds no parameter meaning beyond restating the merge target, 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?

Clear verb (merge) and resource (commit or branch into current branch), so an agent knows exactly what it does. It doesn't distinguish itself from siblings like git_rebase or git_cherry_pick, which also integrate changes, but the core purpose is unambiguous.

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

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

No when-to-use, when-not-to-use, or alternative guidance. In a family of many git mutation tools (rebase, cherry-pick, revert), choosing merge correctly requires knowing the distinction, and the description provides none.

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

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

With no annotations, the description carries the full behavioral burden. It does not disclose that git mv updates/stages the move in the index, how it handles an existing destination, or that the source must be tracked — key facts for a mutating 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 zero filler. It is arguably too terse for a mutation tool, but 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 mutation tool with no annotations and no output schema, the description omits critical behavior such as index staging, overwrite semantics, and error conditions. An agent would need external git knowledge to call it safely.

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

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

Schema coverage is 100%, so the schema already documents source, destination, and cwd. The description adds only the set of movable resource types, which is marginal beyond what the schema 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 names a specific verb pair (move/rename) and the exact resource types it operates on (file, directory, symlink). It is clearly distinguishable from siblings like git_rm or git_add, though it does not explicitly contrast itself with them.

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 alternatives such as git_rm followed by git_add, nor any mention of conditions (e.g., destination already exists, untracked files). The usage is only implied by the verb.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose the critical trait that no actual git push occurs and the artifact is a diff uploaded to an HTTP API. It stops short of covering auth/config requirements, what the upload payload contains, or failure behavior, which are material for a network-mutating 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, front-loaded with the core divergence from the expected git behavior, with zero filler. Every clause 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 four-parameter, no-annotation tool the description conveys the essential divergence from git push, which is the highest-value fact. However, with no output schema and no annotations, it leaves the agent without any understanding of return behavior, API configuration prerequisites, or error outcomes.

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

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

Schema description coverage is 100%, so the schema already documents cwd, args, base, and message, including the important note that args are forwarded as metadata rather than executed. The description adds no parameter-level detail beyond what the schema provides, 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?

States a specific, non-obvious action: create a diff file and upload its path to a configured HTTP API rather than running git push. This clearly contradicts the expectation set by the name git_push, which is precisely the clarification an agent needs. It does not, however, distinguish itself from the sibling git_push_new_branch.

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 'instead of running git push' implies this is the push-equivalent in this environment, which is useful positional context. But there is no explicit statement of when to prefer this over git_push_new_branch or what prerequisites (e.g. configured API endpoint) must hold before calling it.

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

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

No annotations are provided, so the description carries the full behavioral burden. It notes the operation goes through a configured HTTP API and pushes a branch (a remote mutation), but says nothing about permissions, what happens if the branch already exists, whether the remote is modified destructively, or how createLocal/setUpstream side effects manifest. For a write tool with zero annotation coverage this is a substantial gap.

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

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

A single efficient sentence with the core action front-loaded; there is no padding. It is appropriately sized, though the 'Ask the configured HTTP API' framing is a minor distraction rather than added value.

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 no annotations and no output schema, the description is too thin. It omits prerequisites, side effects, and how the branch creation/publishing combination behaves, leaving the agent under-informed about an operation that alters remote state.

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 six parameters are already documented in the schema with their defaults and semantics. The description adds no syntax, format, or behavioral detail beyond what the schema states, so baseline 3 is correct.

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 (push) and resource (a new branch to a git remote), and the word 'new' meaningfully distinguishes it from the sibling git_push, which presumably pushes existing work on the current branch. The 'Ask the configured HTTP API' preamble is slightly noisy but does not obscure the action. Differentiation from siblings is implied rather than explicit.

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

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

No guidance on when to use this versus git_push or git_branch/git_switch. The description never names an alternative or a selection condition, leaving the agent to infer the 'new branch' case on its own.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: it does not mention that rebase rewrites commit history, that it can leave the repository in a conflicted intermediate state, or that the continue/abort/skip actions exist to recover from that state. 'Reapply commits' only faintly hints at history rewriting.

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 well-formed sentence with zero filler and the core operation front-loaded. It is efficient, though for a tool of this complexity the extreme brevity borders on 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?

This is a stateful, potentially history-rewriting operation with a control-action enum and no annotations or output schema to fill the gaps, yet the description is one generic sentence. An agent has no information about conflict states, safety, or recovery, so the definition is not complete enough 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 100%, so cwd, ref, and action are already documented in the schema, and the standard baseline for that situation is 3. The description adds no extra meaning about ref syntax, the meaning of the action enum values, or how they interact with an in-progress rebase.

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 sentence gives a specific verb (reapply) and object (commits) with the notable scope constraint 'on top of another base', which is the textbook definition of a rebase. It does not, however, distinguish this from closely related siblings such as git_merge, git_cherry_pick, or git_reset, which an agent could easily confuse it with.

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 indication of when to prefer rebase over merge or cherry-pick, no mention of the conflict-resolution workflow implied by the continue/abort/skip action parameter, and no note about when the tool should not be used. The agent is left to infer all routing decisions from the name 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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: it never states that "hard" mode permanently discards working-tree and staged changes, that the operation is irreversible for uncommitted work, or what the modes do. For a destructive git operation this is a significant gap, though the verb does at least signal mutation.

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 waste. It is efficient, but the brevity is arguably under-specification rather than true conciseness for a tool with dangerous modes.

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 annotations, no output schema, and no usage or mode explanations, the definition leaves an agent without enough to safely choose this tool over git_restore/git_revert or to pick a reset mode. Only the 100% schema coverage on the three parameters keeps it from being wholly inadequate.

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 cwd, mode, and target are already documented in the schema, making 3 the baseline. The description's phrase "HEAD or paths" loosely echoes the target parameter but adds no detail on the soft/mixed/hard/merge/keep modes, which is where the real semantic risk lies.

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?

It names a verb ("Reset") and a resource ("current HEAD or paths"), so an agent can identify the operation. However, it gives no differentiation from closely related siblings such as git_restore, git_revert, and git_checkout, which are exactly what an agent would confuse with reset. Its purpose is recognizable but not disambiguated.

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, even though git_restore/git_revert/git_checkout overlap heavily with this tool. The agent must 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.

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

No annotations are provided, so the description carries the full burden. It does not disclose that this is a destructive operation that overwrites uncommitted working tree changes, nor does it explain the distinction between staged (index) and working tree restoration.

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, efficient sentence with no filler. It is appropriately sized but perhaps too terse for a tool with meaningful behavioral nuances.

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 destructive git operation with no annotations and no output schema, the description is incomplete. It fails to warn about data loss, explain the staged vs unstaged behavior, or mention any recovery options, leaving the agent without critical context.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters including the staged flag. The description adds no additional parameter meaning beyond what the schema provides, making the baseline 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?

States a verb (restore) and resource (working tree files), which is better than a tautology. However, it does not differentiate from the many similar destructive/mutating siblings (git_reset, git_clean, git_checkout), and 'working tree files' is arguably misleading since the staged parameter enables restoring the index too.

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

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

No guidance on when to use this tool versus git_reset, git_checkout, or git_clean, which overlap heavily. The description gives no context for when restoration is appropriate or what alternatives exist.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only restates the operation. It does not disclose that revert produces new inverse commits rather than rewriting history, that conflicts are possible, or that an existing commit is required, all of which materially affect how an agent invokes it.

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 front-loaded sentence with zero waste, which is structurally sound. The terseness tips into under-specification for a history-mutating git command, so it is efficient but not adequately sized to its complexity.

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, conflict-prone git command with no annotations and no output schema, the description omits required preconditions, conflict behavior, and the side effect of creating new commits. An agent could select it correctly by name but would lack the context to invoke it safely.

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

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

Schema description coverage is 100%, and the schema itself documents revs, noCommit (apply without committing), and cwd, so the description correctly adds nothing new. Baseline 3 applies since the schema does the semantic 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?

"Revert existing commits" gives a specific verb and resource, so the basic operation is legible. However, it does nothing to separate this from closely related siblings like git_reset, git_restore, or git_cherry_pick, leaving the agent to infer the distinction from git knowledge alone.

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 mention of prerequisites (e.g. a clean working tree), and no routing to alternatives such as git_reset for history rewriting. With 25 sibling git tools, the absence of any disambiguation is a real gap.

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

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

No annotations are provided, so the description carries full behavioral burden. It states the removal scope but omits critical behaviors for a destructive tool: permanence/reversibility, whether it requires a clean working tree, whether the removal can be recovered, and how the 'cached' flag alters behavior. This is a significant gap for a git rm operation.

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 is appropriately sized for a simple statement of purpose, though it is arguably too terse for a destructive tool, which borders on under-specification rather than verbosity.

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 no annotations and no output schema, the description should disclose safety and operational context (destructiveness, recovery, prerequisites). It provides only the basic action, leaving an agent without enough information to use git_rm safely or correctly in ambiguous situations.

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 clear descriptions for cwd, paths, and cached. The description adds no parameter meaning beyond the schema, which is the expected baseline when the schema already documents all parameters.

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

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

The description gives a specific verb ('Remove') and resource ('files from the working tree and index'), making the core action clear. However, it does not differentiate from sibling tools like git_clean, git_restore, or git_reset, nor does it specify that it targets tracked files, so an agent cannot easily distinguish it from 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 guidance on when to use this tool versus alternatives such as git_clean or git_restore, nor any prerequisite information (e.g., clean working tree). The description is purely declarative and leaves selection entirely to inference.

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

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

No annotations are provided, so the description must carry full behavioral disclosure. It says nothing about what 'show' does beyond a generic verb – no mention of output format, whether it prints to stdout, what happens with invalid revisions, or if it modifies state. For a tool with zero annotation coverage, this is a significant gap.

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

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

The description is a single short sentence, which is concise. However, it is so terse that it lacks front-loaded specifics – it does not specify which object types or the format of output, making the brevity a liability rather than an asset.

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 annotations, no output schema, and a tool complex enough to have 26 siblings in a VCS context, the description is inadequate. It omits critical context like the types of objects that can be shown, typical use cases, and how it differs from similar tools such as git_diff or git_log.

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 both parameters ('cwd' and 'rev') are documented in the schema with defaults and descriptions. The description adds no meaning beyond what the schema already provides, so 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 'Show an object from the local repository' restates the tool name (git_show) without specifying what an 'object' is (commit, blob, tag, tree) or what 'show' returns. It does not distinguish this tool from siblings like git_diff or git_log, which also display repository content. An agent cannot tell from this description what it will actually get back.

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. With 26 sibling tools including git_diff, git_log, and git_cat-file-like operations, the description provides no context on selection criteria or prerequisites.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says only 'Manage git stashes' and does not mention that actions such as drop, clear, or pop mutate state, that push creates a stash, or any side effects, permissions, or reversibility.

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 concise and front-loaded but too sparse for a tool with seven enumerated actions and optional parameters. It reads as under-specification rather than efficient brevity.

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 multi-action stash tool with no annotations and no output schema, the description should explain action semantics and at least note the default 'list' behavior. Instead it leaves the agent to discover all behavior from the schema enum alone.

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

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

Schema description coverage is 100%, so the schema itself documents cwd, ref, action, and message. The description adds no parameter meaning beyond the schema, making the baseline 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 names the resource (git stashes) and a generic verb (manage), but it does not state the specific operations (list, push, pop, apply, drop, show, clear) or distinguish this tool from siblings like git or git_status. It is marginally more than a restatement of the tool name, so it lands at the vague-purpose level.

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 use stashes versus commits or branches, nor when to choose this tool over siblings. The description offers only an implied domain, with no conditions, exclusions, or alternatives.

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

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

With no annotations, the description carries the full burden. 'Run git status' implicitly signals a non-mutating, read-only inspection and 'local repository' scopes it, which is reasonable context, but it never explicitly states that no write occurs or how the output is formatted.

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 padding, which is efficient. It borders on under-specification for the tool's role, but there is no wasted text.

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 command with no annotations and no output schema, the description is minimally adequate but omits expected behavior details such as the read-only nature and what the status report includes, leaving the agent relying on prior knowledge of git.

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 both parameters (cwd, short) are already documented in the schema. The description adds no additional parameter 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?

States a specific verb (Run git status) and scope (on the local repository), which is enough to distinguish it from remote-inspecting or history-reading siblings like git_log or git_diff. It is clear, though it largely restates the tool name without explaining what status output contains.

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

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

No guidance on when to use this versus alternatives such as git_diff or git_log, and no mention of prerequisites (e.g., being inside a git repo). The agent must infer usage 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?

No annotations are provided, so the description carries the full disclosure burden and does not meet it. It never mentions that this mutates the working tree/index, that it can fail with uncommitted changes, or what the response contains — all critical for a state-changing git operation.

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 words is maximally front-loaded and wastes nothing, but here the brevity is under-specification rather than effective concision for a state-mutating git tool with three parameters.

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 annotations, no output schema, and no usage guidance, the description is too thin for a mutation tool in a 27-tool git family full of near-overlapping siblings. An agent cannot safely decide to call this instead of git_checkout on the text alone.

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% (cwd, branch, create are each documented in-schema), so the baseline is 3. The description adds no extra meaning, such as what create=true does to the branch pointer or whether the name must already exist.

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

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

States a concrete verb and resource ("Switch branches"), so an agent immediately knows this changes the checked-out branch. It does not differentiate from git_checkout, which also switches branches, nor from git_branch, so it lands at clear-but-undifferentiated rather than 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?

No when-to-use guidance, no prerequisites, and no mention of the heavily overlapping sibling git_checkout (or git_restore for files). The description gives the agent no basis for choosing this tool over an alternative.

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

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

With no annotations, the description carries the full behavioral burden and does not disclose that create and delete are mutating, whether deletion is local-only or reaches a remote, permission requirements, or reversibility. The only hint at behavior is the word 'delete', which the parameter description already conveys.

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 wasted words, which is well suited to a short tool. It is arguably under-specified rather than over-verbose, but the sizing itself is efficient.

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

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

For a three-mode tool with mutations, no annotations, and no output schema, the description leaves too much unstated: which parameters are required per mode, whether list returns anything structured, and what deletion affects. It is not complete enough for an agent to invoke the tool confidently.

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

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

Schema description coverage is 100%, so all four parameters are already documented, making 3 the appropriate baseline. The description adds no format details, no explanation of how 'delete', 'name', and 'message' combine across the three modes, so it does not exceed what the schema 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 states concrete verbs (list, create, delete) applied to a specific resource (tags), and no sibling tool covers tags, so it is unambiguous. It stops short of differentiating modes or linking to related workflow tools like git_push, which keeps 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 guidance on when to use each mode or how the parameters interact with them (e.g., which parameters apply when deleting versus creating). An agent must infer that 'delete=true' selects the deletion path and that 'message' selects an annotated tag, with no explicit statement.

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