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

Annotations already indicate a non-read-only action, but the description adds meaningful context: it sends a real enquiry to a specific inbox, requires consent, and warns against inventing details. It provides more behavioral depth than the annotations alone, though it doesn't describe post-send behavior (e.g., confirmation message to user).

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 front-loaded with the core purpose, then transitions to conditions and caveats. Every sentence carries essential information with no filler. Despite being two sentences, it balances completeness with brevity.

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 real-world action tool with 8 parameters and no output schema, the description covers prerequisites, missing-data handling, and confirmation steps. It lacks explicit details on the tool's return value or what happens after sending, but given the exceptional usage guidance, it is nearly complete. Sibling context also makes it clear this is the only action 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 description coverage is 63%, and the description mentions name, email, and 'what they need' (message), but does not clarify optional parameters like budget, company, or timeline. The requirements around asking for missing details and confirming email add some value, but the description mostly reinforces existing schema descriptions rather than adding substantial new semantics.

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 clearly states the verb ('send'), the resource ('a real enquiry to GOJI's studio inbox in Melbourne'), and the action's real-world nature. This distinguishes it sharply from sibling tools, which are all informational (FAQ, glossary, guides, search).

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 provides explicit preconditions: the person must have explicitly asked to be put in touch and given their email. It also gives exclusions ('do not call it speculatively') and practical steps (ask for missing details, confirm the email). This is model guidance for when to use the tool.

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