Skip to main content
Glama

Fluxmail Cloud

Download attachment

download_attachment
Read-only

Get metadata and a resource link for one attachment. With inline, the result also includes the content. For a PDF, inline adds extracted text, and pages returns the text of a page range such as 201-400. The size limit is 10 MB.

Input Schema

NameRequiredDescriptionDefault
pagesNoPDF page or page range to read as text, such as 201-400
inlineNo
accountIdNoAccount to operate on. Optional when exactly one account is connected.
messageIdYes
attachmentIdYesOpaque attachment ID returned by message metadata

Output Schema

NameRequiredDescriptionDefault
dataYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "data": {
      +      "additionalProperties": true,
      +      "properties": {
      +        "filename": {
      +          "type": "string"
      +        },
      +        "id": {
      +          "type": "string"
      +        },
      +        "mimeType": {
      +          "type": "string"
      +        },
      +        "sizeBytes": {
      +          "type": "number"
      +        }
      +      },
      +      "required": [
      +        "id",
      +        "filename",
      +        "mimeType",
      +        "sizeBytes"
      +      ],
      +      "type": "object"
      +    }
      +  },
      +  "required": [
      +    "data"
      +  ],
      +  "type": "object"
      +}
  2. Changed3 schema fields changed
    • changedInput schema / properties / accountId / anyOf
      Previous value: -[
      -  {
      -    "minLength": 1,
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "maxLength": 512,
      +    "minLength": 1,
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • addedInput schema / properties / attachmentId / maxLength
      Added value: +512
    • addedInput schema / properties / messageId / maxLength
      Added value: +512
  3. Changed14 schema fields changed
    • changedInput schema / $schema
      Previous value: -"https://json-schema.org/draft/2020-12/schema"New value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / properties / accountId / anyOf
      Added value: +[
      +  {
      +    "minLength": 1,
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • addedInput schema / properties / accountId / description
      Added value: +"Account to operate on. Optional when exactly one account is connected."
    • removedInput schema / properties / accountId / maxLength
      Removed value: -512
    • removedInput schema / properties / accountId / minLength
      Removed value: -1
    • removedInput schema / properties / accountId / type
      Removed value: -"string"
    • addedInput schema / properties / attachmentId / description
      Added value: +"Opaque attachment ID returned by message metadata"
    • removedInput schema / properties / attachmentId / maxLength
      Removed value: -512
    • changedInput schema / properties / inline / type
      Previous value: -"boolean"New value: +[
      +  "boolean",
      +  "null"
      +]
    • removedInput schema / properties / messageId / maxLength
      Removed value: -512
    • addedInput schema / properties / pages / anyOf
      Added value: +[
      +  {
      +    "description": "PDF page or page range to read as text, such as 201-400",
      +    "pattern": "^[1-9]\\d{0,5}(-[1-9]\\d{0,5})?$",
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • addedInput schema / properties / pages / description
      Added value: +"PDF page or page range to read as text, such as 201-400"
    • removedInput schema / properties / pages / pattern
      Removed value: -"^[1-9]\\d{0,5}(-[1-9]\\d{0,5})?$"
    • removedInput schema / properties / pages / type
      Removed value: -"string"
  4. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  5. Changed1 schema field changed
    • addedInput schema / properties / pages
      Added value: +{
      +  "pattern": "^[1-9]\\d{0,5}(-[1-9]\\d{0,5})?$",
      +  "type": "string"
      +}
  6. Changed1 schema field changed
    • addedInput schema / properties / inline
      Added value: +{
      +  "type": "boolean"
      +}
  7. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive), so the description earns credit for adding real behavior: the default result is metadata plus a resource link, inline additionally returns content, PDFs get extracted text, and there is a hard 10 MB size limit. It stops short of saying what happens when the limit is exceeded or whether text extraction is lossy.

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?

Four short sentences, each carrying new information, with the core return shape front-loaded before the optional behaviors. No repetition of the tool name or title.

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?

An output schema exists, so return values need no further explanation; the description still summarizes what the agent gets. For a read-only tool with all safety signals present, the only meaningful gap is the failure mode above the size limit and any account-selection behavior.

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 only 60%, and the two undocumented-ish parameters are precisely the ones explained here: inline controls content inclusion, and pages takes a range like 201-400 for PDF text. That compensates well for the schema gap, though accountId is left to the schema.

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: retrieve metadata plus a resource link for a single attachment, keyed by message and attachment. It is clearly distinct from email/thread tools, though it never explicitly contrasts with get_email_body, which is the sibling an agent might confuse it with.

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 description implies when the extra behavior is wanted (use inline to get content, use pages to get a PDF text range), but there is no explicit guidance on when to choose this over get_email_body or get_email, and no prerequisites or exclusions are stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources