Skip to main content
Glama
privacyfence

PrivacyFence

Official
by privacyfence
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

gmail_create_draft

Creates a new Gmail draft for messages without attachments, saving it without sending and requiring user approval.

Instructions

Create a Gmail draft. Returns {draft_id, to, subject}; the draft is only saved, never sent. Use gmail_create_draft_with_attachments instead when there is something to attach, and gmail_reply_draft to answer an existing message so the draft threads with it. Requires user approval.

Input Schema

NameRequiredDescriptionDefault
ccNoCc 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.
toYesRecipient 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.
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.
subjectYesSubject line of the new draft.
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. Changed4 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: +"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 / subject / description
      Added value: +"Subject line of the new draft."
    • addedInput schema / properties / to / description
      Added value: +"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."
  2. First observedv5.3.0

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already declare the write/safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds two genuinely useful facts beyond them: 'the draft is only saved, never sent' and the approval requirement. It does not, however, cover retry/idempotency behavior or what happens on send_as validation failure.

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?

Three sentences, zero waste, front-loaded with the core action and the never-sent guarantee before the sibling routing. Every clause carries information the agent needs.

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?

With no output schema, the description helpfully names the return shape ({draft_id, to, subject}), and it covers the mutation/approval semantics and alternative tools. Nothing needed to call this 9-param tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each of the 9 parameters is already documented in detail (send_as constraints, body/body_markdown interaction, signature handling). The description adds no parameter-level meaning beyond that, which is the expected baseline when the schema does the work.

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 ('Create a Gmail draft') and immediately distinguishes itself from the two nearest siblings (gmail_create_draft_with_attachments, gmail_reply_draft). An agent can route correctly 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?

Gives explicit when-to-use-this-elsewhere routing: attachments go to gmail_create_draft_with_attachments, answering an existing message goes to gmail_reply_draft (with the reason, threading). It also states the prerequisite 'Requires user approval.'

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