Skip to main content
Glama
privacyfence

PrivacyFence

Official
by privacyfence
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

gmail_reply_draft

Create a Gmail draft replying to one message in the same thread, addressed only to the original sender, and return its draft and thread IDs. Requires user approval.

Instructions

Create a Gmail draft replying to a single message, staying in the same thread (sets threadId plus In-Reply-To/References so it actually threads, unlike gmail_create_draft). Addressed only to the original sender. Returns {draft_id, thread_id, to, cc, subject}; the subject is the original's with 'Re: ' added if missing, and cc holds only the addresses you passed. Use gmail_reply_all_draft instead to include the other participants, and gmail_reply_draft_with_attachments when there is something to attach. Requires user approval.

Input Schema

NameRequiredDescriptionDefault
ccNoExtra Cc recipient address(es): one, or several separated by commas. Each may be a bare address or 'Name <name@example.com>'; a display name must not contain a comma. Empty means none.
bccNoBcc recipient address(es): one, or several separated by commas. Each may be a bare address or 'Name <name@example.com>'; a display name must not contain a comma. Empty means none.
bodyNoPlain-text body. May be omitted if body_markdown is given -- the plain-text alternative is then auto-derived from it. At least one of body/body_markdown is required.
reasonYesOne sentence: why are you calling this tool right now?
send_asNoSend from this Gmail send-as address instead of the account's default (sets From:, and the signature used is this address's own). Must be one of the account's configured send-as addresses -- anything else is rejected.
message_idYesId of the message to reply to, from gmail_list_messages (its id field). The draft goes in that message's thread.
body_markdownNoOptional Markdown body for a rich-text draft. Supports **bold**, *italic*, ==highlight==, [links](url), bullet/numbered lists, and `# Heading 1`/`## Heading 2` (rendered as Gmail's Large/Huge font-size presets, not raw heading tags -- no tables). When given, the draft is sent as plain text + HTML together, so it renders formatted in HTML-capable clients and as readable plain text everywhere else.
include_signatureNoAppend the user's Gmail signature (the one Gmail stores for the sending address) to the end of the body. Omit to use the user's 'Append Gmail signature to drafts' setting. Don't also write a sign-off block of your own when this is on.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / bcc / description
      Added value: +"Bcc recipient address(es): one, or several separated by commas. Each may be a bare address or 'Name <name@example.com>'; a display name must not contain a comma. Empty means none."
    • addedInput schema / properties / cc / description
      Added value: +"Extra Cc recipient address(es): one, or several separated by commas. Each may be a bare address or 'Name <name@example.com>'; a display name must not contain a comma. Empty means none."
    • addedInput schema / properties / message_id / description
      Added value: +"Id of the message to reply to, from gmail_list_messages (its id field). The draft goes in that message's thread."
  2. First observedv5.3.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnly=false, idempotent=false, destructive=false. The description goes well beyond that: it discloses the threading headers written, the single-recipient addressing rule, the subject derivation ('Re: ' added if missing), that cc holds only what was passed, the return shape, and that user approval is required. That is rich behavioral context an annotation cannot carry.

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?

It is a long single paragraph, but front-loaded with the action and threading behavior, and every clause (subject rule, cc rule, return shape, sibling routing, approval) carries information. Slightly dense for one block; bullets would read better, but nothing is padding.

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?

No output schema exists, and the description compensates by naming the return fields {draft_id, thread_id, to, cc, subject}. Combined with the threading, addressing, approval, and sibling-routing details, an agent has everything needed to call this correctly.

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 description coverage is already 100%, so the baseline is 3. The description adds real parameter-level meaning on top: the subject is the original's with 'Re: ' added if missing, and cc contains only the addresses supplied rather than auto-populated participants. That clarifies the effect of the cc parameter beyond its schema text.

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?

States a specific verb+resource ('Create a Gmail draft replying to a single message') and immediately adds the distinguishing mechanic: it threads properly by setting threadId plus In-Reply-To/References, 'unlike gmail_create_draft'. An agent can separate this from gmail_reply_all_draft and the attachment variants without opening any schema.

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?

Explicitly routes the agent: use gmail_reply_all_draft to include other participants, and gmail_reply_draft_with_attachments when something must be attached. It also notes the addressing constraint (reply goes only to the original sender), which is precisely the condition that decides between siblings.

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