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; text and PDFs return as text, other files embed, or save to an allowed directory and get the path.

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

NameRequiredDescriptionDefault
uidYesuid from search_messages
partYespart id from get_message
folderNoDefault: Gmail All Mail, else INBOX
inlineNoEmbed the bytes instead of a link
accountYeslist_accounts id
save_toNostdio: folder in policy.attachment_dirs; returns the path

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.13.12
    • changedInput schema / properties / account / description
      Previous value: -"Account id from list_accounts"New value: +"list_accounts id"
    • changedInput schema / properties / folder / description
      Previous value: -"Folder/label path. Defaults to All Mail on Gmail, INBOX elsewhere."New value: +"Default: Gmail All Mail, else INBOX"
    • changedInput schema / properties / inline / description
      Previous value: -"Embed the binary content in the result instead of returning a link"New value: +"Embed the bytes instead of a link"
    • changedInput schema / properties / save_to / description
      Previous value: -"Claude Desktop / Claude Code only: directory inside policy.attachment_dirs to write the file into; the tool returns the path"New value: +"stdio: folder in policy.attachment_dirs; returns the path"
    • changedInput schema / properties / uid / description
      Previous value: -"uid from search_messages: a number on IMAP mailboxes, an id string on Outlook; pass it back exactly as returned"New value: +"uid from search_messages"
  2. 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"
  3. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

With readOnlyHint=false conveying the write aspect, the description still adds rich detail beyond annotations: exact size ceilings (2097152 in-chat, 26214400 to disk), content-type handling (text-like/PDF-with-text-layer vs embedded binary), the policy.attachment_dirs constraint, and that the result names the written path. This is substantive behavioral context.

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 dense but purposeful clauses on limits, format, and save behavior. Every sentence carries information, though the size figures and mode switching make it slightly dense to parse in one pass.

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?

No output schema exists, so the description carries the return-shape burden, and it does so by saying text-like/PDF return as text, others as binary, and save_to names the path. That covers the essentials; finer details like inline/link behavior in the result are left to the schema.

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, but the description adds real meaning for save_to (must be inside policy.attachment_dirs; result returns the path) and clarifies the size interaction between the two modes. It goes beyond the schema on the most consequential parameter.

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: 'Downloads one attachment'. An agent can tell what it does unambiguously. However, it never names or contrasts with siblings (e.g., get_message for part ids, upload_attachment as the inverse), so it stops short of full sibling differentiation.

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?

Explains the two modes clearly: default in-conversation retrieval vs. 'Pass save_to ... to write the file to disk instead'. The triggering condition for save_to is stated. It doesn't name alternative tools or exclusions, but the when-to-use context is strong.

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