Skip to main content
Glama

Add storage

add_storage

Give a project an S3 bucket for files that users upload or download, such as photos or documents. Call it after the first deploy_project, with that project_id; the app restarts with the bucket's variables set (persisted like any env var, so they survive redeploys). The app needs a server (runtime node or python): for each upload the server signs a presigned PUT URL, and for each download a presigned GET URL, with its own key, and the browser sends or fetches the file straight to or from the bucket, never through the app. A static page cannot do this: it has no server to hold the key, and the key must never reach the browser. The app reads S3_ENDPOINT, S3_REGION, S3_BUCKET, S3_ACCESS_KEY_ID, and S3_SECRET_ACCESS_KEY (plus S3_PUBLIC_URL for a public bucket) with any S3 SDK. Pass the values to the S3 client explicitly: SDKs read the AWS_* names on their own, not these. Have the app start without these variables and say so until they are set. Private is the default and the right choice for user files. Pass public: true only for files meant for everyone, such as a public gallery's images: they are then readable by anyone at S3_PUBLIC_URL/, outside the project's gate, so a restricted project with a public bucket gets a warning to relay. Idempotent: calling it again returns the same bucket and changes nothing, public included (set_storage_visibility changes that). Refused if the user set any of those S3_* variables themselves. Each plan caps a project's bucket (Free 500 MiB, Pro 50 GiB, Business 100 GiB), measured once a day: past it the app's key can no longer upload (reads, listings, and deletes still work, and nothing is deleted) until the bucket is back under or its plan allows more, and get_project shows storage.read_only with a note to relay. The persistent data directory (SPAWNPOINT_DATA_DIR) needs no call and suits a SQLite file or files only the app reads; a bucket is for files browsers upload or download, or that must outlive the machine. The bucket and every file in it are deleted when the project is terminated.

Input Schema

NameRequiredDescriptionDefault
publicNofalse (the default): only the app's own key reads the bucket, and browsers get presigned URLs the app signs. true: anyone can read any object at S3_PUBLIC_URL/<key>, outside the gate; only for files meant for everyone, such as a public gallery
project_idYesthe id of the project

Output Schema

NameRequiredDescriptionDefault
envNo
noteYes
bucketNo
publicNo
statusYes
warningNo
read_onlyNo
project_idYes
public_urlNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior1/5

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

The description directly contradicts the idempotentHint=false annotation by saying 'Idempotent: calling it again returns the same bucket and changes nothing.' That is a serious annotation contradiction for an agent deciding whether retries are safe. Other behavioral details are rich, but the contradiction dominates this dimension.

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?

The description is long, but it is front-loaded with the core purpose and then organized around prerequisites, runtime behavior, public/private semantics, limits, and lifecycle. Most detail is justified for a complex storage-provisioning tool, though some implementation narrative is verbose.

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?

It covers prerequisites, env vars, server requirement, public/private behavior, plan caps, refusal cases, and termination cleanup, so it is broadly complete for this complex operation. The incorrect idempotency claim prevents a top score because it could mislead agent behavior.

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 both project_id and public well. The description adds operational guidance around public/private consequences, but it does not add much parameter semantics beyond what the schema already provides.

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 states a specific verb and resource: give a project an S3 bucket for user-uploaded/downloaded files. It also distinguishes the bucket from the persistent data directory and names related tools like deploy_project, get_project, and set_storage_visibility.

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?

It gives explicit timing (after the first deploy_project), prerequisites (server runtime node or python), exclusions (static page cannot do this), and alternatives (SPAWNPOINT_DATA_DIR needs no call). It also clearly states when to use public versus private storage and how visibility changes later.

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.