Skip to main content
Glama
privacyfence

PrivacyFence

Official
by privacyfence
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

gmail_download_attachment

Read-onlyIdempotent

Download a Gmail attachment's content by name. Save it to a specified directory on local installs, or receive it inline or via a link on organization-managed installs.

Instructions

Download a Gmail attachment's content. Identify the attachment by the name returned from gmail_list_message_attachments. Local install: saved to destination_dir (required, no default): pass ~/Downloads, or a path the user asked for, if they should find the file afterward, or your own scratch directory if it is only for you to read. Organization-managed install: destination_dir is ignored; a small attachment comes back inline in the result, a larger one as a one-time link the human opens in their own signed-in browser. Returns {path, name, size_bytes} for a file saved on a local install (a save through the file bridge returns {path, delivery} instead), the file content inline, or {delivery: 'link', name, size_bytes, download_url, expires_at, note}. Requires user approval.

Input Schema

NameRequiredDescriptionDefault
reasonYesOne sentence: why are you calling this tool right now?
message_idYesId of the Gmail message, from gmail_list_messages (its id field).
attachment_nameYesFile name of the attachment, exactly as gmail_list_message_attachments returns it in its name field; a name that matches none fails.
destination_dirYesLocal install only: where to save the attachment -- required, no default. On an organization-managed install it is ignored and nothing is saved to it; any value will do. Use ~/Downloads (or a path the user specified) if the user should find this file afterward; use your own working/scratch directory if it's only for you to read or process.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / attachment_name / description
      Added value: +"File name of the attachment, exactly as gmail_list_message_attachments returns it in its name field; a name that matches none fails."
    • addedInput schema / properties / message_id / description
      Added value: +"Id of the Gmail message, from gmail_list_messages (its id field)."
  2. First observedv5.3.0

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations by disclosing install-dependent behavior (local save vs org-managed inline/link delivery), the requirement of user approval, and two distinct return shapes including the file-bridge {path, delivery} case.

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?

Long but front-loaded: purpose, identity source, then per-install destination guidance and return shapes. Every clause carries information, though the destination_dir guidance partially duplicates the schema.

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?

With no output schema, the description fully compensates by enumerating the possible return payloads ({path,name,size_bytes}, inline content, {delivery:'link',...}) and noting the approval requirement, so an agent has everything needed to call and interpret it.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the destination_dir description in the schema is nearly identical to the prose here, so the description mostly restates structured data. The message_id/attachment_name semantics are also already in the schema, leaving little added meaning beyond the baseline.

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 a specific verb+resource ('Download a Gmail attachment's content') and immediately names the sibling (gmail_list_message_attachments) that supplies the identifier, so the agent can distinguish it from confluence_download_attachment and drive_download_file without opening schemas.

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?

Gives clear operational guidance: identify the attachment by the name from gmail_list_message_attachments, when to pass ~/Downloads vs a scratch dir, and that user approval is required. It stops short of explicit when-not-to-use or naming a preferred alternative path, but the 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