list_identitiesList the addresses this mailbox can send as, and which one is used by default. Pass one of them as from on send_email, reply_email, forward_email or draft_email to send as that address instead of the default. Addresses are added by the mailbox owner in their account, not through this connector, and the mail server still decides whether it will carry one.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and idempotent hints, the description adds important behavioral context: identities are added by the mailbox owner outside the connector, and the mail server ultimately decides whether it will carry one. It also discloses that one address is the default, which is a meaningful detail for agents.
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?
Three sentences with no redundancy. The first sentence front-loads the core purpose, the second explains how to use the result, and the third adds a caveat about external limitations. Every sentence earns its place.
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 read-only, zero-parameter tool with no output schema, the description fully covers what is returned (the addresses and the default), how to use the result (as `from` in sending tools), and external constraints (owner-managed addresses, server decision). No critical information 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?
The tool has zero parameters, so parameter semantics are not applicable. The description appropriately focuses on output usage instead, and the baseline of 4 for zero-parameter tools applies.
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 action ('List the addresses this mailbox can send as') and identifies the resource (send-as addresses) and the default selection. This clearly distinguishes it from siblings like list_mailboxes, which lists mailboxes rather than identities.
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 gives clear context by explaining that the returned addresses can be passed as `from` on send_email, reply_email, forward_email, and draft_email to override the default. It doesn't explicitly mention alternatives or when-not-to-use, but the intended usage is evident and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools target clearly distinct actions and resource types, and the near-overlapping pairs (archive_email vs move_email, check_bounces vs check_receipts) are explicitly cross-referenced in their descriptions. However, the delivery-status pair genuinely overlaps — both scan inbound mail to answer "did my message get there?" — and archive_email is functionally a role-aware move_email, so an agent could still select the wrong one without careful reading.
Virtually every tool follows a consistent verb_noun pattern with clear prefix families (check_*, create_*, draft_*, list_*, mark_*, read_*). The single outlier is not_junk, which breaks the mark_* symmetry of its counterpart mark_junk and is not a standard verb-noun construction, though it remains perfectly readable.
31 tools is firmly in the heavy range, though email is a genuinely broad domain spanning send/reply/forward, three draft variants, folder management, flags, junk handling, and diagnostics. Real consolidation was possible — check_bounces and check_receipts could be one delivery-status tool, archive_email is a special case of move_email, and the read-state/flag pairs could take boolean parameters — but each tool has a defensible job.
The core email lifecycle is thoroughly covered: send/reply/forward, three draft types plus draft editing, read/search/list/thread, full folder CRUD, move/archive/delete, flags, read state, junk handling, and file-upload intake. Minor gaps exist — there is no permanent-deletion or purge tool, no filter/rules management, and identity/contact maintenance is deliberately out of scope — but real user workflows can be completed without dead ends.