Skip to main content
Glama
nabheet

google-services-mcp

by nabheet
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Get email attachment

google_gmail_get_attachment

Download a Gmail attachment by message and attachment ID, returning text or base64 for binary files; save large attachments to a local path to avoid inline size limits.

Instructions

Download a single attachment by message ID and attachment ID. Text-like files are returned decoded as text; binary files as base64. Attachments that would produce an inline result over 6 MB are rejected — pass saveToPath to write the raw bytes to a local file instead. The limit is measured on the JSON-RPC frame, not the raw bytes.

Input Schema

NameRequiredDescriptionDefault
idYesMessage ID.
partIdNoStable part ID (from list_attachments); preferred over attachmentId for lookup.
accountNoAccount nickname to use.
maxBytesNoInline size limit in bytes (default 6 MB), measured on the JSON-RPC frame the client receives. Escaping can inflate a payload (base64 ~1.33x, NUL-heavy text ~7x). Ignored when saving to disk.
saveToPathNoLocal path to write the raw bytes to (returns savedTo and kind "saved" instead of an inline payload). Must be inside the save root: GOOGLE_MCP_SAVE_ROOT, default ~/Downloads.
attachmentIdYesAttachment ID (from list_attachments).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.95
    • addedInput schema / properties / maxBytes
      Added value: +{
+  "description": "Inline size limit in bytes (default 6 MB), measured on the JSON-RPC frame the client receives. Escaping can inflate a payload (base64 ~1.33x, NUL-heavy text ~7x). Ignored when saving to disk.",
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}
    • addedInput schema / properties / saveToPath
      Added value: +{
+  "description": "Local path to write the raw bytes to (returns savedTo and kind \"saved\" instead of an inline payload). Must be inside the save root: GOOGLE_MCP_SAVE_ROOT, default ~/Downloads.",
+  "type": "string"
+}
  2. Addedv0.1.30

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full load and does well: it discloses that oversized attachments are rejected, how the limit is measured (JSON-RPC frame, not raw bytes), and the escape hatch. It leaves the read-only nature and any permission/account requirements implicit.

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?

Three tight sentences, each earning its place: identification, return encoding, then the failure mode and its workaround. The size constraint arrives before the caveat about how it is measured.

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, and the description covers the inline return encoding (text vs base64) and the saved-path alternate mode, which is what an agent most needs. It stops short of describing the actual response envelope for the inline case.

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 description coverage is 100%, so the schema already documents id, partId, maxBytes, saveToPath, and account in detail. The description reinforces the saveToPath/maxBytes trade-off but adds no syntax or format information beyond what the schema states, making 3 the correct 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 and resource — 'Download a single attachment by message ID and attachment ID' — and immediately clarifies the decoding behavior for text vs binary. This cleanly separates it from its sibling google_gmail_list_attachments, which enumerates rather than fetches.

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 a genuine routing rule: attachments that would exceed 6 MB inline must instead be written via saveToPath. It does not, however, point the agent at google_gmail_list_attachments as the source of the required IDs, nor mention the partId preference noted in the schema.

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