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

With no annotations at all, the description carries the full burden and mostly meets it: it discloses that submission triggers an email to the person, that a click is required before any provider sees the enquiry, and that the tool performs validation rather than committing a purchase. It stops short of stating idempotency (what a repeat step-1 or step-2 call does) or failure handling, which for a mutation-style tool with zero annotation coverage keeps it below a 5.

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 critical constraint (not a purchase) is front-loaded and the Step 1 / Step 2 structure maps directly onto the call sequence an agent must perform. The one redundancy is the consent sentence, quoted verbatim in both the description and the consent parameter's schema description, which is space that could have carried other behavioral detail.

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-phase, human-in-the-loop tool with no output schema and a nested answers object, the description supplies everything an agent needs: call order, required flags per phase, what step 1 returns in prose, and when the enquiry actually becomes visible to providers. Nothing essential about correct invocation is left to inference.

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 the baseline is 3, but the description adds real meaning: where answer keys come from (enquiry_fields), the temporal ordering of the confirmation token (only after step 1 and only after human approval), and that consent must be true on both calls. That goes beyond the per-parameter schema text, though it does not explain how nested answers are scoped or typed.

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?

"Submits an enquiry to FlightDelayHQ" gives a specific verb and resource, and the immediate negation ("NOT a purchase, NOT a guaranteed quote") pre-empts the most likely agent misread. It is clearly distinguishable from data-lookup siblings such as enquiry_fields or dataset_search, which cannot submit anything.

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 spells out the exact two-call sequence: step 1 with answers plus consent=true for validation, then step 2 only "if the person agrees" with the token added. It also names the required intermediary human action (show the summary and consent line), which is genuine when-and-when-not guidance rather than a restatement of the schema.

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