Skip to main content
Glama
Albretsen

MCP Emails

Automations

automation
Destructive

Create and manage unattended email triage rules that run on a schedule, applying actions like move, label, mark read, forward, or draft reply based on search filters. Preview before enabling.

Instructions

Create and manage unattended scheduled triage rules. A rule is a stored search plus one fixed action, evaluated on a cadence with NO model in the loop: mail is matched, never interpreted. Set action: 'create' (name, filter, rule_action, interval_minutes; the rule is created DISABLED), 'list', 'get' (automation_id), 'update' (automation_id + fields), 'enable'/'disable' (automation_id), 'delete' (automation_id; run history is kept), 'runs' (automation_id, recent run counters), or 'preview' (DRY RUN: reports what a filter matches right now and applies nothing). NOTE the two different keys: action selects the operation on this tool, while rule_action is the action the RULE performs on matching mail. Rule actions are move, label (applied as a Gmail label, an Outlook category or an IMAP keyword), mark_read, forward and draft_reply. DELETING MAIL IS NOT AVAILABLE to an automation. A forward is ALWAYS held for human approval whatever the inbox's approval setting says, and a draft_reply only ever writes a draft. Always 'preview' before you 'enable'. Every action needs manage:automations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoHuman-readable name for the rule.
inboxNoInbox email address; an alternative to inbox_id, which wins when both are given.
limitNoHow many runs to return, newest first.
actionYesOperation to run.
filterNoThe stored search, as the same structured criteria email_search takes: from, to, cc, subject, body, text, unread, has_attachment, flagged, since, before. At least one criterion is required - an empty filter matches the whole mailbox. Provider-native 'raw' queries are NOT accepted here: a rule re-executes unattended for months, and a raw string is a dialect nothing validates.
inbox_idNoInbox UUID. Optional when the key has exactly one inbox. Otherwise pass this or `inbox`; omit both and the error lists every inbox_id.
rule_actionNoOne tagged action. {type:'move',folder} | {type:'label',label} (applied as a Gmail label, an Outlook category, or an IMAP keyword; on IMAP a label is an atom, so spaces become underscores and ( ) [ ] { } % * " \ are refused) | {type:'mark_read'} | {type:'forward',to:[...],note} | {type:'draft_reply',template}. DELETING MAIL IS NOT AVAILABLE to an automation and is refused. 'forward' is ALWAYS held for human approval regardless of the inbox's approval setting, and 'draft_reply' only ever creates a draft. A draft_reply template substitutes {{sender_name}}, {{sender_email}}, {{subject}} and {{date}} and nothing else; everything else is literal text and message bodies are never interpolated.
automation_idNoThe automation's UUID, as returned by action 'list' or 'create'.
interval_minutesNoMinutes between runs. A fixed ladder, not a free integer: a 1-minute rule hammers a provider into rate limiting.
max_messages_per_runNoPer-run blast radius. Caps how much mail one misconfigured filter can touch before a human sees the run log.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv1.0.4

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, so the description carries the burden of elaborating side effects — and it does so thoroughly. It discloses that rules are created DISABLED, delete keeps run history, preview is a DRY RUN, forward is ALWAYS held for approval, draft_reply only writes a draft, and label semantics vary by provider. This goes well beyond the annotation hints and prevents agent surprise.

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 dense but every sentence earns its place. It front-loads the core concept, then systematically covers actions, key naming, rule actions, safety constraints, and permissions. It is longer than average, but the tool's scope — nine operations with nested objects — justifies the length. No filler or tautology.

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 tool with 10 parameters, nested objects, nine actions, and no output schema, the description is remarkably complete. The schema's conditional blocks handle per-action requirements, while the description supplies all interpretive context: filter criteria reference, raw-query rejection, interval ladder rationale, per-run blast radius, approval behavior, and permission requirements. Nothing an agent needs to invoke this safely 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. The description adds meaning well beyond the schema: it resolves the confusing action vs rule_action naming, explains preview's dry-run semantics, details label application differences (Gmail label, Outlook category, IMAP keyword), and documents draft_reply template substitution limits. The only minor deduction is that parameter semantics could have been even more explicitly mapped to each action.

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+resource combination: 'Create and manage unattended scheduled triage rules.' It immediately clarifies the tool's nature — a stored search plus one fixed action, evaluated on a cadence with no model in the loop. It distinguishes itself from siblings like email_delete and email_compose by enumerating rule actions and explicitly stating deletion is unavailable.

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?

The description gives explicit operational guidance: 'Always preview before you enable', notes that every action needs manage:automations, explains the two-key distinction between action and rule_action, and states when the tool is not appropriate (raw queries are rejected, deleting mail is refused). This is strong when-to-use and when-not-to-use guidance.

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

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/Albretsen/MCPEmails'

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