Skip to main content
Glama

Set mail flags

set_mail_flags
DestructiveIdempotent

Set email read/unread and star status, and add, remove, or replace keywords/tags. Reversible changes tracked via requestId for safe retries.

Instructions

Marks one email read or unread, stars or unstars it, and adds, removes, or replaces its keywords — the labels a mail client shows as tags. Every value is optional and at least one is required; a call that names none is refused. The change is written down durably and issued to the mail server by the account's next synchronization run, so the result reports the records rather than a mailbox that has already changed: each carries a changeRecordId and the lifecycle it has reached. To read where a change has got to, call again with the same requestId, which answers with the same records and their current lifecycle. Every change is reversible: call again with the opposite value. keywordChange replace states the whole keyword set — a keyword you do not list is removed, and an empty list clears them all — so read the email's keywords first, or use add and remove, which touch only what they name. Only these three values can be written: this tool never sets the answered or draft flags, never deletes mail, and never sends anything.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
seenNotrue marks the email read, false marks it unread. Omit it to leave the flag where it stands. Reading mail through MailFathom never sets it, so this is the only way it moves from here.
flaggedNotrue stars the email, false unstars it. This is the flag a mail client draws as a star or a flag, and it is what the owner will see in their own client.
keywordsNoThe keywords the change names, at most 64, each at most 64 characters. A keyword is an IMAP atom: no space, no control character, none of ( ) { % * " \ ], nothing above plain ASCII, and no leading backslash, which is how system flags are spelled. Two spellings differing only in case are one keyword. An empty list is accepted only with replace, where it clears every keyword.
requestIdNoYour own identifier for this request, at most 128 characters. Send the same one when retrying a call that may have gone through: the change is then the same request and is not made twice. A call with a new value, or with none, is a new request — which is what lets you star a message, unstar it, and star it again. Reusing one to ask for a different value is refused, so send a new identifier whenever you mean a new change.
keywordChangeNoWhat to do with keywords: add puts the listed ones on beside whatever the email already carries, remove takes the listed ones off and leaves the rest, replace makes the keywords exactly the listed ones. Send it together with keywords; either one alone is refused.
storedEmailIdYesThe storedEmailId a listing, a search, or a read returned for the email. A UUID that does not change when the mail server renumbers or moves the message.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
accountIdYesThe account the email belongs to. Its next synchronization run is what issues the change to the mail server.
folderAliasYesThe folder alias the email is in, as MailFathom's configuration names it.
storedEmailIdYesThe storedEmailId the change was recorded against, which is the one the call named.
recordedChangesYesOne entry per value asked for, in the order seen, flagged, keywords. A call that asked for one value carries one entry.
Install Server

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description explains durability ('written down durably and issued to the mail server by the account's next synchronization run'), result shape ('changeRecordId and the lifecycle'), idempotent retry behavior, reversibility, and the replace semantics that removes unlisted keywords. This is rich behavioral context that annotations alone do not provide.

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

Conciseness5/5

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

The description is a single dense paragraph but every sentence contributes essential information: purpose, required-value rule, durability, idempotency, reversibility, keyword replace caveat, and exclusions. It is front-loaded with the core action and then layers necessary nuance without redundancy.

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 six parameters, complex keyword semantics, idempotency concerns, and output schema, the description covers all critical behavioral aspects: what happens on retry, how replace differs from add/remove, what cannot be changed, and how results are reported. It leaves no major operational gap.

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

Parameters5/5

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

Although the schema already documents each parameter in detail, the description adds crucial cross-parameter semantics: the requirement that at least one value be set, the interplay between keywordChange and keywords, the full-set replacement behavior of 'replace', and the requestId rules for deduplication versus new changes. This goes well beyond the schema descriptions.

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 opens with a specific verb and resource: 'Marks one email read or unread, stars or unstars it, and adds, removes, or replaces its keywords.' This clearly distinguishes the tool from siblings like delete_draft or send_email, and the closing exclusion ('never sets the answered or draft flags, never deletes mail, and never sends anything') reinforces its scope.

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?

The description gives clear operational guidance: at least one value is required, keywordChange must accompany keywords, and same requestId semantics for retries. It also states exclusions versus other mail actions, though it does not explicitly name alternative sibling tools for cases like deleting or sending.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Krzysztof318/MailFathom'

If you have feedback or need assistance with the MCP directory API, please join our Discord server