MCP Emails

Search and Move

email_search_and_move

DestructiveIdempotent

Move every message matching a search into a destination folder, in one server-side operation, so no message ID is ever stale by the time it is used. Search uses structured, provider-agnostic fields (from, to, cc, subject, body, text, unread, has_attachment, flagged, since, before) that the server translates into the inbox's native search syntax, so you never need provider query syntax; query is a raw escape hatch. SEPARATE from email_organize, and flagged destructive to your MCP client, because it acts on everything the filter matches rather than on ids you chose: one wrong filter relocates a whole inbox. To move messages you have already listed, use email_organize (action 'move' or 'move_batch') instead. Bounded by limit, maximum and default 500: check has_more before reporting a mailbox fully swept, and finish any remainder with email_organize (action 'move_batch'). On Gmail, moving adds the destination label and removes the INBOX label. Returns succeeded/failed counts and per-message results. Needs manage:folders.

Input Schema

TableJSON Schema

Name	Required	Description
`cc`	No	Cc recipient to match: address, name, or fragment.
`to`	No	To recipient to match: address, name, or fragment.
`body`	No	Text to find in the body. On Gmail this matches the whole message.
`from`	No	Sender to match: address, name, or fragment.
`text`	No	Text to match anywhere, headers included.
`inbox`	No	Inbox email address, an alternative to inbox_id.
`limit`	No	Cap on messages moved. Default 500.
`query`	No	Provider-native raw query (escape hatch); prefer the structured fields. Ignored on Fastmail.
`since`	No	Received on or after this date or datetime (no timezone = UTC). Also takes "2026-06", "today", "7 days ago", "last month" or "30d".
`before`	No	Received strictly before this date or datetime (no timezone = UTC). Takes the same relative forms as `since`.
`unread`	No	true = unread only; false = read only; omit for both.
`flagged`	No	true = only flagged/starred messages.
`subject`	No	Text to match in the subject, as written. Gmail (API or IMAP) and Outlook match WHOLE WORDS, so a partial word finds nothing; other IMAP servers substring-match.
`inbox_id`	No	Inbox UUID from inbox_list. Optional when the key has one inbox; pass this or `inbox`, not both — a pair naming different mailboxes is refused.
`has_attachment`	No	true = only messages with an attachment. Ignored on generic IMAP.
`idempotency_key`	No	Reuse only when retrying the identical request within 24 hours; the retry is collapsed, not repeated. Reuse with different arguments is rejected.
`include_folders`	No	Folders to search, each an alias, a folder or label name, or a folder id (names and aliases resolve for you). IMAP covers INBOX only unless you name archive or sent folders; Gmail and Outlook search every folder except the trash (Deleted Items on Outlook; Gmail also skips Spam), so name it to include it.
`destination_folder_id`	Yes	Target folder: an alias (inbox, sent, drafts, trash, archive, spam), a folder name, or a folder id. Names and aliases resolve for you.

Output Schema

TableJSON Schema

Name	Required	Description
`limit`	No	The limit that bounded the search.
`notes`	No	Server notes about how this call was handled — for example an argument that was not applied because the selected action does not accept it. Written by MCP Emails, not taken from any message, and absent when there is nothing to report.
`failed`	Yes
`partial`	No	True when the operation did NOT process every message it was given. succeeded/failed describe only what was attempted; remaining_message_ids lists what was left untouched.
`results`	Yes
`has_more`	No	True when messages matching the query were left UNTOUCHED because of the limit. Check this before reporting the sweep complete: re-run until it is false.
`inbox_id`	Yes
`operation`	Yes
`remaining`	No
`succeeded`	Yes
`match_count`	No	How many messages the search returned, i.e. the most this call could act on.
`continuation`	No
`limit_notice`	No	Present only when has_more: plain-language statement of what was left behind.
`limit_reached`	No	True when the search filled its window and stopped counting. On its own it does not prove more mail exists; has_more is that claim.
`total_matches`	No	Provider's total match count when it supplies one.
`partial_notice`	No
`stopped_reason`	No	'cancelled' — a person stopped the run from the dashboard. 'time_budget' — the server stopped on its own wall-clock limit so the result could be returned before the client timed out. Neither is an error.
`total_requested`	No
`remaining_message_ids`	No	Messages that were NOT processed and are unchanged. These exact ids, not a repeat of the original search, are what a follow-up call should use.
`total_matches_is_estimate`	No	True when total_matches is a provider estimate (Gmail) rather than a count.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 26, 2026

