Skip to main content
Glama

Add an image

add_image

Copies an image or SVG into the project's assets folder and places it on a slide at specified coordinates and width, so visuals can be positioned precisely on the canvas.

Instructions

Copies an image or SVG file into the project's assets/ folder and places it on a slide (slide units: 1600 × 900, origin at the center).

Input Schema

NameRequiredDescriptionDefault
xNo
yNo
pathYesThe GlideDeck project file (.glide.json). Absolute, or relative to the server's folder; `.glide.json` is added when there is no extension.
stepNo
imageYesImage file (png, jpg, gif, webp, svg…).
widthNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations declare readOnlyHint=false and openWorldHint=false, so mutation is known. The description adds a non-obvious side effect — the source file is copied into assets/ — which is genuinely useful context beyond annotations. However, it omits what happens on filename collisions, whether the source must exist, and what is returned.

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?

One sentence, front-loaded with the core action and the coordinate reference appended where it is most needed. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no annotation detail on results, so the agent doesn't know what the call returns (element ID? asset path?) or how to reference the placed image later. The coordinate-system note helps, but gaps around `step`, `width`, and return value leave it only partially complete for a 6-parameter mutation tool.

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 coverage is only 33%, so the description must compensate. It usefully explains the coordinate system (1600×900, origin at center), which clarifies x/y semantics that the schema leaves bare, but says nothing about `width` (default 800), `step` (slide selection), or positional defaults for x/y.

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 full flow: 'Copies an image or SVG file into the project's assets/ folder and places it on a slide'. This distinguishes it from add_text/add_slide and tells the agent both the file operation and the placement outcome.

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

Usage Guidelines2/5

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

No guidance on when to use this versus update_elements, add_text, or other placement tools, and no prerequisites stated (e.g., that add_slide must exist first, or how `step` interacts with slide indices). Usage is only inferable from the name.

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