Skip to main content
Glama
Commonpost MCP for Thunderbird

Commonpost MCP for Thunderbird

Compose Mail

sendMail
Destructive

Compose and send emails in Thunderbird, with an optional filled-in review window before sending, plus drafts, dry-run checks, attachments, and CC/BCC support.

Instructions

Write a new email (replies: replyToMessage; forwards: forwardMessage; unsent: saveDraft). By default it opens a filled-in compose window for the user to review and send: the result (Compose window opened) does not mean sent. skipReview sends at once, only if the user turned off the default-on skipReview block; dryRun only checks.

Input Schema

NameRequiredDescriptionDefault
ccNoCC recipients (comma-separated)
toYesRecipient email address
bccNoBCC recipients (comma-separated)
bodyYesEmail body text
fromNoSender identity (email address or identity ID from listAccounts)
dryRunNoCheck only: report sender, recipients (with automatic Cc/Bcc), attachments and size, or the error; sends nothing
isHtmlNoThe body is HTML (default: false)
subjectYesEmail subject line
skipReviewNoSend without the compose window; refused while the skipReview block is on (default: false)
attachmentsNoAttachments: file paths (strings) or inline objects ({name, contentType, base64})

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.19.2
    • changedInput schema / properties / attachments / items / oneOf
      Previous value: -[
      -  {
      -    "description": "Absolute file path to attach",
      -    "type": "string"
      -  },
      -  {
      -    "additionalProperties": false,
      -    "anyOf": [
      -      {
      -        "required": [
      -          "base64"
      -        ],
      -        "type": "object"
      -      },
      -      {
      -        "required": [
      -          "content"
      -        ],
      -        "type": "object"
      -      }
      -    ],
      -    "properties": {
      -      "base64": {
      -        "contentEncoding": "base64",
      -        "description": "Base64-encoded file content",
      -        "minLength": 1,
      -        "type": "string"
      -      },
      -      "content": {
      -        "contentEncoding": "base64",
      -        "description": "Alias for base64 (accepted for backwards compatibility); base64 takes precedence when both are set",
      -        "minLength": 1,
      -        "type": "string"
      -      },
      -      "contentType": {
      -        "description": "MIME type, e.g. application/pdf",
      -        "type": "string"
      -      },
      -      "name": {
      -        "description": "Attachment filename",
      -        "minLength": 1,
      -        "type": "string"
      -      }
      -    },
      -    "required": [
      -      "name"
      -    ],
      -    "type": "object"
      -  }
      -]New value: +[
      +  {
      +    "description": "Absolute file path",
      +    "type": "string"
      +  },
      +  {
      +    "additionalProperties": false,
      +    "anyOf": [
      +      {
      +        "required": [
      +          "base64"
      +        ],
      +        "type": "object"
      +      },
      +      {
      +        "required": [
      +          "content"
      +        ],
      +        "type": "object"
      +      }
      +    ],
      +    "properties": {
      +      "base64": {
      +        "contentEncoding": "base64",
      +        "description": "File content, base64",
      +        "minLength": 1,
      +        "type": "string"
      +      },
      +      "content": {
      +        "contentEncoding": "base64",
      +        "description": "Old name of base64, which wins if both are set",
      +        "minLength": 1,
      +        "type": "string"
      +      },
      +      "contentType": {
      +        "description": "MIME type",
      +        "type": "string"
      +      },
      +      "name": {
      +        "description": "File name",
      +        "minLength": 1,
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "name"
      +    ],
      +    "type": "object"
      +  }
      +]
    • changedInput schema / properties / isHtml / description
      Previous value: -"Set to true if body contains HTML markup (default: false)"New value: +"The body is HTML (default: false)"
    • changedInput schema / properties / skipReview / description
      Previous value: -"Request direct sending without a compose window. Honored only when the user explicitly disables the default-on skipReview safety block (default: false)."New value: +"Send without the compose window; refused while the skipReview block is on (default: false)"
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and openWorldHint=true, but the description adds the critical operational trait: the default call opens a compose window and the result does NOT mean the mail was sent. It also discloses that skipReview is refused while the default-on block is active, which explains the destructive path's safeguard.

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 dense sentences, front-loaded with the action and the sibling routing, then the behavioral caveat, then the two override flags. Parenthetical sibling list is efficient rather than wasteful.

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 10-parameter, non-idempotent, outward-facing tool with no output schema, the description covers the safety-critical behavior and defaults well. It stops short of describing what a dryRun or skipReview call actually returns, though the schema's field docs partially fill that gap.

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 the baseline is 3; the description adds meaning by explaining how skipReview and dryRun interact with the default compose-window flow rather than restating their field docs. It does not add anything about attachments, cc/bcc, or isHtml beyond the schema.

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 ('Write a new email') and immediately routes the three adjacent intents to siblings (replyToMessage, forwardMessage, saveDraft). An agent can distinguish this from the other compose-family tools 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 alternative routing (replies/forwards/unsent to specific sibling tools) plus the condition for each mode: default compose-window flow, skipReview only when the user disabled the block, dryRun for check-only. This is the when/when-not guidance the dimension rewards.

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