git_status

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

There are no annotations (e.g., readOnlyHint or destructiveHint) to disclose behavior. The description is neutral and does not explicitly state that the operation is non-mutating or that it does not have side effects. While 'status' implies a read-only operation, the description alone does not fully disclose behavioral traits beyond what is obvious from the tool name.

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, concise sentence that directly states what the tool does without any redundant phrasing or unrelated details. It is well-structured and easy to parse.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description is sufficiently complete. It names the input (cwd) and the output characteristics (structured status including staged, unstaged, untracked files, and active branch). There is no missing context that would prevent an agent from using the tool correctly.

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

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

The only parameter, cwd, is clearly described as 'Target repository directory path' with a default behavior ('defaults to current working directory'). This fully explains its purpose and expected value, providing complete semantic meaning without ambiguity.

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

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

The description clearly states the action (Get) and the resource (status of current repository), and specifies the included details (staged, unstaged, untracked files and active branch). This makes the tool's purpose unambiguous and distinct from the sibling tools (e.g., git_smart_commit, git_review_diff), which have different actions.

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 does not provide any guidance on when to use this tool versus alternatives. For example, it does not mention that this tool should be used for read-only status checks or that other tools are for commits or diffs. This lack of explicit usage context leaves the agent to infer the appropriate conditions.

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