Skip to main content
Glama
aaronsb

Google Workspace MCP Server

by aaronsb

manage_email

Search, read, send, and manage emails in Google Workspace: find messages with Gmail search syntax, retrieve full content, reply, forward, archive, label, and handle attachments.

Instructions

Search, read, send, forward, or manage emails in a Google Workspace account. Supports Gmail search syntax.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNoCC email(s), comma-separated. On `replyAll` these are ADDITIONAL — they do not replace the recipients already on the thread.
toNoRecipient email(s), comma-separated
bccNoBCC email(s), comma-separated
bodyNoEmail body text. On `forward`, an optional note prepended ABOVE the forwarded message.
fromNoSender email or RFC 2822 mailbox for a verified Gmail Send As alias
htmlNoTreat body as HTML content (default: plain text)
draftNoSave as draft instead of sending (default: false, forced true when attachments present)
emailYesAccount email address
queryNoGmail search query (e.g. "from:alice subject:meeting has:attachment")
subjectNoEmail subject line
filenameNoAttachment filename, exactly as it appears in the `read` response (e.g. 'invoice_template.md')
threadIdNoThread ID to retrieve
messageIdNoEmail message ID
operationYessearch: find emails by query | read: get full email by ID. Pass bodyFormat: 'html' when the plain-text part is a stub (marketing email, invitations, booking confirmations) and the dates/codes you need only exist in the HTML — returned HTML is sanitized and wrapped in a Spotlighting block (ADR-305). | archive: save an email's headers and body to a markdown file in the workspace — a LOCAL archive, not Gmail's 'remove from inbox' (attachments are listed, not downloaded) | send: compose and send a new email (creates draft when attachments present, 35MB attachment limit via upload endpoint) | reply: reply to a message (thread-aware, creates draft when attachments present) | replyAll: reply-all to a message (thread-aware, includes all recipients, creates draft when attachments present) | forward: forward a message to new recipients (includes original attachments by default) | triage: unread inbox summary (sender, subject, date) | trash: move a message to trash | untrash: restore a message from trash | getAttachment: download an email attachment to workspace directory (use read first to see attachment list) | viewAttachment: view an image attachment inline without saving to workspace (png, jpg, gif, webp). Use for quick preview — use getAttachment to save. | modify: add or remove labels on a message (e.g. archive, mark read/unread) | labels: list all labels in the mailbox | threads: list email threads by query | getThread: get all messages in a thread
bodyFormatNoHow to render the message body. 'plain' (default) returns text/plain or a crude HTML-strip fallback. 'html' returns the text/html part sanitized — useful when the plain-text part is empty/stub.
maxResultsNoMax results (default: 10, max: 50)
outputPathNoLocal path to save the markdown file (workspace-relative; defaults to a slug from the message date and subject)
addLabelIdsNoComma-separated label IDs to add (e.g. STARRED, IMPORTANT, Label_123)
attachmentsNoWorkspace filenames to attach, comma-separated (files must exist in workspace via manage_workspace). Creates draft when present.
removeLabelIdsNoComma-separated label IDs to remove (e.g. UNREAD, INBOX to archive)
Install Server

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses meaningful behavioral details: returned HTML is sanitized and wrapped in a Spotlighting block, archive saves locally without downloading attachments, attachments force draft mode, uploads are capped at 35MB, forward includes original attachments, and replyAll treats cc as additional recipients. This is unusually transparent for an email tool.

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 tool description is a single front-loaded sentence naming the resource, major actions, and search syntax support. The operation enum descriptions are long, but each clause is operation-specific and earns its place across 16 distinct operations, with no filler.

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

Completeness4/5

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

Given the high complexity — 20 parameters, 16 operations, no annotations, and no output schema — the description is substantially complete. It covers operation behaviors, attachment handling, draft behavior, and limits. It falls just short of fully complete because return shapes for operations like search, labels, and threads are not described, and no auth/account prerequisites are stated beyond the required email parameter.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents all 20 parameters. The tool-level description adds no parameter-level semantics. The operation enum clarifies behavior, but that detail is part of the schema rather than something the description contributes beyond it.

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 explicit actions on a concrete resource: 'Search, read, send, forward, or manage emails in a Google Workspace account.' It also adds a distinguishing capability, Gmail search syntax support. Sibling tools are calendar/drive/tasks, so this is unambiguously the email tool.

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 operation enum provides detailed routing guidance: read says to pass bodyFormat 'html' when the plain-text part is a stub; viewAttachment says use it for quick preview and use getAttachment to save; archive clarifies it is a local archive, not Gmail's remove-from-inbox. This gives the agent explicit context for choosing among operations.

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/aaronsb/google-workspace-mcp'

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