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 a genuinely important trait: the revert creates a new commit that 'deploys like a push,' warning the agent of a deployment side effect. However, it omits auth/permission requirements, reversibility, and whether the operation is destructive.

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 tightly written sentences with zero waste. The core operation is front-loaded and the deploy consequence follows immediately. Nothing is padded.

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 terse but does disclose the critical deploy side effect. It still leaves gaps around permissions, reversibility, and return behavior that an agent invoking a git history rewrite would benefit from.

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 67%, above the low-coverage threshold. The description implies the commit and branch context but adds no format or syntax detail. The required 'commit' parameter has no schema description and is not clarified in the description either, so this is a minimum-viable 3.

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 and resource: 'Revert a commit on a branch server-side.' This clearly distinguishes it as a git-level operation, though it does not explicitly differentiate from the sibling 'rollback' tool, which an agent could plausibly 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 explicit when-to-use or when-not-to-use guidance. The alternative 'rollback' sibling is never named, and no condition is given for choosing git.revert over it. The only hint is the deploy consequence, which is a side-effect note rather than usage guidance.

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