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

Annotations already declare readOnly=false, idempotent=true, destructive=true, and openWorld=false. The description adds meaningful behavioral context beyond those annotations: it enforces 'exactly one target' among four mutually exclusive targeting modes, explains the scope of each target, and clarifies that only pre-existing intended deliveries are re-sent. It does not contradict any annotation, though it omits finer details such as failure modes or what happens to already-sent rows.

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?

The description is two tightly structured sentences, front-loaded with the core action and then the targeting rules and sibling alternative. Every clause earns its place, using punctuation (em dash, semicolon) to pack dense but necessary information without waste.

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 6-parameter mutation tool with an output schema and rich annotations, the description covers purpose, targeting constraints, parameter roles, and the key alternative tool. Return values can be inferred from the output schema, and safety traits are covered by annotations, so nothing essential is missing for correct invocation.

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?

With schema description coverage at only 17%, the description compensates by explaining the role of responseIds, destinationKey, deliveryKind+deliveryId, and all, along with the critical 'exactly one target' constraint. The form parameter is documented in the schema, and enum values for deliveryKind are self-explanatory, but some specifics like the 200-item limit on responseIds remain undocumented.

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 uses a specific verb and resource ('Repair failed deliveries') and explicitly distinguishes the tool from its sibling fillo_redeliver_responses by contrasting 're-sends work that was already meant to go out' with a 'deliberate new send.' An agent can identify exactly what this tool does and how it differs from alternatives without opening the schema.

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?

The description states the precise condition for using this tool—only re-sending previously intended work—and names the alternative tool and condition for a new send ('use fillo_redeliver_responses for a deliberate new send'). This is explicit when/when-not guidance with a routing decision.

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