Skip to main content
Glama
kojott

mailmcp

by kojott
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Get attachment

get_attachment

Download an email attachment by account, UID, and part ID. Returns text or PDFs as text and other files as binary, or saves to disk when a directory is provided.

Instructions

Downloads one attachment (max 2097152 bytes into the conversation; with save_to up to 26214400 bytes to disk). Text-like types and PDFs with a text layer are returned as text, others as embedded binary. Pass save_to with a directory inside policy.attachment_dirs to write the file to disk instead; the result names the path.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uidYesuid from search_messages: a number on IMAP mailboxes, an id string on Outlook; pass it back exactly as returned
partYespart id from get_message
folderNoFolder/label path. Defaults to All Mail on Gmail, INBOX elsewhere.
inlineNoEmbed the binary content in the result instead of returning a link
accountYesAccount id from list_accounts
save_toNoClaude Desktop / Claude Code only: directory inside policy.attachment_dirs to write the file into; the tool returns the path

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.8.1
    • addedInput schema / properties / save_to
      Added value: +{
+  "description": "Claude Desktop / Claude Code only: directory inside policy.attachment_dirs to write the file into; the tool returns the path",
+  "type": "string"
+}
    • addedInput schema / properties / uid / description
      Added value: +"uid from search_messages: a number on IMAP mailboxes, an id string on Outlook; pass it back exactly as returned"
    • addedInput schema / properties / uid / maxLength
      Added value: +512
    • removedInput schema / properties / uid / maximum
      Removed value: -9007199254740991
    • addedInput schema / properties / uid / minLength
      Added value: +1
    • removedInput schema / properties / uid / minimum
      Removed value: -1
    • changedInput schema / properties / uid / type
      Previous value: -"integer"New value: +"string"
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

All annotations are false (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), so the description carries the full burden. It discloses size limits, the two modes (inline vs save_to), and text/binary return behavior. It does not mention error conditions or permission requirements, but it covers the main behavioral traits well.

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?

The description is two sentences, front-loaded with the primary action, and includes all essential details without redundancy. Every sentence contributes meaningful information, making it efficient and easy to parse.

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?

With 6 parameters and no output schema, the description explains the return behavior (text, embedded binary, or path when save_to is used) and the key size constraints. It does not explicitly address the 'inline' parameter or error conditions, but overall it covers the essential context an agent needs to call the tool correctly.

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. The description adds value beyond the schema by explaining size limits, the save_to effect (write to disk, returns path), and the text/binary distinction, which enriches the understanding of parameters like part and save_to.

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?

The description states a specific verb ('Downloads') and resource ('one attachment'), and immediately provides differentiating details: size limits, text vs. binary handling, and the save_to alternative. This clearly distinguishes it from sibling tools like upload_attachment and makes its scope unambiguous.

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 explains the tool's core function and provides conditional guidance: use save_to to write to disk instead of returning content. It does not explicitly name alternatives or exclusions, but the purpose is clear enough that an agent can infer when to use it. Slight deduction for lacking explicit 'when not to use' guidance.

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

Deploy Server

Other Tools