MCP Aruba Email & Calendar Server

Overview Schema Source Related Servers Discussions Admin

download_attachment

Downloads a specific email attachment by email ID and attachment index, returning its filename, content type, size, and base64-encoded data for saving or processing.

Instructions

Download a specific attachment from an email.

Args: email_id: Email ID attachment_index: Index of attachment (from get_email_attachments, starting at 0) folder: Mail folder (default: INBOX)

Returns: Dictionary with filename, content_type, size, and data_base64 (base64 encoded content)

Example: download_attachment(email_id="123", attachment_index=0)

Note: The attachment content is returned as base64 encoded string in 'data_base64' field. You can decode it and save to file.

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": {
      "email_id": "<email_id>",
      "attachment_index": "<attachment_index>"
    },
    "name": "download_attachment"
  }
}

Input Schema

Name	Required	Default
`folder`	No	INBOX
`email_id`	Yes
`attachment_index`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.1Nov 9, 2026

TDQS

A3.7/5.0

Behavior4/5

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

No annotations are supplied, so the description carries the full burden and mostly meets it: it discloses the return dictionary keys, states that content comes back as a base64 string in data_base64, and tells the agent it must decode and persist it itself. That is exactly the kind of non-obvious behavior an agent needs. It stops short of covering failure modes such as invalid index or missing attachment.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with a clear one-line purpose and the example is genuinely useful. However, the Args block restates parameter names already in the schema and the closing Note repeats the base64 point already made in Returns, so a meaningful fraction of the text is redundant.

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 the Returns section is a bonus rather than a necessity, and the base64 decode instruction fills the one semantic gap a schema cannot. Given three parameters and no annotations, the definition covers what an agent needs to call it correctly, with the main omission being failure behavior and sibling differentiation.

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 0%, so the description must compensate, and it largely does: attachment_index is explained as a 0-based index sourced from get_email_attachments, and folder is given its default of INBOX. Only email_id is left as a bare restatement ('Email ID'), which is the one weak spot.

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: download a single attachment from a specific email. The verb 'download' plus the attachment_index parameter makes it distinct from get_email_attachments (which enumerates) and save_attachment (which presumably writes to disk), though the description never names those siblings to make the contrast explicit.

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?

Usage is implied rather than stated: the attachment_index note points the agent to call get_email_attachments first and use a 0-based index, which is a genuine workflow hint. However, there is no guidance on when to prefer this tool over save_attachment or get_raw_email, and no mention of what happens when the index is out of range.

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