Skip to main content
Glama

Select emails for a bulk action

select_emails
Read-onlyIdempotent

Find every message matching a search, up to 500 at a time, and return their UIDs grouped by folder and then by sender, for one bulk call per folder of delete_email, move_email, archive_email, mark_junk, not_junk, mark_read, mark_unread, flag_email or unflag_email. Each sender group gives the address and name, how many, how many unread and flagged, the delivery date range and up to 3 of its subjects, so what matched can be told to the user before anything changes; there are no previews or bodies. search_emails, by contrast, returns at most 100 full summaries, for finding particular messages. fromAny takes up to 20 senders, matched as alternatives; all: true takes every message in the named folders. Matching is by substring, as in search_emails, so a search can match senders it was not aimed at; each has its own group, except that senders past the 25 largest share one group that lists their addresses. A capped result says so, with the true total.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNoSubstring match against the Cc address or display name.
onNoDelivered on exactly this date (e.g. "2026-08-01"). Matches when the message arrived in this mailbox, not its Date: header.
toNoSubstring match against the To address or display name.
allNotrue: every message in the named folders, with no other condition. Stated explicitly, because an empty call is refused.
bodyNoSubstring match against the message body.
fromNoOne sender. Substring match against the From address or display name.
seenNoFilter by read/unread status.
textNoSubstring match against headers and body together.
limitNoHow many UIDs to return across all the folders, newest first within each. Defaults to 500, the most one write call takes.
sinceNoDelivered on or after this date (e.g. "2026-08-01"). Matches when the message arrived in this mailbox, not its Date: header. Whole-day precision only.
beforeNoDelivered before this date (e.g. "2026-08-01"). Matches when the message arrived in this mailbox, not its Date: header. Whole-day precision only.
flaggedNoFilter by the flagged/starred state.
fromAnyNoUp to 20 senders, any of them. Substring matches, as `from`. Not together with `from`.
subjectNoSubstring match against the subject line.
answeredNoFilter by whether the message has been answered.
mailboxesNoIMAP folders to select from, e.g. ["INBOX"]. Defaults to ["INBOX"]. Up to 25 in one call. A write call acts on one folder, so each folder in the answer is one write call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: no previews or bodies are returned, capped results report the true total, substring matching can match unintended senders, and senders past the 25 largest are collapsed into one shared group. That is exactly the kind of behavioral detail an agent needs before deciding to act.

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?

It is a single very long, densely packed sentence chain, but every clause carries information and the core purpose is front-loaded. Structure could be improved by splitting it, but there is essentially no filler.

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 16-parameter, no-output-schema tool, the description covers return shape (groups, counts, date range, subjects), the cap behavior, and the workflow fit with write tools. Nothing an agent needs to call it correctly 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: fromAny is described as matched-alternatives with a 20-sender cap, all:true as the no-condition escape hatch, and the substring caveat applies to the whole matching model. It does not, however, add much for the individual date/flag filters, which the schema already documents.

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 description states a specific verb (find/select), resource (messages matching a search), result shape (UIDs grouped by folder then sender) and purpose (feeding bulk per-folder write calls). It explicitly contrasts with search_emails, so an agent can distinguish the two without opening either schema.

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

Usage Guidelines5/5

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

It names the exact downstream tools this feeds (delete_email, move_email, archive_email, mark_junk, etc.), specifies the one-write-call-per-folder constraint, and states when to prefer search_emails instead. Both the when and the alternative are explicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources