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

With no annotations, the description carries the full burden and does so well: it discloses that step 1 is non-committal, that submission triggers an email requiring a click before any provider sees the data, that up to three suppliers will be chosen and contacted, and the exact consent text. Side effects, sequencing, and downstream consequences are all spelled out.

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 disambiguation ('NOT a purchase'), then the two steps in order. The quoted consent text is long but it is verbatim user-facing copy the agent must display, so it earns its space; a small amount of repetition of the consent definition between description and schema is the only slack.

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?

No output schema exists, yet the description enumerates what step 1 returns (summary, consent line, confirmation token) and what step 2 produces (submission plus a verification email). For a nested-object, two-phase tool with zero annotations, nothing material is missing.

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 consent string is already fully documented there. The description still adds value by tying 'answers' to the field keys from enquiry_fields, and by clarifying that 'confirmation' is the token returned from step 1 and only applies on the second call — sequencing meaning the schema alone does not convey.

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 (submits) and resource (enquiry to Mail Merge PDF) and immediately negates the two most likely misclassifications — 'NOT a purchase, NOT a guaranteed quote' — so an agent won't confuse it with a transactional tool. The title and description agree, and the sibling tools (enquiry_fields, enquiry_describe) are implied as the discovery path for the answers payload.

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?

Gives an explicit two-step protocol: step 1 validates and returns a summary/token, step 2 is only called after the person approves. It states the precise gating condition ('only if the person agrees') and what must be shown to the user before proceeding, which is exactly the when/when-not guidance an agent needs.

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