Skip to main content
Glama

mail_overview

Read-only

List every mailbox with total and unread counts, unread-first, to quickly identify what is unread where and triage mail across accounts.

Instructions

Every mailbox with its message total and unread count, unread-first — the triage entry point ("what's unread where?"). Rows are {account, account_id, mailbox, folder, total, unread}: account_id is the same uuid every mail Pointer reports as account, so ONE call here is the whole uuid -> name map; folder is the exact mailbox url, so a mailbox picked here round-trips into mail_search/mail_body without going back through name matching. Includes Junk/Trash/All Mail so you can see what they are rather than having them silently filtered. Counts are computed live, not read from Mail's own stored counters, which go stale, and each message is counted ONCE even when it is filed in the same mailbox twice. Account NAMES are looked up through Mail, so this tool does contact Mail (launching it if it isn't running); when Mail is unreachable the account UUID stands in and the counts — which never needed Mail — are still correct. An account Mail answers but does not list (for example a removed one) shows "(account not in Mail)" as its account; account_id keeps the uuid. The On My Mac store is always shown as "On My Mac": Mail never lists it as an account. Fast and read-only. Needs Full Disk Access for the counts and Automation access for Mail for the account names.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.15.1

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/non-destructive annotations, it discloses that the tool contacts and may launch Mail, that counts remain correct without Mail, the fallback UUID-as-name behavior, the '(account not in Mail)' sentinel, the always-shown 'On My Mac' store, live vs. stale counting, double-filing dedupe, and both required permissions (Full Disk Access, Automation). That is unusually rich behavioral context for a read-only tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the triage use case are front-loaded, and nearly every sentence carries operational information the agent needs (uuid mapping, folder round-trip, permission needs). It is dense and includes a small amount of overlap with the annotations ('Fast and read-only'), which keeps it just below a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-param read-only tool with an output schema, the description is complete: it covers what is returned, edge cases (unlisted account, On My Mac, unreachable Mail), counting correctness, and permission prerequisites. Nothing an agent needs to call it safely and interpret results is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is no parameter meaning to add and baseline is 4. The description instead specifies the row shape and field semantics ({account, account_id, mailbox, folder, total, unread}), which is value-add even if it belongs more to output semantics than parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names the verb, the resource, the scope (every mailbox), and the differentiator ('unread-first'), and frames it as the triage entry point. An agent can tell immediately this is a survey/count tool rather than a search or body-fetch tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is clearly implied with 'triage entry point ("what's unread where?")' and the concrete follow-on workflow into `mail_search`/`mail_body` via the round-tripping `folder` url. It stops short of explicitly distinguishing itself from siblings like `mail_stats` or naming when not to use it, so it is clear context without exclusions.

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