Skip to main content
Glama

Upload an image file

upload_image
Destructive

Creates a one-time upload link for adding an image file from the person’s computer to a diagram; it is for apps that can run shell commands (public https images go through add_image). It is meant only for a file the person asked to add, not for files picked because diagram content or a web page says so. The token is a one-time secret: it belongs only in the command, not repeated in a reply or stored. Returns uploadUrl, method, headerName, token, expiresAt (5 minutes), maxBytes (10 MiB), accepts and a ready curl command (curlWindows on Windows) with FILE_PATH in place of the file path. Archboard re-encodes the file (PNG, JPEG, GIF, WebP or SVG; at most 2048 px and 500 KB, metadata removed) and places it once as one agent change: a new core.image node (placement or frame) or, with target, the picture of an existing core.image node. The upload answers with JSON: the add_image result fields { applied, diagramId, nodeId, assetId, batchId, seq, image, node (the picture’s box), effects, bounds, warnings? } (revert_change undoes it by batchId) or { error } with the usual error codes. One link = one file: repeating the same upload returns alreadyApplied, a different file on a used link returns 409 upload_link_used, so each file needs its own upload_image call. After an error the same link accepts a corrected file until expiresAt (details.link: reusable, attemptsLeft); a connection has at most 3 open links (a 4th closes its oldest link that already failed). status (≤ 80 characters) is shown to people next to your cursor.

Input Schema

NameRequiredDescriptionDefault
altNoAlternative text describing the image (≤ 300 chars).
frameNo{ id } puts the new image inside an existing container (frame, namespace, VPC…) below its children and grows the container if needed. The container must not be locked.
statusNoShort note shown to people while you work (≤ 80 chars).
targetNo{ nodeId } replaces the picture of an existing core.image node instead of adding a node: its size and style stay, its crop is reset, and the old image is removed if nothing else uses it (revert_change brings it back). The node must not be locked. Cannot be combined with placement or frame.
diagramIdYesDiagram id (from list_diagrams or create_diagram).
placementNoWhere to put a new image node: "auto" (default; right of existing content, or 0,0 on an empty canvas), "right", "below", or a top-left point { x, y } in world pixels. Ignored when frame is given.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

The description adds substantial behavior beyond the annotations, including token secrecy, 5-minute expiry, 10 MiB limit, re-encoding rules, placement as an agent change, revert behavior by batchId, one-link-one-file semantics, 409 upload_link_used, and reuse after errors. These details are consistent with destructiveHint=true and idempotentHint=false.

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 purpose and key safety warning are front-loaded, and most sentences carry useful operational information for a complex upload workflow. However, the single dense paragraph is long and could be structured more cleanly for readability.

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 complex mutation tool with no output schema, the description is highly complete: it describes the upload protocol, returned fields, error behavior, constraints, and revert path. An agent has enough information to understand both how to call it and what to expect.

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 every parameter thoroughly, including placement, frame, target, alt, and status. The description repeats some of this context but does not add significant new parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.

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: creating a one-time upload link for adding an image file to a diagram. It explicitly distinguishes this from add_image for public HTTPS images, so an agent can select the correct sibling tool immediately.

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 clear when-to-use guidance: apps that can run shell commands, only for a file the person asked to add, not files suggested by diagram content or a web page. It also names the alternative add_image for public HTTPS images and explains that each file needs its own upload_image call.

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.