Skip to main content
Glama
rajool

google-workspace-mcp

by rajool
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

gmail_draft_update

Update an existing Gmail draft with new recipients, subject, body, or attachments. Pass thread_id for replies to preserve the conversation and quote history.

Instructions

Overwrite an existing draft's contents.

Pass thread_id when the draft is a reply — it keeps the draft attached to
that thread (an update without it detaches the draft) and re-quotes the
thread's history, so `body` stays just the new text.

Body format: write `body` as plain text — blank-line paragraphs,
"- " bullets, "1." / "1)" numbered lines (ASCII or Persian digits).
It goes out as multipart/alternative with a Gmail-composer-style HTML
part, so lists arrive as Gmail's real bullets/numbering and the draft
can be opened and sent from the Gmail web UI safely. Never hard-wrap
lines yourself. Set html=true only for a body that is already HTML.

`attachments` are paths on the machine running this server. Each is
attached under its own file name, with the MIME type guessed from that
name and `application/octet-stream` as the fallback.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNo
toYes
bccNo
bodyYes
htmlNo
accountYes
subjectYes
draft_idYes
thread_idNo
attachmentsNo
quote_historyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.10.1
    • addedInput schema / properties / attachments
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Attachments"
+}
    • addedInput schema / properties / quote_history
      Added value: +{
+  "default": true,
+  "title": "Quote History",
+  "type": "boolean"
+}
    • addedInput schema / properties / thread_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Thread Id"
+}
  2. First observedv0.3.0

TDQS

A4.4/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 burden and delivers richly: it discloses the overwrite side-effect, the detachment behavior ('an update without it detaches the draft'), the multipart/alternative MIME conversion with Gmail-composer-style HTML, Gmail-native list rendering, and the application/octet-stream MIME fallback for attachments. This exceeds what annotations would typically convey.

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?

Four front-loaded paragraphs, each earning its place: a one-sentence purpose statement, then dense but relevant guidance on thread_id semantics, body format with explicit constraints, and attachment path semantics. There is no filler, repetition, or boilerplate.

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 an 11-parameter tool with zero annotations, zero schema descriptions, and no output schema, this is close to complete: purpose, threading side-effects, body formatting rules, and attachment semantics are all covered in depth. Minor gaps remain — quote_history's meaning is never tied to the thread_id re-quoting behavior, and the success/return value is unspecified.

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 0%, and the description compensates for the four hardest parameters: thread_id (thread attachment plus re-quoting of history), body (plain-text format rules, blank-line paragraphs, bullet/numbering syntax, no hard-wrapping), html (reserved for already-HTML bodies), and attachments (server-local paths with MIME guessing). However, the remaining seven parameters — including quote_history, which has a non-obvious default of true — receive no semantic explanation, though most are self-evident from their names.

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?

Opens with a specific verb+resource combination: 'Overwrite an existing draft's contents.' This unambiguously distinguishes it from sibling draft tools — gmail_draft_create creates, gmail_draft_send sends, gmail_draft_delete removes — and the word 'existing' marks the scope as mutation of a previously created draft.

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?

Provides strong conditional guidance for parameters ('Pass thread_id when the draft is a reply', 'Set html=true only for a body that is already HTML'), but never names an alternative tool or states when not to use this one. The distinction from gmail_draft_create is only implied by the word 'existing' rather than made explicit.

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