Skip to main content
Glama

image_add

DestructiveIdempotent

Add a still image—photo, logo, or sticker—from common formats into the project, with EXIF rotation applied so it displays upright, and use it in cues or as an overlay.

Instructions

Add a still image to the project: a photo, a logo, a cut-out sticker.

It lands upright (a phone photo's EXIF rotation applied) in a format the render and the window both read. Then show it full frame with cue_add(asset="image:"), or place it over the film as a sticker with overlay_add(image=name, x=, y=, width=, rotate=, style="photo").

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoWhat to call it; `image:<name>` is how a cue names it. Unset, from the filename.
pathNoThe project directory to act on. Omit it — the usual case — when this server is bound to a project (started as `proofcut -C DIR mcp`, or inside a project; `ping` says which): it then resolves to that one bound project, a relative path resolves against it, and a path outside it is refused by name. Unbound, `path` is the whole address and omitting it refuses rather than guessing.
sourceYesThe image file: PNG, JPEG, WebP, HEIC, GIF (its first frame), AVIF, TIFF or BMP. list_media lists the ones in a folder under `images`.
replaceNoReplace an image of this name. Unset, a taken name is refused.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.43.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already signal destructive/idempotent behavior, so the description's added value is contextual: it discloses that EXIF rotation is applied and that the image lands in a format readable by both render and window. This is genuine behavioral information beyond the structured annotations.

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?

The description is well-structured and front-loaded, starting with the core action, then adding behavioral detail and downstream usage. Every sentence earns its place; there is no padding or repetition of schema fields.

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?

Given full parameter schema coverage, output schema presence, and annotations for safety/idempotency, the description is complete enough for correct invocation. It also includes downstream composition guidance, leaving no critical gap for an agent to act on.

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 baseline is 3, but the description adds meaning beyond the schema: it explains that a cue names the asset as image:<name> and gives the overlay_add signature for placing the image over film. This helps an agent compose correct follow-up calls.

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 names a specific action and resource: add a still image to the project, with concrete examples (photo, logo, sticker). It is clearly distinct from sibling tools like image_ls, image_rm, and graphic_* by focusing on adding image assets, and it immediately connects to how the image is used downstream.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear context for when to use the tool (adding a still image) and explicitly shows the next steps with cue_add and overlay_add. It does not name exclusion cases or alternatives like import_media or graphic_new, so it stops short of full when-not guidance.

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

Deploy Server

Other Tools