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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, non-idempotent), and the description adds real value beyond that: it discloses that invite triggers an immediate outbound email to the business, and that close discards the enquiry with an optional internal note. It doesn't say whether close is irreversible or whether invite can be repeated — with idempotentHint=false already declared, this is a modest gap rather than a failure.

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?

Two compact sentences, front-loaded with the audience restriction, which is good. But the content is slightly redundant — the invite/close mechanics appear in the schema parameter descriptions too — and the final clause about immediate email is tacked on rather than integrated.

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?

A three-parameter mutation with no output schema and no confirmation of what the tool returns (a status? the updated enquiry?). The description covers eligibility and both branches but leaves the agent guessing what to report back after a successful invite, which matters for a tool with real-world side effects like sending mail.

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% and each parameter already has its own description including the enum meaning and note's close-only restriction. The description restates the same invite/close semantics and adds the 'optional note for us' framing, but contributes no syntax or format detail beyond the schema.

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 states a specific verb pair (invite/close) on a specific resource (an enquiry listed by op_leads), and explains what each branch does behaviorally — invite emails setup instructions, close drops it. It's clear apart from siblings like op_decide_application, though the title alone would be ambiguous.

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?

It explicitly names the audience ('Only for the Awning team') and the precondition ('an enquiry op_leads listed'), which tells the agent to call op_leads first. What's missing is guidance on choosing invite vs close — no criteria for when each decision is appropriate beyond the bare mechanics.

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