Skip to main content
Glama
tom275275

Google Workspace MCP Server

by tom275275

draft_gmail_message

Create Gmail drafts with attachments, CC/BCC, and send-as aliases. Draft new emails or replies within existing threads.

Instructions

Creates a draft email in the user's Gmail account. Supports both new drafts and reply drafts with optional attachments. Supports Gmail's "Send As" feature to draft from configured alias addresses.

Args: user_google_email (str): The user's Google email address. Required for authentication. subject (str): Email subject. body (str): Email body (plain text). body_format (Literal['plain', 'html']): Email body format. Defaults to 'plain'. to (Optional[str]): Optional recipient email address. Can be left empty for drafts. 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 draft will be from the authenticated user's primary email address. thread_id (Optional[str]): Optional Gmail thread ID to reply within. When provided, creates a reply draft. 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'). attachments (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') include_signature (bool): Whether to append Gmail signature HTML from send-as settings. If unavailable (e.g., missing gmail.settings.basic scope), the draft is still created without signature. quote_original (bool): Whether to include the original message as a quoted reply. Requires thread_id to be provided. When enabled, fetches the original message and appends it below the signature. Defaults to False.

Returns: str: Confirmation message with the created draft's ID.

Examples: # Create a new draft draft_gmail_message(subject="Hello", body="Hi there!", to="user@example.com")

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

# Create a plaintext draft with CC and BCC
draft_gmail_message(
    subject="Project Update",
    body="Here's the latest update...",
    to="user@example.com",
    cc="manager@example.com",
    bcc="archive@example.com"
)

# Create a HTML draft with CC and BCC
draft_gmail_message(
    subject="Project Update",
    body="<strong>Hi there!</strong>",
    body_format="html",
    to="user@example.com",
    cc="manager@example.com",
    bcc="archive@example.com"
)

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

# Create a reply draft in HTML
draft_gmail_message(
    subject="Re: Meeting tomorrow",
    body="<strong>Thanks for the update!</strong>",
    body_format="html",
    to="user@example.com",
    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.
toNoOptional recipient email address.
bccNoOptional BCC email address.
bodyYesEmail body (plain text).
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' (auto-detected from path if not provided).
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>').
quote_originalNoWhether to include the original message as a quoted reply. Requires thread_id. Defaults to false.
include_signatureNoWhether to append the Gmail signature from Settings > Signature when available. Defaults to true.
user_google_emailYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.14.3

TDQS

A4/5.0
Behavior4/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, and it does well: it discloses that include_signature degrades gracefully when scopes are missing, that quote_original fetches the original message and appends it below the signature, that attachments auto-encode vs. require base64, and that the result is a confirmation string with the draft ID. It only omits minor traits like rate limits and explicit 'this does not send the email' language.

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

Conciseness3/5

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

The structure is excellent—core purpose front-loaded, then Args/Returns/Examples—but the length is excessive. The Args section largely restates schema descriptions, and the six examples repeat similar invocation patterns (e.g., two nearly identical reply examples differing only in body_format). A tighter version with 2-3 examples and less schema duplication would earn higher marks.

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 complex 15-parameter tool with no annotations and an output schema, the description is nearly complete: it covers authentication, reply threading, alias sending, attachment encoding, signature fallback, and return format. Gaps include error conditions (invalid thread_id, unconfigured alias) and explicit contrast with the sibling send tool, but overall an agent can call this correctly from the description alone.

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 high at 93%, setting a baseline of 3, but the description adds genuinely useful semantics beyond the schema: the two attachment dict formats with base64-not-urlsafe and MIME auto-detection, the dependency that quote_original requires thread_id, the threading relationship among thread_id/in_reply_to/references, and the 'Send As' alias configuration requirement. This elevates it above the baseline.

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 sentence states the exact verb and resource: 'Creates a draft email in the user's Gmail account.' It immediately clarifies this is a draft, not a send, which distinguishes it from the sibling send_gmail_message. The second sentence adds scope (new drafts, reply drafts, attachments), making the tool's boundary crisp.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied through six varied examples (new draft, alias, CC/BCC, HTML, replies) but never stated explicitly. There is no sentence telling an agent 'use this when you want to draft rather than send, and use send_gmail_message when the message should be sent immediately.' The reply-draft mechanics are documented, but the when/when-not selection guidance 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