changedInput schema / properties / include_folders / description

Previous value: -"Folders to search, each an alias, a folder or label name, or a folder id (names and aliases resolve for you). IMAP covers INBOX only unless you name archive or sent folders; Gmail and Outlook always search everything."New value: +"Folders to search, each an alias, a folder or label name, or a folder id (names and aliases resolve for you). IMAP covers INBOX only unless you name archive or sent folders; Gmail and Outlook search every folder except the trash (Deleted Items on Outlook; Gmail also skips Spam), so name it to include it."

Changed2 schema fields changedSep 26, 2026

changedInput schema / properties / flagged / description

Previous value: -"true = only flagged/starred messages. Ignored on Outlook."New value: +"true = only flagged/starred messages."

addedOutput schema / properties / results / items / properties / new_message_id

Added value: +{
+  "description": "Moves only: the message's id in the destination folder, to use for any further action on it. Omitted when the id did not change or was not reported.",
+  "type": "string"
+}

Changed4 schema fields changedSep 21, 2026

changedInput schema / properties / before / description

Previous value: -"Received strictly before this date or datetime (no timezone = UTC)."New value: +"Received strictly before this date or datetime (no timezone = UTC). Takes the same relative forms as `since`."

changedInput schema / properties / inbox_id / description

Previous value: -"Inbox UUID from inbox_list. Optional when the key has one inbox; pass this or `inbox`, not both."New value: +"Inbox UUID from inbox_list. Optional when the key has one inbox; pass this or `inbox`, not both — a pair naming different mailboxes is refused."

changedInput schema / properties / since / description

Previous value: -"Received on or after this date or datetime (no timezone = UTC)."New value: +"Received on or after this date or datetime (no timezone = UTC). Also takes \"2026-06\", \"today\", \"7 days ago\", \"last month\" or \"30d\"."

changedInput schema / properties / subject / description

Previous value: -"Text to match in the subject; phrases match as-is."New value: +"Text to match in the subject, as written. Gmail (API or IMAP) and Outlook match WHOLE WORDS, so a partial word finds nothing; other IMAP servers substring-match."

Changed1 schema field changedSep 14, 2026

changedInput schema / properties / include_folders / description

Previous value: -"Folder names to search. IMAP covers INBOX only when omitted."New value: +"Folders to search, each an alias, a folder or label name, or a folder id (names and aliases resolve for you). IMAP covers INBOX only unless you name archive or sent folders; Gmail and Outlook always search everything."

AddedSep 10, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond annotations by explaining that the tool acts on everything the filter matches, not on chosen IDs, and that one wrong filter can relocate a whole inbox. It also discloses provider-specific Gmail label behavior, the 500-message limit and has_more semantics, the manage:folders permission requirement, and the return counts.

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?

The description is long but every sentence carries operational value, and the most important warning (destructive, acts on all matches) is front-loaded. It could be slightly easier to scan with paragraph breaks, but there is no wasted or redundant prose.

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?

Given the tool's complexity and destructive nature, the description covers purpose, alternatives, limits, continuation behavior, provider-specific semantics, permissions, and return values. An agent has enough to invoke it safely and to know when to route to email_organize instead.

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 meaningful collective context: structured fields are provider-agnostic and translated server-side, while `query` is only a raw escape hatch. It doesn't enumerate every parameter, but the schema already documents those details thoroughly.

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?

States a specific verb and resource: 'Move every message matching a search into a destination folder, in one server-side operation.' It clearly distinguishes itself from email_organize and explains the core value (no stale message IDs). The title and name are also reinforced rather than merely repeated.

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?

Explicitly says when to use this tool versus the sibling: 'To move messages you have already listed, use email_organize (action "move" or "move_batch") instead.' It also warns about the destructive blast radius and instructs on checking has_more and finishing remainder via email_organize, giving concrete operational guidance.

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

All MCP Emails tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.