Skip to main content
Glama

store_artifact

Idempotent

Upload a file as an artifact, either via base64 content (up to 10 MB) or local path (up to 500 MB), with metadata tagging for later retrieval.

Instructions

Upload a file as a new artifact in a single call. Provide EITHER up to ~10 MB of base64-encoded bytes via content, OR a local filesystem path that the MCP server reads and streams as multipart/form-data (up to 500 MB). For files larger than 500 MB, use request_upload_url (Pro only) instead — store_artifact returns file_too_large for them. Tags the artifact with session_id / agent_id / metadata for later retrieval and returns the full artifact record including its new artifact_id and content_hash.

Path uploads are confined. The path argument is constrained to the launcher-configured allow-list (default: the MCP server's CWD). Paths outside the allow-list, paths traversing symlinks out of it, and paths to known-sensitive locations (~/.ssh, ~/.aws, /etc/, etc.) are refused with invalid_request.

For crash-safe retries, supply your own idempotency_key (any string ≤256 chars): a replay within 24h returns the original artifact and never double-bills. If you omit it, the server auto-generates one and returns it under _meta.idempotency_key, but that key protects only in-process retries within a single call — it is lost if the server restarts, so pre-commit your own key when durability matters.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filenameYes
contentNoBase64-encoded bytes. Use for content under 10 MB or when no local path is available.
pathNoAbsolute local path inside the launcher-configured allow-list. The MCP server reads and streams this as multipart. Mutually exclusive with `content`. Paths outside the allow-list are refused.
content_typeNoMIME type. If omitted, guessed from filename.
session_idNo
agent_idNo
metadataNo
ttlNoDuration suffix (e.g. `7d`, `30d`) or `never` (Pro only). Defaults to plan default.
idempotency_keyNo
Behavior5/5

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

Beyond annotations (idempotentHint=true, readOnlyHint=false), description details idempotency guarantees, return value (full artifact record with artifact_id and content_hash), tagging behavior, and path confinement rules including sensitive locations refused. No contradiction with annotations.

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 well-structured and front-loaded with purpose, then modes, limits, alternatives, return info, constraints, and idempotency. Each sentence adds value, though slightly verbose; could be more concise but effective.

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?

Despite no output schema, the description explains the return value (full artifact record with artifact_id and content_hash). It covers all essential aspects: input modes, size limits, path constraints, idempotency, tagging, and error conditions. Complete for an upload tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 44% schema description coverage, the description compensates by clarifying size limits, streaming behavior, path restrictions, idempotency mechanics, and tagging. It adds significant meaning beyond the schema, especially for content, path, and idempotency_key.

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 'Upload a file as a new artifact in a single call' and specifies two distinct input modes (base64 content or local path). It distinguishes from siblings like list_artifacts and get_artifact by being the upload tool.

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 provides when-to-use guidance: recommends request_upload_url for files >500 MB, describes path allow-list constraints, and explains idempotency_key usage for crash-safe retries. Also notes conditions that cause errors (file_too_large, invalid_request).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SagaPeak/artifacta-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server