Skip to main content
Glama
tom275275

Google Workspace MCP Server

by tom275275

send_gmail_message

Send Gmail messages with attachments, replies, CC/BCC, and alias support. Compose plain-text or HTML emails and deliver them through the user's Gmail account.

Instructions

Sends an email using the user's Gmail account. Supports both new emails and replies with optional attachments. Supports Gmail's "Send As" feature to send from configured alias addresses.

Args: to (str): Recipient email address. subject (str): Email subject. body (str): Email body content. body_format (Literal['plain', 'html']): Email body format. Defaults to 'plain'. attachments (Optional[List[Dict[str, str]]]): Optional list of attachments. Each dict can contain: Option 1 - File path (auto-encodes): - 'path' (required): File path to attach - 'filename' (optional): Override filename - 'mime_type' (optional): Override MIME type (auto-detected if not provided) Option 2 - Base64 content: - 'content' (required): Standard base64-encoded file content (not urlsafe) - 'filename' (required): Name of the file - 'mime_type' (optional): MIME type (defaults to 'application/octet-stream') cc (Optional[str]): Optional CC email address. bcc (Optional[str]): Optional BCC email address. from_name (Optional[str]): Optional sender display name. If provided, the From header will be formatted as 'Name '. from_email (Optional[str]): Optional 'Send As' alias email address. The alias must be configured in Gmail settings (Settings > Accounts > Send mail as). If not provided, the email will be sent from the authenticated user's primary email address. user_google_email (str): The user's Google email address. Required for authentication. thread_id (Optional[str]): Optional Gmail thread ID to reply within. When provided, sends a reply. in_reply_to (Optional[str]): Optional RFC Message-ID of the message being replied to (e.g., 'message123@gmail.com'). references (Optional[str]): Optional chain of RFC Message-IDs for proper threading (e.g., 'msg1@gmail.com msg2@gmail.com').

Returns: str: Confirmation message with the sent email's message ID.

Examples: # Send a new email send_gmail_message(to="user@example.com", subject="Hello", body="Hi there!")

# Send with a custom display name
send_gmail_message(to="user@example.com", subject="Hello", body="Hi there!", from_name="John Doe")

# Send an HTML email
send_gmail_message(
    to="user@example.com",
    subject="Hello",
    body="<strong>Hi there!</strong>",
    body_format="html"
)

# Send from a configured alias (Send As)
send_gmail_message(
    to="user@example.com",
    subject="Business Inquiry",
    body="Hello from my business address...",
    from_email="business@mydomain.com"
)

# Send an email with CC and BCC
send_gmail_message(
    to="user@example.com",
    cc="manager@example.com",
    bcc="archive@example.com",
    subject="Project Update",
    body="Here's the latest update..."
)

# Send an email with attachments (using file path)
send_gmail_message(
    to="user@example.com",
    subject="Report",
    body="Please see attached report.",
    attachments=[{
        "path": "/path/to/report.pdf"
    }]
)

# Send an email with attachments (using base64 content)
send_gmail_message(
    to="user@example.com",
    subject="Report",
    body="Please see attached report.",
    attachments=[{
        "filename": "report.pdf",
        "content": "JVBERi0xLjQK...",  # base64 encoded PDF
        "mime_type": "application/pdf"
    }]
)

# Send a reply
send_gmail_message(
    to="user@example.com",
    subject="Re: Meeting tomorrow",
    body="Thanks for the update!",
    thread_id="thread_123",
    in_reply_to="<message123@gmail.com>",
    references="<original@gmail.com> <message123@gmail.com>"
)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNoOptional CC email address.
toYesRecipient email address.
bccNoOptional BCC email address.
bodyYesEmail body content (plain text or HTML).
subjectYesEmail subject.
from_nameNoOptional sender display name (e.g., 'Peter Hartree'). If provided, the From header will be formatted as 'Name <email>'.
thread_idNoOptional Gmail thread ID to reply within.
from_emailNoOptional 'Send As' alias email address. Must be configured in Gmail settings (Settings > Accounts > Send mail as). If not provided, uses the authenticated user's email.
referencesNoOptional chain of Message-IDs for proper threading.
attachmentsNoOptional list of attachments. Each can have: "path" (file path, auto-encodes), OR "content" (standard base64, not urlsafe) + "filename". Optional "mime_type". Example: [{"path": "/path/to/file.pdf"}] or [{"filename": "doc.pdf", "content": "base64data", "mime_type": "application/pdf"}]
body_formatNoEmail body format. Use 'plain' for plaintext or 'html' for HTML content.plain
in_reply_toNoOptional RFC Message-ID of the message being replied to (e.g., '<message123@gmail.com>').
user_google_emailYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.14.3

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full disclosure burden and meets it: it states that the tool actually sends email, describes reply behavior via thread_id/in_reply_to/references, explains attachment auto-encoding vs raw base64, notes mime defaulting, and calls out auth and alias configuration requirements.

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 structure is strong: purpose first, then Args, Returns, Examples. However, the Args section largely duplicates the input-schema content and the nine examples, while instructive, make the description longer than necessary for the information conveyed.

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?

For a 13-parameter sending tool, the description covers nearly every operational aspect: auth, aliases, threading, attachments, body formats, and return value. It is slightly incomplete in not mentioning the prerequisite start_google_auth flow or explicitly steering agents toward draft_gmail_message when the user wants a draft rather than an immediate send.

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?

Even though schema coverage is 92%, the description adds meaningful semantics beyond the schema: 'path' auto-encodes, base64 must be standard (not urlsafe), mime_type auto-detected, 'from_name' formats the From header as 'Name <email>', and the alias must be configured in Gmail settings. The examples make non-obvious combinations concrete.

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 first line states a specific verb and resource: 'Sends an email using the user's Gmail account.' It then enumerates the exact behaviors (new emails, replies, attachments, Send As aliases), making it easy to distinguish from sibling Gmail tools like search_gmail_messages or draft_gmail_message.

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?

Clear context is provided for when to use the tool: sending a new message, replying within a thread, using CC/BCC, sending HTML, or using a Send As alias. It does not explicitly name alternatives such as draft_gmail_message or chat send_message, so it misses the 'when-not/alternatives' requirement for a 5.

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