Skip to main content
Glama

upload_file

Upload a file into the platform project's own files entity. Works over any transport (local stdio or the hosted mcp.aaly.io endpoint) — no local filesystem access required. Platform-project only — for uploading into an end-customer's own project, call that project's own REST API (POST /files/presigned-url, then POST /files) directly, the same way the generated app does; this tool does not do that.

Three ways to use it, in order of preference:

  1. Pass content_base64 (the file's bytes, base64-encoded) with filename and mime_type — this tool uploads and registers it in one call. Keep it under 8MB for this mode; base64 in a single tool-call argument gets unreliable well before that.

  2. If you can perform your own HTTP request (e.g. a sandboxed curl/fetch capability) and the file is larger: call with filename, mime_type, and size only (no content_base64, no s3_key) to get back a presigned upload URL — POST the file directly to it yourself (uploadFields as form fields, the file's bytes as the LAST field, named 'file'), then call this tool again with s3_key set to the returned value (plus the same filename/mime_type/size) to register the record.

  3. If neither is possible in your environment, don't force it — tell the user to upload the file directly through the AALY platform app instead.

100MB cap either way (enforced server-side at the presign step).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sizeNoFile size in bytes. Required for modes 2 and 3 above; derived automatically from content_base64 in mode 1.
s3_keyNoThe s3Key from a prior mint-only call (mode 2), after you've uploaded the bytes yourself — registers the record (mode 3).
filenameYesFilename to store.
mime_typeNoMIME type of the file. Defaults to application/octet-stream.
content_base64NoThe file's bytes, base64-encoded (mode 1) — this tool uploads and registers it in one call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the generic safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=false). The description adds far more: a 100MB server-enforced cap, an ~8MB practical ceiling on base64 args, a transport-agnostic guarantee (no local FS needed), and the two-phase presign-then-register flow with the exact form-field naming rule ('file' last). This is well beyond what structured fields provide.

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-loads the purpose and the scope exclusion before the numbered modes, and every sentence carries load (caps, ordering, field naming). The three-mode block plus the 100MB trailer is fairly long, but the complexity of the call genuinely warrants it; only mild tightening is possible.

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 compensates by describing what mode 2 returns (presigned URL plus uploadFields and the s3_key to feed back), and it closes the loop on error handling by telling the agent what to do when no mode is viable. Nothing needed to call this 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, and the schema descriptions already map each parameter to its mode. The description adds orchestration semantics the schema cannot express — that size is derived automatically in mode 1 but required in modes 2/3, and that s3_key comes from a prior mint-only call — which lifts it above baseline without being strictly necessary.

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 (upload) and resource (file into the project's own `files` entity), and immediately delimits scope: platform-project only, not an end-customer's project. It names the sibling behavior an agent might otherwise assume (calling a project's REST API) and rules it out, so it is distinguishable without opening any schema.

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?

Gives three ranked usage modes with explicit selection conditions (small file → content_base64; large file + own HTTP capability → mint presigned URL then register with s3_key; neither → defer to the app UI), plus an explicit when-NOT (end-customer projects). No inference is left to the agent.

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