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

Annotations flag destructiveHint=true and openWorldHint=true, and the description adds real context beyond them: dry_run defaults to true and reports quota consumption and launch blockers, idempotency_key makes retries safe, and screening is gated on a confirmed email plus an approved criteria stage. It stops short of saying what is actually mutated or consumed when a launch proceeds despite destructiveHint=true.

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?

Front-loaded with the triggering condition, then split by action value, which matches the two-mode shape of the tool. Dense but every clause carries information; only the parenthetical retry note is slightly compressed.

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?

With no output schema, the description still explains what a dry_run returns (record counts, human-verification quota share, blockers). It leaves the return shape of an actual launch and of a decide call unstated, and does not name a sibling for listing screening results, but the gating and safety story is otherwise complete for an 8-parameter mutation 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 88%, so the baseline is 3, but the description goes further by tying dry_run to its default behavior, linking idempotency_key to retry safety within a window, and stressing that decide records exactly ONE decision. Those cross-parameter relationships are not in the schema itself.

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 for each mode ('AI screening run' vs 'a screening decision recorded') and immediately enumerates the two action values. An agent can tell this apart from the read-side sibling revisia_screening and from bulk work, which the description pushes to the web app.

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?

Opens with an explicit when-to-use sentence, then gives an exclusion ('bulk changes are made in the web app') and prerequisites ('Screening needs a confirmed email and an approved criteria stage'). It also sets the default expectation for dry_run before launch, so the agent knows the safe first call.

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