Skip to main content
Glama
Sign In
gmail-mcp

gmail-mcp

by DimitrisPasakaleris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

send_email

Compose and send a new Gmail message, including CC, BCC, and file attachments, or reply within an existing thread using thread and message headers.

Instructions

Send a new email. Can thread into an existing conversation by including
thread_id and in_reply_to/references headers. Supports CC, BCC, and
file attachments.

Required:
  to (str) — recipient email address.
  subject (str) — email subject line.
  body (str) — email body text.

Optional:
  cc (str, default="") — CC recipients, comma-separated.
  bcc (str, default="") — BCC recipients, comma-separated.
  thread_id (str, default="") — Gmail thread ID to reply within.
    If provided with in_reply_to and references, the email threads
    into the existing conversation.
  in_reply_to (str, default="") — the Message-ID header of the
    message being replied to. Required for threading.
  references (str, default="") — References header for threading.
    Usually same as in_reply_to.
  attachments (list[str] | None, default=None) — absolute file paths
    to files to attach. Paths must be absolute or relative to cwd.

Returns on success:
  {"message_id": "...", "thread_id": "...", "to": "...", "subject": "..."}

Workflow note: For threading, you need both thread_id and in_reply_to.
  If you only have a thread_id but not in_reply_to, use
  get_thread_messages(thread_id) first to find a message_id.
  Attachments: paths must exist and be under 25MB.
  The body parameter is the email text — not a file path.

Input Schema

NameRequiredDescriptionDefault
ccNo
toYes
bccNo
bodyYes
subjectYes
thread_idNo
referencesNo
attachmentsNo
in_reply_toNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.4/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 well: it discloses the return shape, threading requirements, attachment size limits and path rules, and clarifies that body is text rather than a file path. It stops short of stating that sending delivers immediately and is effectively irreversible, and it says nothing about permission or rate-limit behavior.

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 description is front-loaded with purpose, then organized into required, optional, returns, and workflow sections. Every sentence carries actionable information, and the parameter list is easy to scan without redundancy.

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 nine-parameter mutation tool with no output schema and no annotations, this is complete enough to call correctly. It covers required inputs, optional threading and attachment behavior, a recovery path for missing message IDs, and the return value.

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?

Schema description coverage is 0%, but the description compensates fully by documenting all nine parameters with types, defaults, and meaning, including the subtle distinction that in_reply_to is required for threading even when thread_id is present. This is exactly what the description should add beyond a bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Send a new email') and explains the threading capability, which goes beyond a generic send tool. However, it never differentiates this from the sibling reply_email tool, leaving the agent to infer which one handles an in-thread response.

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?

It gives concrete workflow guidance for threading, including the prerequisite of having both thread_id and in_reply_to and a fallback to get_thread_messages. It also states attachment constraints. What it lacks is explicit routing guidance versus reply_email or create_draft, so the when-not-to-use case is absent.

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