Skip to main content
Glama

AIGE

by ws.aige
OverviewDiscussionsAdmin

Put an Image on Deck Slides (free)

antix_attach_deck_image
DestructiveIdempotent

Put an image FILE from this conversation on named slides of a carousel deck, as their picture: an image the user uploaded, or one you made with your own image generation. FREE here — nothing is generated by this tool and no credits are used. The image is screened, stored with the deck and laid full-bleed under the slide's copy; the copy is recoloured to read on it. slideIds is REQUIRED (one image may go on several slides). A picture put on with this tool is replaced by another one freely; replacing PAID artwork needs confirmDropPaid:true, and only after the user asks for the replacement. Requires the current expectedVersion. For a good slide picture: the deck's shape (4:5 → 1080×1350), NO words, letters or logos in the image, and quiet, even areas where the copy sits. If the result's review says the copy is lost on the picture, call again with the same image and the shade it names. Returns the deck with its re-rendered previews.

Input Schema

NameRequiredDescriptionDefault
imageYesThe image file from this conversation: one the user uploaded, or one you generated with your own image tool.
shadeNoLay an even veil over the picture so the copy reads on it: 0.2–0.5 darkens (under light copy), −0.5 to −0.2 lightens (under dark copy). Use it when the result's review says the copy is lost on the picture, with the same image again.
deckIdYes
localeNo
slideIdsYesREQUIRED, explicit: the slides that get this picture. One image may go on several slides.
projectIdNo
accountHandleNo
confirmDropPaidNoMust be true to replace a picture a slide already holds (generated artwork or an attached image) — only after the user asks for the replacement.
expectedVersionYesREQUIRED: the deck version you last read. A stale value fails with DECK_CONFLICT before any work.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is partly covered. The description adds useful context beyond annotations: screening, full-bleed placement, copy recolouring, free versus paid replacement rules, expectedVersion conflict behavior, and retry shading with the same image. However, it does not fully explain the destructive scope of replacing existing slide artwork beyond the confirmDropPaid condition.

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 front-loaded with the core action and free status, then layers replacement rules and image-quality guidance. It is dense and useful, though long; a few clauses could be tightened without losing meaning.

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?

Although there is no output schema, the description explains that it returns the deck with re-rendered previews and tells the agent how to respond to a review that says the copy is lost. Combined with the replacement and version guidance, it is complete enough for correct invocation.

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 56%, so the description must help with several parameters. It adds important meaning for slideIds, expectedVersion, shade, confirmDropPaid, and the image source, but does not explain deckId, projectId, locale, or accountHandle.

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: putting an image file from the conversation onto named slides of a carousel deck. It also distinguishes the operation from generation-based siblings by saying nothing is generated and no credits are used, so an agent can separate it from antix_generate_deck_slide_images or antix_set_slide_picture.

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 conditions: the image must be one the user uploaded or one the agent generated separately. It also specifies replacement rules, the requirement to ask the user before replacing paid artwork, and the retry path when the review says the copy is lost.

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

All AIGE toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources