Skip to main content
Glama

Manage Attachments

attachments
Destructive

Binary attachments (images, PDFs, audio, video) referenced from event payloads and input_data via format: homespun-attachment-id. Actions: upload, fetch, presign, finalize, download, show, list, delete, mint_token, revoke_token, list_tokens.

Choosing an upload path matters for cost. An inline upload with content_base64 carries the bytes in the tool-call arguments, so they enter the model context at a token cost proportional to file size, paid again on every retry; a few-hundred-KB image is already expensive. Two paths avoid that entirely: fetch, when the bytes are reachable at a URL, and presign plus finalize, when the client can PUT the raw bytes out of band. Inline upload suits small assets and clients that have neither a URL nor an out-of-band PUT.

fetch takes { source_url (https), scope } and the relay downloads the URL itself behind an SSRF guard (https only, no private, loopback or metadata hosts, DNS pinned, redirects refused, size-capped and timed out), then runs the same byte-sniff, allowlist, size, quota and scan checks as any upload. It works on any storage backend. upload takes either content_base64 (base64 bytes, no filesystem) or file_path (an absolute path read on the relay host, so it only applies when the file is local to the relay). presign plus finalize is token-free: presign with { mime, size, sha256, scope } returns { put_url, attachment_id }, the caller PUTs the raw bytes to put_url over plain HTTP out of band, then finalize with the attachment_id. At finalize the relay re-reads the stored bytes, sniffs the real type, and enforces the same allowlist, size, sha256, quota and scan checks, so a presign that misstates its mime is caught and never served inline. The presigned path requires the Azure storage backend; a filesystem-backed relay returns a clear not-supported error and fetch or inline upload apply there instead. download writes to an absolute out_path or returns base64. An upload is scoped to agent (the default, reusable) or app. mint_token returns a /b/ capability URL, shown once, that a browser can GET without the caller's API key.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
mimeNoupload/presign: advisory Content-Type. The relay byte-sniffs the actual bytes and stores/serves that sniffed type regardless (a lying mime is caught, never served inline). Required for presign (scopes the upload URL + fails fast against the allowlist).
onceNomint_token: token self-deletes on first GET.
sizeNopresign: the exact byte length you will PUT. Committed at presign and re-verified against the uploaded bytes at finalize.
limitNolist page size (1..100).
scopeNoupload scope (default agent).
actionYesBinary attachment operations. The upload path affects token cost: `fetch` and presign plus finalize keep the bytes out of the model context entirely, while upload with `content_base64` carries them in the tool-call arguments at a cost proportional to file size, paid again on every retry. fetch takes { source_url, scope } and the relay downloads the bytes itself (https only, SSRF-guarded), running the same sniff, allowlist, size, quota and scan checks as any upload. upload takes `content_base64` (base64 bytes, no filesystem) or `file_path` (absolute, read on the relay host), scoped agent or app. presign plus finalize is three steps: presign with { mime, size, sha256, scope }, PUT the bytes to put_url out of band, then finalize, which re-sniffs and re-checks them. download fetches bytes by attachment_id to an absolute out_path or returns base64. show returns metadata only. list returns the agent's attachments. delete is a soft-delete. mint_token mints a /b/<token> capability URL, returned once. revoke_token and list_tokens manage those tokens.
app_idNoRequired when scope=app.
cursorNolist pagination cursor.
sha256Nopresign: the hex SHA-256 (64 chars) of the exact bytes you will PUT. Committed at presign and re-verified against the uploaded bytes at finalize.
filenameNoupload: display filename (defaults to the file's basename).
out_pathNodownload: absolute path to write the bytes to. If omitted, the bytes are returned base64-encoded in the result.
token_idNorevoke_token: the token id to revoke.
file_pathNoupload: absolute path to a file read on the server host running this MCP connector (the relay), not the calling agent's machine. It resolves only when the file is local to the relay (e.g. a locally-run CLI); a hosted or remote agent supplies the bytes as `content_base64` instead.
source_urlNofetch: an https URL the relay downloads server-side, so the bytes do not enter the model context and cost no tokens. SSRF-guarded: https only, no private, loopback, link-local or metadata hosts, DNS pinned, redirects refused, size-capped and timed out. The downloaded bytes run the same byte-sniff, allowlist, size, quota and scan checks as any upload. This and presign plus finalize are the zero-context paths for real images and media.
ttl_secondsNomint_token: per-token TTL (clamped by scope default).
attachment_idNoAttachment id. Required for download/show/delete/mint_token/revoke_token/list_tokens.
content_base64Noupload: the file bytes as base64, sent inline with no filesystem access. The base64 rides in the tool-call arguments and enters the model context, costing tokens proportional to file size; a few-hundred-KB image is already expensive, and the cost repeats on every retry. presign plus finalize avoids that for any real image or media whenever the client can do an out-of-band HTTP PUT, which leaves `content_base64` suited to small assets such as a tiny icon, and to clients that cannot PUT out of band. If both `content_base64` and `file_path` are given, `content_base64` wins. The relay sniffs the real type and enforces the same size, allowlist and quota checks as a file upload.

TDQS

A4.8/5.0
Behavior5/5

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

Adds substantial behavioral detail beyond annotations: SSRF guard specifics, byte-sniffing/re-check on finalize, soft-delete semantics, token shown once, cost implications of inline uploads. No contradiction with destructiveHint/readOnlyHint.

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?

Well-organized and front-loaded, but lengthy with some repetition (e.g., 'same byte-sniff, allowlist, size, quota and scan checks' appears multiple times). For a 17-param/11-action tool, the length is mostly justified; a tighter edit could remove redundancy.

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?

Covers all actions, cost model, SSRF constraints, backend requirements, token behavior, scoping, and upload path trade-offs. With no output schema, it still gives enough for correct invocation; missing auth details are not critical given annotations.

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% with detailed parameter descriptions, so baseline is 3. The main description adds orchestration-level meaning (presign/finalize flow, which params are required together, content_base64 cost), but relies heavily on the schema for individual parameter details.

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?

The description opens with 'Binary attachments...' and enumerates 11 actions, clearly identifying the resource and verbs (upload, fetch, presign, finalize, download, etc.). It distinguishes from sibling row/table tools by focusing on the attachment lifecycle.

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?

Explicitly contrasts upload paths with cost trade-offs: inline for small assets, fetch for URL-reachable bytes, presign+finalize for out-of-band PUTs, and notes Azure backend requirement. This is precise when-to-use guidance beyond a simple action list.

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.

TDQS

A4.1/5.0
Disambiguation4/5

Most tools are clearly distinct, with row operations (list, get, upsert, update, delete, restore) well separated. Some boundaries like apps vs deploy_app and credentials vs grants require careful reading, but descriptions resolve the overlap.

Naming Consistency2/5

Tool names mix resource nouns (apps, attachments, connections) with verb_noun actions (delete_row, deploy_app). Singular and plural forms are inconsistent, and there is no uniform pattern across the set.

Tool Count3/5

24 tools is on the heavy side, but the platform's breadth (app deployment, data, auth, community) justifies the count. Each tool has a distinct role, though the set slightly exceeds the typical well-scoped range.

Completeness4/5

The surface covers the full app lifecycle: deploy, manage, delete, row CRUD with restore, attachments, credentials, and community features. Minor gaps like no dedicated row search or outbound webhook management are workable via existing tools.