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

Annotations already mark the tool as read-only, idempotent, and non-destructive, so the safety profile is clear without the description. The description adds useful behavioral context by revealing that provider contact directories exist only for Gmail/Microsoft and not generic IMAP, which sets expectations about availability and fallback behavior. No contradictions with annotations.

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 sentences deliver the core action, the purpose, and the key limitation without wasted words. The primary verb and resource are front-loaded, and the IMAP caveat is the second sentence.

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?

With no output schema, the description nevertheless provides enough context for correct invocation: provider scope, when to use it, and a fallback for IMAP. The account_id disambiguation rules are detailed in the schema. The main omission is a concrete statement of what the response contains (e.g., contact names and addresses), but this is not critical for a list operation.

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?

The input schema documents cursor and account_id with detailed descriptions, but the tool description itself does not explain any parameters. At 67% schema coverage, the missing limit description is minor given its simple min/max integer type. Overall the description adds no parameter semantics beyond the schema, but the schema handles most of the load; a neutral score is appropriate.

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 opens with a specific verb ('List'), resource ('contacts'), and provider scope ('Gmail/Microsoft'), and ties it to a concrete workflow ('resolve a human recipient name to an email address before composing'). It also distinguishes the tool from generic IMAP by noting that IMAP has no provider contact directory. This clearly differentiates it from siblings like email_list_messages or whatsapp_list_contacts.

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 explicitly defines when to use the tool ('before composing') and when not to ('Generic IMAP normally has no provider contact directory'), directing users to 'use mailbox context instead.' The account_id schema description further clarifies the multi-account case with explicit instructions to list and ask rather than guess. This gives the agent unambiguous routing guidance.

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