Skip to main content
Glama

Upload Media Inline (Popcraft)

popcraft_media_upload_inline

Upload a SMALL local file (icon, thumbnail, screenshot, short audio clip) by sending its bytes as base64 in this call — the bytes travel over this MCP connection, so it needs NO access to any other host and no shell. Returns a media_id that is ready immediately — no popcraft_media_confirm step — to pass as a medias[].value for popcraft_generate_image / popcraft_generate_video / popcraft_generate_audio. NOT FOR VIDEO: the base64 payload goes in this tool's ARGUMENTS, so you must generate every character of it, and even a 1 MB file is roughly 1.4 million characters. Practical ceiling is a few hundred KB; the hard limit is 20 MB. For video, or any file you would not want to type out in full, use popcraft_media_upload and RUN one of the shell recipes it returns — that streams the file from disk and never puts the bytes in your context. Never tell the user to upload a file through the website instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesThe file bytes, base64-encoded. A full `data:<mime>;base64,...` URI is accepted too. Send the WHOLE file — a truncated payload is rejected, not silently stored.
sha256NoOptional hex sha256 of the raw (pre-base64) file bytes. Pass it and the server verifies the payload arrived intact — worth it for multi-MB video.
filenameYesOriginal filename, e.g. clip.mp4 — cosmetic only; the stored path is unique regardless
content_typeYesMIME type of the file, e.g. image/png, video/mp4, audio/mpeg. Accepted: jpeg/png/webp/gif images, mp4/webm/mov video, mp3/wav/ogg/aac/m4a audio, glb/fbx 3D — anything else is rejected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only state the mutation/idempotency profile; the description adds real behavioral context the annotations cannot convey: the bytes travel over MCP so no host/shell access is needed, the return `media_id` is immediately usable with no `popcraft_media_confirm` step, truncated payloads are rejected, and there is a practical ceiling (a few hundred KB) versus a hard 20 MB limit.

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?

Front-loads the core action and the returned `media_id`, then sequences mechanics, the video exclusion, and the redirect to the shell-based alternative. Despite its length, every sentence carries a distinct decision-relevant fact.

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 still explains the return value (`media_id` ready immediately, passable as `medias[].value` to the generate tools) and covers limits, integrity verification, and the fallback path. Nothing needed to call it correctly is missing.

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%, and the schema already documents base64 format, the `data:` URI alternative, sha256 verification, cosmetic filename, and the accepted MIME list, so the description's per-parameter contribution is minimal. The throughput/limit guidance is capacity-oriented rather than parameter syntax, so the baseline 3 holds.

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 and resource ('Upload a SMALL local file ... by sending its bytes as base64 in this call') and explicitly differentiates scope (small inline files) from the sibling `popcraft_media_upload` used for larger/video data. An agent can identify this tool's niche without opening another 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 explicit when-to-use (icons, thumbnails, screenshots, short audio), when-not-to-use ('NOT FOR VIDEO', any file you would not type out in full), and names the concrete alternative (`popcraft_media_upload` plus its shell recipes). The routing decision is fully specified.

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