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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral return context: the verdict categories, rationale, alternatives, risks, and gate requirements. It does not add operational details like rate limits, but the annotations carry that burden.

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?

It is a single dense sentence that front-loads the input scope ('For one ... item') and then enumerates the returned information. There is no filler or redundancy, though the long comma-separated clause list makes it slightly less scannable than ideal.

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 tool with no output schema, the description usefully outlines the response content: fit verdict, strength and why, alternatives and their advice, risks, and required gates. The nested context schema is richly documented elsewhere. The main missing piece is sibling routing guidance, which keeps it from a 5.

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 100%, with id, lang, and context parameters fully documented, including enum values and nested context field descriptions. The description adds only the conceptual idea of evaluating an item against 'this context,' not any parameter syntax or meaning beyond the schema. Baseline 3 is appropriate.

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 evaluation task: for one named item (event, practice, technique, etc.), decide whether it fits the given context and return fit, rationale, alternatives, risks, and required gates. This is clear enough to distinguish from siblings like search_graph or validate_plan, though it does not explicitly name or compare against any sibling tool.

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?

It identifies the input scope ('For one ... item') but gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. With siblings such as check_gate, check_mix, and explain_node, an agent must infer when this tool is preferable.

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