Thunderbird MCP

Overview Schema Source Related Servers Discussions Admin

Forward a message

mail_forward

Destructive

Forward an email as a reviewable draft or send it, choosing inline quoting or .eml attachment, with a covering note, recipients, and optional files.

Instructions

Forward a message. Saves a reviewable draft unless mode="send".

inline quotes the original in the body; attachment attaches it as a .eml, which preserves the headers a recipient may need. body is your covering note and goes above the forwarded text.

Input Schema

Name	Required	Default
`cc`	No
`to`	Yes
`bcc`	No
`body`	No
`mode`	No
`confirm`	No
`is_html`	No
`subject`	No
`forward_as`	No	inline
`message_id`	Yes
`attachments`	No
`identity_id`	No
`request_key`	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

B3.2/5.0

Behavior3/5

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

Adds real value beyond annotations by disclosing that a reviewable draft is created unless mode is "send", plus the header-preservation tradeoff of the .eml attachment form. However it never explains the `confirm` gate, why the tool is destructiveHint=true, or what `request_key` does for a non-idempotent 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?

Front-loads the action and its default-draft behavior, then uses the remaining two short groups for the inline/attachment and body semantics. Dense and waste-free; only the backtick-heavy formatting costs it slightly.

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?

An output schema exists so return values need no explanation, and the send-vs-draft behavior is covered. But for a 13-parameter destructive, non-idempotent tool, the missing treatment of `confirm` and `request_key` leaves the agent without the guardrails it needs before invoking a real send.

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 13 parameters, so the description must carry the load — but it only gives meaning to `mode`, `forward_as`, and `body`. Critical parameters such as `confirm`, `request_key`, `is_html`, `identity_id`, and `subject` are left completely undefined.

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?

States a specific verb and resource ("Forward a message") that is naturally distinguishable from siblings like mail_reply and mail_send. It does not explicitly name an alternative, so it stops short of a 5.

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?

The draft-by-default rule implies the safe workflow and the `mode="send"` escape hatch is stated, but there is no explicit when-to-use guidance versus mail_reply or mail_send, and no prerequisites or ordering advice.

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

Deploy Server