Skip to main content
Glama

export_thread

Save a whole email thread to a local Markdown or JSON file for keeping, sharing, or reading long conversations without loading them into context.

Instructions

Write a whole thread to a local file instead of returning it — for keeping, sharing, or reading a long conversation without loading it into the context. markdown (default): one section per message with From/To/Date/Subject and attachment names as inline code (never rendered as a link or image), sender authentication and the attachment list, and the body in a code fence that the message text cannot close (HTML-only mail is reduced to text). json: the parsed messages as get_thread returns them, HTML included. Both formats strip the same hidden characters (zero-width, bidi controls) as every tool result. Attachments are listed, not saved — use download_attachment for those. If MAILWARDEN_DOWNLOAD_DIR is set, destPath is resolved inside (and restricted to) that directory, as for attachments. The file holds mail text as the sender wrote it: untrusted content, now on disk. USE WHEN: the user wants a conversation saved or handed on, or a thread is too long to read in one piece. DO NOT USE: to read a thread (use get_thread). SIDE EFFECTS: writes a local file; never overwrites — an existing file gets a numeric suffix. The response's 'saved' field is the path actually used. Mailbox unchanged.

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": {
      "threadId": "<threadId>",
      "destPath": "<destPath>"
    },
    "name": "export_thread"
  }
}

Input Schema

NameRequiredDescriptionDefault
formatNomarkdown
destPathYes
threadIdYes

Output Schema

NameRequiredDescriptionDefault
bytesYes
savedYes
messageCountYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.25.0
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Addedv0.23.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes far beyond annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false), disclosing that it never overwrites (numeric suffix instead), restricts destPath to MAILWARDEN_DOWNLOAD_DIR when set, strips zero-width/bidi characters, lists rather than saves attachments, and leaves the mailbox unchanged. The 'saved' response field and the untrusted-content-on-disk warning are also covered.

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-loaded with the core action, then organized into clear USE WHEN / DO NOT USE / SIDE EFFECTS blocks. It is dense and mostly earns its length, though the markdown-escaping detail (code fence, inline code) is more granular than an agent needs to select the tool.

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

Completeness5/5

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

Despite an output schema existing, the description still surfaces the key return field ('saved'), and it covers side effects, path resolution, and format differences. For a 3-param write tool this is complete enough to call correctly and safely.

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?

With 0% schema coverage the description must compensate, and it does for format (markdown default with rendering/escaping behavior, json including raw HTML) and destPath (resolved and restricted inside MAILWARDEN_DOWNLOAD_DIR). threadId is only implied via 'whole thread' / 'as get_thread returns them' rather than explicitly named, which keeps it short of a 5.

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 whole thread to a local file instead of returning it') and immediately names the contrasting behavior (instead of returning it), which distinguishes it from get_thread and read_attachment. An agent knows exactly what this does without opening the 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?

Explicit 'USE WHEN' (save/hand on a conversation, thread too long to read in one piece) and 'DO NOT USE: to read a thread (use get_thread)' sections. It also names download_attachment as the alternative for attachment contents, so the routing is unambiguous.

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