check_decisions

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

With no annotations, the description carries the full burden and does it well: it discloses that the diff of tracked changes is uploaded to a Lockstep server (untracked files are excluded), that a 'skipped' status is returned unless hosted diff checks are on, and that findings are advisory rather than blocking. These are exactly the side-effect and outcome traits an agent needs before calling.

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?

Four tight sentences, front-loaded with the purpose and scope, then the gating behavior, parameter note, and return shape. The parameter sentence is somewhat redundant with the schema but not wasteful enough to penalize heavily.

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?

Covers the upload behavior, the skipped-status path, the finding shape (file, line, rule), and the advisory nature — all important for a tool with no output schema. Minor gaps remain around required permissions or configuration for enabling lockstep checks, but the agent has enough to act 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 coverage is 100% and the schema already documents `base` with its default of HEAD. The description only restates 'the optional base is the git ref to diff against', adding no format guidance or examples beyond the schema. 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?

Opens with a specific verb+resource: 'Check the working-tree diff against accepted decisions.' It also names the sibling `decisions` for the adjacent read-the-rules task, so the agent can tell the two apart without opening either schema.

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 gives a clear context (working-tree diff checking) and routes the agent to `decisions` when it wants to read the decisions themselves. It doesn't state explicit when-not-to-use conditions or a workflow point (e.g. before commit), so it falls short of a 5.

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