Skip to main content
Glama
gmail-mcp

gmail-mcp

reply_email

Send a reply within an existing Gmail thread, automatically adding "Re:" to the subject and optionally CC all original recipients.

Instructions

Convenience wrapper to reply to an existing thread.

Automatically prepends "Re: " to the subject if missing.
Can CC all original recipients with reply_all=True.

Required:
  to (str) — recipient address.
  body (str) — reply text.
  thread_id (str) — Gmail thread ID to reply within.
  in_reply_to (str) — Gmail message ID being replied to.
    GET THIS FROM get_thread_messages(thread_id) — do not guess.

Optional:
  subject (str, default="") — if empty, "Re: " is prepended to the
    original message's subject.
  cc (str, default="") — additional CC recipients.
  bcc (str, default="") — BCC recipients.
  reply_all (bool, default=False) — if True, auto-CCs all other
    recipients from the original message (To and CC headers).

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

Workflow note: CRITICAL — in_reply_to must be a Gmail message ID
  (e.g. "19e09c7f2e8d487d"), NOT an email Message-ID header
  (e.g. "<CAC4dBmc...@mail.gmail.com>"). To find the right ID:
    1. Call get_thread_messages(thread_id)
    2. Pick the message ID from the "messages" array
    3. Pass that to reply_email's in_reply_to parameter

Input Schema

NameRequiredDescriptionDefault
ccNo
toYes
bccNo
bodyYes
subjectNo
reply_allNo
thread_idYes
in_reply_toYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full burden and does disclose real behavior: automatic "Re: " prefixing, reply_all auto-CCing To and CC headers from the original, and the exact effect of leaving subject empty. It omits whether sending is immediate/irreversible and says nothing about failure modes or auth expectations, which matters for a send-type operation.

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?

Front-loaded one-line summary followed by grouped required/optional/return sections is easy to scan. The in_reply_to warning is stated twice (inline and again in the workflow note), which is a slight redundancy — justified by the criticality, but still duplicated text.

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 an 8-parameter send tool with no annotations and no output schema, the description covers purpose, every parameter, the return payload shape, and the multi-step prerequisite for the hardest parameter. Nothing an agent needs in order to call it correctly is absent.

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%, so the description must compensate entirely — and it does, documenting all eight parameters with type, default, and semantics (e.g. cc is *additional* CC beyond reply_all's auto-CC, subject is ignored when empty). It also adds critical format constraints for in_reply_to that the schema could never convey.

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?

"Convenience wrapper to reply to an existing thread" names a specific verb and resource and immediately separates it from send_email (new mail) by scoping it to an existing thread. An agent can tell from the first sentence alone which operation it is invoking.

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?

The description gives a clear precondition (an existing thread plus a Gmail message ID fetched via get_thread_messages) and states the condition for reply_all=True. What is missing is an explicit negative case, e.g. "do not use for new mail, use send_email" — the sibling routing is implied rather than stated.

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