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

Annotations declare readOnlyHint=false and idempotentHint=true, so the agent already knows this mutates state and is safe to repeat. The description adds genuine value by disclosing the auth requirement (get_free_key) and the scoping to 'your own guard,' but it never says whether the label takes effect immediately, whether more labels can be batched, or what comes back after labeling.

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 short sentences, front-loaded with the action and its payoff, then the prerequisite, then the benefit statistic. The benchmark figure supports adoption rather than the mechanics of the call, but it is brief enough not to crowd out the operative content.

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 two-parameter, non-read-only tool with no output schema, the description covers purpose, trigger condition, auth prerequisite, and expected effect. The remaining gap is post-call behavior – whether labeling is immediate and whether there is any confirmation or cost – which matters somewhat for a mutating tool.

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%, so both parameters are already documented, making 3 the baseline. The description earns above that by translating the two error modes it names – false alarm and missed injection – onto the meaning of the boolean 'injection' field, giving the agent a semantic mapping rather than just a type.

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 ('Label one prompt for your own guard') and frames the outcome ('stops repeating a mistake'), which is concrete enough to separate it from check_prompt. It does not explicitly name check_prompt as the runtime-check counterpart, so sibling differentiation is implied rather than stated.

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 a clear trigger condition – the guard is making a recurring error, either a false alarm on a normal request or a missed injection – and names get_free_key as the prerequisite for the API key. It stops short of an explicit exclusion such as 'do not use this for one-off verdicts; use check_prompt instead.'

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