Skip to main content
Glama

gws-mcp__gmail_forward

Destructive

Forward an existing email to another recipient. The account's Gmail signature is appended automatically, so do not write a sign-off or signature in the body yourself; pass signature: false to send without it. The signature goes in the message's HTML part, so a plain-text body is sent as multipart/alternative when the account has one. The response's signature field reports what happened.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "message_id": "<message_id>",
      "to": "<to>"
    },
    "name": "gws-mcp__gmail_forward"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYesRecipient email address to forward to
bodyNoOptional plain-text note included above the forwarded message
accountNoOptional email address of the connected account to use (e.g. 'user@gmail.com'). If omitted, the default account is used.
html_bodyNoOptional HTML note included above the forwarded message. The forward goes out with both an HTML part and a plain-text part, and the forwarded block is formatted with Gmail styling. Provide body or html_body, not both.
signatureNoSet false to send without the account's Gmail signature, and to skip the lookup entirely. Defaults to true.
message_idYesThe Gmail message ID to forward
attachmentsNoFiles to send with the message, at most 10, 25 MB in total. Each entry is a Drive file id as a string, or {"file_id": "<id>", "as": "<format>"} to send a Google Doc, Sheet or Slides deck as a file, or a file reference. Formats: Docs pdf, docx, txt, html, md, rtf, odt, epub; Sheets pdf, xlsx, csv, tsv, html, ods; Slides pdf, pptx, txt, odp. csv and tsv export one tab: add "tab": "<title>" to choose it, otherwise the first tab goes, and the response says which. A Sheet as html arrives as a .zip of pages, one per tab; Slides as txt is the slides' visible text only. Google Docs, Sheets and Slides passed by id alone are sent as links in the message, the way Gmail does, not as files. Other Drive files are attached as they are. A file reference is an object with a "type": {"type": "gmail_message", "message_id": "<id>"} attaches an email as its original .eml, {"type": "gmail_attachment", "message_id": "<id>", "part_id": "<part id>"} one attachment of an email, {"type": "drive_file", "file_id": "<id>"} a Drive file as stored, {"type": "drive_export", "file_id": "<id>", "format": "pdf"} a Google file exported, {"type": "content", "name": "<file name>", "base64": "<standard base64, one unbroken string>"} a file the caller already holds, at most 1 MB, and {"type": "upload", "upload_id": "<id>"} a file the user sent through file_upload_link. A reference may carry an "account" naming the connected Google account that holds the email or file. Several entries may be references. Two attachments may not share a filename. To show an image in the body rather than at the bottom, reference it in html_body as <img src="cid:FILENAME">, where FILENAME is its Drive filename with any character other than letters, digits, dot, dash and underscore replaced by an underscore. Sharing a Drive link is the sender's responsibility; nothing here changes who can open a file. The response's attachments field reports each file as attached, inline, linked or exported, with its size and the SHA-256 of the bytes that went into the message; a file sent as a link has neither.
include_original_attachmentsNoThe original message's own attachments are forwarded with it, counted in the 25 MB limit. Set false to forward the text alone. Defaults to true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

The description adds real behavioral context beyond the annotations: the signature is appended automatically, goes in the HTML part, triggers multipart/alternative when a plain-text body is present, and is reported in the response's signature field. Annotations already declare the mutating/destructive nature, so this is solid added value without contradiction.

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?

Four tight sentences, front-loaded with the core action and then the signature caveat. No filler, and each sentence addresses a distinct behavior.

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 a mutating forward tool with rich schema coverage and annotations carrying the safety profile, the description covers the key surprising behavior (auto-signature) and points to a response field. It leaves thread/limit details to the schema, which is reasonable.

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 coverage is 100%, so baseline is 3, but the description adds meaning about how the signature parameter interacts with the body and HTML parts that the schema alone does not spell out. This earns above-baseline credit.

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 states a specific verb and resource: 'Forward an existing email to another recipient.' It is clear and distinguishable from gmail_send or gmail_reply by the word 'forward', though it does not explicitly name those siblings.

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?

Usage is implied by the word 'forward', but the description gives no explicit when-to-use versus gmail_reply or gmail_send guidance, and no exclusions. It does provide actionable guidance about not writing a signature and passing signature: false.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.