Show Git status

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds 'fixed' (implying no custom arguments) and 'authorized' (implying a prerequisite), which are useful contextual details beyond the annotation. However, it does not disclose what the status output contains (e.g., modified, staged, untracked files) or whether it includes branch information, so it adds only modest behavioral context.

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

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

The description is a single, front-loaded sentence with no wasted words. It is compact and readable. However, it could add a brief clause about what status returns without losing conciseness, so it is not a perfect 5.

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 read-only tool, the description is thin. It does not explain the projectId parameter, does not mention the need to have a project authorized (despite implying 'authorized'), and provides no information about the return value or output format. There is no output schema, so the description carries the full burden, which is left unmet.

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

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

The schema has a single parameter, projectId, with no description and zero schema coverage. The description only says 'in an authorized project,' which hints that projectId should reference an authorized project, but it does not explain what the parameter format is, how to obtain a valid ID, or that it might be listed via list_projects. Since schema coverage is 0%, the description must compensate, and it fails to do so.

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 ('Run') and the resource ('a fixed, read-only Git status command'), and the 'read-only' plus 'fixed' qualifiers distinguish it from mutation tools like git_commit and git_push, and from comparison tools like git_diff. It is unambiguous what this tool does.

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

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

The description provides no guidance on when to use this tool versus its siblings. It does not mention that git_status is the go-to for checking working tree state, nor does it warn against using it for diffs or staging. It only mentions 'in an authorized project,' which is a prerequisite, not a usage comparison.

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