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

Richly discloses behavior beyond the annotations: it creates a self-addressed draft (a write, consistent with readOnlyHint=false and destructiveHint=false), explains the draft is the person's to see, that sending turns it into a test message to themselves, the inference heuristic used (marked block, else shared closing lines, never a 'Sent from my iPhone' line), and IMAP-specific sourcing. Prerequisites and refusal conditions are surfaced, all beyond what annotations declare.

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 content is valuable but delivered as one long, densely embedded run-on sentence with awkward phrasing ('the person's to see', 'takes the name its newest sent mail goes out under'), making it hard to parse. The lead action is front-loaded, but the structure sacrifices readability for compression.

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?

An output schema exists, so return values needn't be explained, and the description covers the remaining essentials: the required tool permissions, the server-side-signature refusal, the draft side effect, the downstream patch hand-off, and the IMAP caveat. Nothing an agent needs to invoke it correctly 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?

Single parameter 'mailbox' with 100% schema coverage already documenting it as name or email address, so baseline is 3. The description adds no new parameter-level detail, only behavioral notes about IMAP sending-name resolution.

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+resource (find the signature) and clarifies it does more than a read: it also writes the result into a new self-addressed draft. It implicitly distinguishes itself from settings_send_as_get (which reads the configured signature) and settings_send_as_patch (which applies it), though those sibling names are not stated explicitly as alternatives.

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 real prerequisites (messages_get and drafts_create must be enabled per mailbox) and an explicit refusal condition (company adds a signature server-side). It also defines the downstream hand-off: only on the person's word does settings_send_as_patch with fromDraft keep the signature. It stops short of stating a clear 'use this vs settings_send_as_get' selection rule.

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