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

Goes well beyond the annotations by disclosing that out-of-scope runs are rejected before evaluation, that the original is preserved (reinforcing destructiveHint=false), that it consumes separate evaluator capacity, that it never reruns the target, and that assessment-create authority is required. This is rich, actionable behavioral context.

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 purpose and scope, and each subsequent sentence (scope rejection, capacity cost, authority requirement) carries distinct information. Dense but not padded.

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?

Behavior is well covered, but with no output schema and a complex nested rubric parameter, the description leaves the agent guessing about the rubric argument and the returned assessment. It is adequate on behavior yet incomplete on the inputs/outputs an agent must handle.

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 only 20% (just operationKey), and the nested rubric object is entirely undocumented. The description gestures at project/environment scope and saved evidence but adds no field-level semantics, syntax, or format guidance, so it fails to compensate for the coverage gap.

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 ('Request a new bounded assessment of saved evidence') plus scope ('explicitly selected project/environment'), which is enough to separate it from listing tools like firedrill_assessments and from firedrill_compare. The 'preserving the original' and 'never reruns the target' clauses pin down exactly what kind of assessment this is.

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?

Implied usage is present: this is for reassessing already-saved evidence without rerunning the target. However, it never names an alternative tool or a when-not condition, so the agent must infer when to prefer this over firedrill_assessments or a fresh run.

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