Skip to main content
Glama

Stage an Artifact Asset

artifact-get_asset_upload_url

Step 1 of adding a LARGE asset (an image, font or media file) to an EXISTING artifact — anything over 256 KB, which is the most artifact-edit takes inline. Smaller files need no staging: send them to artifact-edit directly with encoding "base64".

Flow:

  1. Call this with the sessionId and the filename: it returns assetUploadId, uploadUrl and uploadFields.

  2. Upload the file with an HTTP POST of multipart/form-data to uploadUrl. Send EVERY key/value of uploadFields as a form field FIRST, then the file itself LAST, in a field named "file" — S3 ignores anything sent after the file part, so the order matters. Do not add a size or Content-Length field. Success is HTTP 204 with an empty body. With curl, uploadFields {"key": "abc", "policy": "xyz"} becomes: curl -X POST -F key=abc -F policy=xyz -F file=@/path/to/your-file.png

  3. Call artifact-edit with a "write" change carrying assetUploadId instead of content, and the path the file should live at. Put the code that references it in the SAME edit, so both land in one commit.

Rules: one file per id, single use, 30 minutes to redeem it, 32 MB max — S3 rejects a larger body at step 2. Files over 10 MB are stored through Git LFS automatically: the commit carries a small pointer and .gitattributes gains the matching filter line, with no extra steps on your side. uploadFields carry the signature that authorizes the upload; treat them as a secret. If your host cannot make an HTTP request, use artifact-edit with encoding "base64" for a file that fits inline, or artifact-get_git_token to push the file with git.

Returns: success, assetUploadId, uploadUrl, uploadFields, expiresAt, maxBytes, nextSteps.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filenameYesThe file you are uploading, e.g. "hero.png". Only its extension is read, to type the upload — the path the asset lands at is the one you pass to artifact-edit afterwards.
sessionIdYesThe artifact session id — the last path segment of the artifact URL (e.g. "mr25vsjppVtbMx" from https://app.agentgrid.io/artifacts/mr25vsjppVtbMx), or the id from artifact-create.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

The description goes far beyond the annotations. It discloses the multi-step flow, the exact S3 upload requirements (order of form fields, file last, no size/Content-Length field), the 204 success response, one-file-per-id, single-use, 30-minute expiry, 32 MB max, automatic Git LFS behavior for files over 10 MB, and the security note about uploadFields being a secret. This is exceptionally transparent about behavior and constraints.

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 dense but well-structured with clear sections (Flow, Rules, Returns). It front-loads the core purpose and the 256 KB threshold. It is longer than typical, but every sentence carries operational information an agent needs. The only minor issue is that the length could be slightly trimmed, but the structure keeps it navigable.

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?

For a tool with no output schema, the description fully compensates by listing the return fields (success, assetUploadId, uploadUrl, uploadFields, expiresAt, maxBytes, nextSteps). It also covers the complete workflow, error-prone details (S3 field order), constraints, and fallback paths. An agent has everything needed to invoke this tool and execute the subsequent upload correctly.

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 the schema already documents both parameters. The description adds meaningful context: it explains that only the filename's extension is read for typing the upload, and that the actual path is passed later to artifact-edit. It also clarifies sessionId's format and source. This adds value beyond the schema, though the schema already covers the basics.

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 clearly states the tool's purpose: 'Step 1 of adding a LARGE asset to an EXISTING artifact' and distinguishes it from the alternative artifact-edit for smaller files. It names the specific verb (stage/get upload URL) and resource (artifact asset), and the flow makes the tool's role unambiguous.

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 provides explicit when-to-use guidance: use for files over 256 KB, and explicitly says smaller files should go to artifact-edit directly. It also names alternatives (artifact-edit with base64, artifact-get_git_token) and gives a fallback for hosts that cannot make HTTP requests. This is comprehensive routing guidance.

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.