Skip to main content
Glama
iTvX

Google Workspace MCP — Gmail edition

by iTvX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

send_email

Send emails from a Gmail account—new messages, replies, forwards, or saved drafts—immediately upon invocation. For approval workflows, create a draft first and send it after review.

Instructions

Send mail from a Gmail account: a new message, a reply, a reply-all, or a forward. It sends immediately, so call it only for a message the user asked for, with the complete final text. email is the account the message is sent FROM. To prepare mail for the user to review first, use manage_email createDraft, then sendDraft here once they approve it.

Input 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)
emailYesAccount email address this acts as. Required: there is no default account here.
draftIdNoDraft id (the r… id from listDrafts or createDraft), not a message id
subjectNoEmail subject line
messageIdNoEmail message ID
operationYessend: compose and send a new email (attachments up to 25 MB via the upload endpoint) | reply: reply to a message (thread-aware) | replyAll: reply-all to a message (thread-aware, includes all recipients) | forward: forward a message to new recipients (includes original attachments by default) | sendDraft: send a saved draft exactly as it is, by its draft id (the r… id from manage_email listDrafts or createDraft). Use this after the user has reviewed a draft, so what goes out is what they read.
attachmentsNoWorkspace filenames to attach, comma-separated (files must exist in workspace via manage_workspace).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.8.0

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose the critical trait — it 'sends immediately,' so it is irreversible — plus that `email` has no default account here. It does not cover broader auth expectations (e.g. that `from` requires a verified Send As alias) or any rate limits, which keeps it short of a 5.

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?

Three tight sentences that are strictly front-loaded: the destructive/immediacy constraint and the createDraft alternative both come before any parameter talk. Zero 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 12-parameter, no-annotation, no-output-schema tool, the description covers the two things an agent most needs and the schema cannot express: that sending is immediate/irreversible and that the correct pre-review path is createDraft + sendDraft. Per-parameter detail (cc, bcc, body, html, attachments) is already documented in the schema, so no return-value or parameter explanation 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; however the description adds meaning the schema alone does not by resolving the easily-confused `email` vs `from` pair — '`email` is the account the message is sent FROM' (the acting account) versus `from` as an alias. Thread-aware semantics for reply/replyAll are also sketched, though no syntax examples are given.

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 opening sentence names the specific verb and resource and enumerates the four message kinds handled (new, reply, reply-all, forward), matching the operation enum. It also distinguishes itself from the sibling manage_email by naming createDraft as the non-sending alternative.

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?

Explicit when/when-not: 'call it only for a message the user asked for, with the complete final text,' plus a concrete alternative workflow ('use manage_email createDraft, then sendDraft here once they approve it'). Nothing about routing is left to inference.

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

Deploy Server

Other Tools