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

Beyond the annotations, it discloses the effect scope (the bell, the digest, and site health) and an important negative ('No alert is re-sent'). It also names the domain field (aiTriage.setAside) that identifies the affected run, which is real behavioral context the annotations cannot carry.

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?

Three sentences, front-loaded with the action and its effect, with the trigger condition last. The parenthetical 'a site on level "aside"' is slightly awkward but earns its place by clarifying the domain term. No wasted padding.

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 output schema and a single required param, it covers action, effect scope, alert behavior, and trigger condition. What remains unstated (permissions, reversibility) is minor for this domain and partially implied by idempotentHint.

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 single parameter runId is 100% covered by the schema ('The set-aside run'). The description reinforces that the target must be a set-aside run but adds no syntax, format, or constraint detail beyond the schema, so the 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?

States a specific verb and resource ('bring back a set-aside failure', 'make it count as a failure again') and explains the mechanic being reversed (aiTriage.setAside). It anchors to the sibling get_run, so an agent can tell exactly which state is being toggled.

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?

Gives an explicit trigger: 'Use it when the user says the failure is real.' It also names get_run as the way to detect the set-aside state, which is effectively the precondition. No explicit when-not-to-use or named alternative is given, so it stops short of 5.

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