Skip to main content
Glama

gws-mcp__gmail_reply

Destructive

Reply to an existing email in its thread. The reply is addressed the way Gmail's own Reply does it: to the original's Reply-To when it has one, otherwise to its sender; when you sent the original yourself, to the people it was sent to. Pass reply_all: true to include everyone else on the original as well. The response reports the To and Cc the reply went to; when a Reply-To meant the original's sender was not among them, it also carries reply_to_used: true and original_from, so check to against who you meant to answer, or pass expected_to and the reply is refused instead of sent when it would go anywhere else. A body is required: pass body or html_body. 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>"
    },
    "name": "gws-mcp__gmail_reply"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyNoReply body text (plain). One of body or html_body is required.
accountNoOptional email address of the connected account to use (e.g. 'user@gmail.com'). If omitted, the default account is used.
html_bodyNoHTML reply body. The reply goes out with both an HTML part and a plain-text part derived from it, and the original message is quoted beneath with Gmail styling. Provide body or html_body, not both; one of them is required.
reply_allNoDefault false: the reply goes to one party, the original's Reply-To or sender (or, for a message you sent, its recipients). Set true to reply to everyone: the original's other To recipients are added to To and its Cc recipients to Cc, without your own addresses.
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 reply to
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.
expected_toNoOptional guard: the address or addresses, comma separated, you mean this reply to reach. The reply is refused before anything is sent unless it would go to exactly these (every To address, and every Cc address under reply_all; order and case are ignored). Use it when it matters who receives the reply: the recipients come from the original message's headers, and a Reply-To can name someone other than the sender you see.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

With readOnlyHint=false and destructiveHint=true already declaring this is a mutating, sending operation, the description still earns its keep: it spells out the exact recipient-resolution rule (Reply-To, else sender, else own recipients), states that a body is mandatory, discloses that the account signature is appended automatically and how to suppress it, and describes the opt-in refusal via expected_to. It also narrates the response fields that reveal which behavior actually occurred, which is exactly what an agent needs before an irreversible send.

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 front-loaded with the core action and recipient rule, then moves to the guard, the body requirement, and the signature caveat. Some detail, such as the multipart/alternative explanation, is slightly more than an agent needs to choose and call the tool, but nothing is redundant filler.

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 8-parameter send tool with no output schema, the description covers recipient logic, body requirement, signature handling, and even the shape of the response (To/Cc, reply_to_used, original_from, signature). The main gap is failure behavior beyond the expected_to refusal, such as what happens with an invalid or already-closed message_id.

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 100%, so the baseline is 3, but the description adds real meaning on top: it explains why reply_all can produce a different recipient set than the original sender, why signature: false also skips the lookup, and why expected_to exists (a Reply-To can name someone other than the visible sender). The multipart/alternative consequence for plain-text bodies is also surfaced, which is behavior rather than mere parameter restatement.

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?

"Reply to an existing email in its thread" gives a specific verb and resource, and the thread-based framing distinguishes it at a glance from gmail_send, gmail_create_draft and gmail_forward without needing the schema. The follow-on sentences about recipient resolution confirm it is the reply tool, not a generic message sender.

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 clearly separates the two modes of use: default single-party reply vs. reply_all: true for everyone else on the original, plus the expected_to guard for when the recipients matter. It never explicitly says when to reach for gmail_send or gmail_forward instead, but the thread-based framing makes the boundary reasonably clear.

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.