Skip to main content
Glama

save_mail_attachment

Save one email attachment to an approved local folder without overwriting existing files. Fetches the message when needed and reports failures instead of leaving empty files.

Instructions

Save ONE attachment to disk (Automation, plus Full Disk Access to resolve a bare message_id).

List them with mail_attachments first, then address one by name or — when several on the same message share a name, which is ordinary — by its attachment_id (the id field on the attachment row). An ambiguous name RAISES and lists the ids rather than picking one.

dest_dir must be inside the allowed root (~/Downloads by default; MACOS_APPS_FILE_ROOT moves it) and is created if needed; a path outside it is REFUSED. The filename is DERIVED from the attachment's name — an attachment name comes from whoever sent the mail, so it is treated as hostile — and an existing file is never overwritten. Writes are capped at 25 MiB.

mailbox is optional: the folder value from the read that produced message_id, verbatim. Omitted, the id resolves on its own through the index.

Saving an attachment Mail has not downloaded makes Mail FETCH the message first, so this can take much longer than a read; if the account is offline the file lands empty, and it is then removed and reported as a failure rather than left behind. Returns {saved, name, original_name, bytes, reported_size, was_downloaded, id, folder}. Additive: writes a new file, never modifies mail.

Input Schema

NameRequiredDescriptionDefault
nameNo
mailboxNo
dest_dirYes
message_idYes
attachment_idNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.15.1

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare `readOnlyHint=false` and `destructiveHint=false`; the description adds substantial behavioral context: Full Disk Access requirements, allowed `dest_dir` root and refusal outside it, filename sanitisation, no overwrite, 25 MiB cap, Mail fetch delays, and offline cleanup. These details go well beyond the annotations and align with `destructiveHint=false` via the additive-write note.

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 dense but front-loaded: it leads with the action, then addressing, filesystem security, mailbox behavior, fetch caveats, and return fields. Every paragraph provides operational value without filler, which is appropriate for a security-sensitive filesystem write.

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?

Given the mutation, sensitive filesystem effects, missing schema parameter descriptions, and available output schema, the description is complete. It covers permissions, path security, collision policy, size limits, failure handling, and return shape, leaving no material gap for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/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 carry parameter meaning—and it does. It defines `name` versus `attachment_id` disambiguation, `dest_dir` root restrictions and creation behavior, `mailbox` as the verbatim folder from the read, and how `message_id` resolves through the index when mailbox is omitted.

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 'Save ONE attachment to disk'—a specific verb and resource—and immediately distinguishes the tool from sibling `mail_attachments` by telling the agent to list attachments first. The capitalised ONE and two addressing methods make the scope precise.

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?

Gives an explicit workflow: list with `mail_attachments` first, then address one attachment by `name` or `attachment_id`. It also explains the ambiguous-name failure mode and when `mailbox` is needed, so the agent knows how to select and invoke it correctly.

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