diff_review

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

No annotations provided, and the description does not disclose read-only behavior, side effects, or limitations. It implies a review operation but does not confirm no mutable actions. Basic but insufficient.

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?

Very concise, front-loaded purpose, efficient bullet points. No unnecessary words.

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?

Despite good explanation of core functionality, the description omits details about required parameter 'agents', output format, and other optional parameters. Incomplete for a 6-param tool with no output 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 has 0% description coverage. The description explains diff_text and git_ref+cwd relationship but does not describe required 'agents' parameter or 'focus' and 'timeout_seconds'. Only partial compensation.

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 tool reviews git diffs for risks, regressions, and breaking changes, using a specific verb and resource. It distinguishes from sibling tools like codereview by focusing on git diffs and specific risk detection.

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?

Provides explicit use cases (pre-merge sanity check, spotting breaking changes, cross-validation) and explains the mutually exclusive input modes. Does not explicitly state when not to use or compare with siblings, but covers main scenarios.

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