Skip to main content
Glama

upload_attachment

Stage a file to attach to an email sent with send_message (Gmail only) or to a message sent with send_chat_message (AccountHub chat: photos, videos, files). Intended for SMALL files — 数百KB目安: the base64 content passes through the model and costs tokens, so for anything larger prefer giving send_message a public URL via attachment_urls instead. Pass filename + content_base64 (mime_type is inferred from the extension if omitted); the returned upload_id goes into send_message's or send_chat_message's attachment_ids. For files too big for one call, chunk them: first call without upload_id creates the upload, then repeat with the same upload_id + append=true to concatenate (each chunk must be valid base64 by itself). Hard cap 5MB per upload; staged files expire after 24 hours.

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": {
      "filename": "<filename>",
      "content_base64": "<content_base64>"
    },
    "name": "upload_attachment"
  }
}

Input Schema

NameRequiredDescriptionDefault
appendNotrue = append this chunk to the existing upload_id instead of creating a new upload.
filenameYesFile name, e.g. "report.csv" (日本語名可).
mime_typeNoMIME type, e.g. "text/csv". Omit to infer from the filename extension.
upload_idNoFor chunked uploads: the id returned by the first call. Requires append=true.
content_base64YesThe file bytes, base64-encoded. Each chunk must be valid base64 on its own.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only declare destructiveHint=false and a title, so the description carries the load and does it well: 5MB hard cap, 24-hour expiry of staged files, token-cost warning, and the chunking protocol. It omits failure modes (invalid base64, expired upload_id behavior on append) and any permission/auth notes, which keeps it from a 5.

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?

Front-loaded with purpose and the small-file constraint, and almost every sentence carries operational information. Slightly dense and mixes in a Japanese phrase, plus some redundancy with schema text, but no filler sentences.

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?

Five-param mutation-ish staging tool with no output schema; the description compensates by explaining what is returned (upload_id), lifecycle (24h expiry, 5MB cap), and the multi-call chunking path. Nothing an agent needs to invoke it correctly is missing.

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 100%, so baseline is 3, but the description adds real linkage semantics the schema doesn't: the upload_id/append=true concatenation flow and how the returned upload_id feeds attachment_ids. It repeats the per-chunk-valid-base64 rule already in the schema, which limits it to 4 rather than 5.

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 ('stage a file to attach to an email') and names both downstream consumers (send_message Gmail only, send_chat_message AccountHub chat with media types). Multiple sibling 'upload'/'send' tools exist, and the description makes the staging-then-referencing relationship explicit, so an agent can tell it apart from upload_shared_project_file.

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?

Explicit when-to-use (small files, base64 through the model) and a concrete alternative ('prefer giving send_message a public URL via attachment_urls'). Also routes the caller forward by explaining that the returned upload_id goes into attachment_ids, which is the exact next step.

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