Thunderbird MCP

Overview Schema Source Related Servers Discussions Admin

Reply to a message

mail_reply

Destructive

Draft or send replies to email messages, deriving recipients, subject, and quoted original; drafts remain reviewable unless sent.

Instructions

Reply to a message. Saves a reviewable draft unless mode="send".

Thunderbird derives the recipients, the subject and the quoted original; body goes above the quote. reply_all copies everyone, reply_to_list answers the mailing list. Passing cc replaces the addresses Thunderbird derived, so leave it unset unless that is the intent.

Input Schema

Name	Required	Description	Default
`cc`	No
`bcc`	No
`body`	Yes
`mode`	No
`confirm`	No
`is_html`	No
`subject`	No
`reply_all`	No
`message_id`	Yes
`attachments`	No
`identity_id`	No
`request_key`	No
`reply_to_list`	No
`quote_original`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.4.0Nov 2, 2026

addedInput schema / properties / request_key

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Request Key"
+}

First observedv0.1.0Jul 29, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations flag destructiveHint and openWorld, and the description adds real value beyond them: what Thunderbird auto-derives (recipients, subject, quote), where body lands relative to the quote, and the fact that supplying cc *replaces* derived addresses — a genuine footgun. It does not mention the irreversible nature of mode="send" or the role of confirm, which matters for a destructive-hinted tool.

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 dense sentences, front-loaded with the default behavior and the safety-relevant cc warning. No filler, though the semantic relationships between reply_all, reply_to_list and cc could be grouped more tightly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists so return values needn't be explained, and the reply semantics are well covered. But for a 14-parameter, destructive-hinted mutation tool with zero schema descriptions, leaving confirm, attachments and the required message_id unexplained is a visible gap.

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

Parameters2/5

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

Schema description coverage is 0% across 14 parameters, so the description must carry the load, yet it explains only mode, body, cc, reply_all, reply_to_list and implicitly quote_original. Required message_id, plus subject, bcc, is_html, attachments, identity_id, request_key and especially confirm are left entirely undefined.

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 and resource (reply to a message) and immediately discloses the defining behavior — a reviewable draft is created unless mode="send". That default distinguishes it from mail_send, mail_draft_save and mail_forward without the agent needing to compare schemas.

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 default-draft versus mode="send" split gives clear guidance on which variant of the operation to pick, and the cc caveat explicitly says when not to pass a parameter. It stops short of naming sibling alternatives (mail_forward, mail_compose_open) or stating prerequisites such as the message needing to exist.

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

Deploy Server