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

Annotations already establish readOnly, idempotent, non-destructive, non-open-world behavior. The description adds genuinely useful context beyond that: this tool only reports connection state and cannot connect a mailbox (that happens in Settings), and it reveals approval requirements. The legal-compliance paragraph is not behavioral context about the tool itself and dilutes the signal.

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 purpose is front-loaded, but the description then sprawls into a Czech e-mail marketing law citation (§ 7 of Act 480/2004 Coll.) and LinkedIn outreach advice that is unrelated to listing e-mail integrations. This is off-topic content that inflates the definition and obscures the core function.

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 zero-parameter read tool with no output schema, the definition covers what is listed (connected mailboxes, approval need) adequately. The appended legal/outreach guidance adds no completeness value regarding the tool's actual behavior or return shape.

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 tool takes no parameters, so the baseline is 4. The mailbox_id/provider_campaign_id remark refers to send_email, not this tool's inputs, so it adds no parameter meaning here but does not mislead.

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 opening states a specific verb and resource: it shows which of the user's own mailboxes (Outlook or IMAP/SMTP) are connected, and whether manual approval is required. That is clear and distinct from sibling list_* tools, though it does not explicitly contrast itself with adjacent tools like get_email_status or list_email_outreach.

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?

'Use to see which...' gives a positive usage cue and it notes that the actual connecting happens in the app, implying this tool only reads. However, it never states when NOT to use it or which sibling to pick instead, so an agent must infer the boundaries.

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