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.7/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint=false, destructiveHint=true), the description discloses SSRF guards, soft-delete semantics, token shown-once behavior, byte-sniffing with mime misstatement being caught, and backend-specific error conditions. This adds substantial contextual detail without contradicting the annotations.

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?

Although long, the description is dense with essential information: cost model, security constraints, backend dependencies, and per-action behavior. It opens with the core resource, then moves to the most consequential decision (upload cost), and proceeds logically through each action—high signal density with no filler.

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 11 actions, 17 parameters, no output schema, and numerous operational constraints, the description covers all actions, key return shapes (put_url, base64, metadata-only), failure modes, and security safeguards. It is complete enough for an agent to correctly select and invoke any action.

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 every parameter has a highly detailed description, so the baseline of 3 applies. While the tool description reinforces critical choices like content_base64 vs file_path, it does not add meaning significantly beyond the schema's own strong explanations.

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 opening sentence identifies the resource (binary attachments) and the exact format they're referenced by, then enumerates all 11 actions. This clearly distinguishes the tool from sibling operations like row access or row manipulation.

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?

The description gives explicit decision guidance on upload path selection based on cost, with clear trade-offs among inline, fetch, and presign+finalize. It also states prerequisites (presign requires Azure, file_path requires relay-local file) and notes when fetch applies to any backend.

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.4/5.0
Disambiguation5/5

Each tool targets a distinct resource or action: row operations (get/list/upsert/update/delete/restore) are clearly separated, while apps, attachments, community, grants, ingest, members, publisher, review, and taste each cover a different domain. Even closely related actions like share_link_rotate and domain_set have clearly scoped descriptions, so an agent can reliably select the right tool.

Naming Consistency4/5

Tool names use two patterns: noun-like names for resource areas (apps, attachments, community, grants, ingest, members) and verb_noun names for row operations (upsert_row, delete_row, etc.). This deviation is predictable and readable, but it is not perfectly uniform, so a slight deduction applies.

Tool Count4/5

With 22 tools, the server is on the heavier side, but the breadth of the platform (app lifecycle, data storage, attachments, community, reviews, feedback, identity) justifies the count. Each tool represents a meaningful feature area with multiple internal actions, so none feels redundant.

Completeness5/5

The tool surface covers the full lifecycle for apps (create, read, update, delete), rows (create, read, update, delete, restore, list deleted), attachments, membership, grants, ingest, community, and reviews. Obvious gaps like rollback or version history are not core to the domain, and the presence of get_skill helps agents understand the workflow.

Resources