Skip to main content
Glama

Roastify Add Design Element

roastify_add_design_element

Add a new element (text or image) to a design and commit a new version of it.

The store is configuration management: the element is committed back to the SAME design_id (git tracks the diff). The new element's id comes back, so you can immediately edit a text element by id with update_design_text, or move/reorder either kind with move_elements. Placement is validated server-side and REFUSED, not warned: the element must fall inside the named panel (with a default margin — the dieline carries no real safe area) — or, when the product has no panels (Tubes / continuous wrap), inside the design sheet — and must not overlap any existing element (the collider's id is named). Typography is inherited for text, so a new text element matches the template. Image creation reuses a src already present in the design (no new asset upload) — pass kind="image" with src_from (an existing image id) or src that already appears on an image.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
srcNoAn image src already present in this design (kind="image"); alternative to src_from. New uploads are refused — only reuse an asset already on the design.
faceNoThe panel to place it on — one of the `panels` from get_design_text (e.g. "right"). On multi-panel boxes the element must fall inside that panel; face is required there. On single-face products (Tubes: `panels` is empty) any face is accepted and containment uses the design's sheet bounds instead.
kindNo"text" (default) or "image".text
npubNoRequired. Your Nostr public key (npub1...) for credit billing.
textNoThe element's text (\n for line breaks). Required when kind="text".
labelNoRename the design (optional). Defaults to keeping its current label.
widthNoThe text box (wrap) width, or the image frame width, in design units. Defaults to the panel width minus margins for text; required for images when not defaulting from the donor.
heightNoImage frame height in design units (kind="image" only). Defaults to the donor image's height when src_from is set.
positionNoWhere to place it. Either absolute {"x": N, "y": M} (top-left in design units), or relative to an existing element: {"below"|"above"|"rightOf"|"leftOf": "layer_id", "gap": G}. Relative is best when there's a sibling to anchor to; an empty panel needs absolute.
src_fromNoExisting IMAGE element id whose src to copy (kind="image").
design_idYesThe design to add to, from roastify_list_designs.
dpop_tokenNo
style_fromNoAn existing TEXT layer id (from get_design_text) whose font, size, weight, colour, alignment, and leading the new text element inherits. Required when kind="text".
version_tagNoThe NEXT semver version (MAJOR.MINOR.PATCH, e.g. 1.3.0, no 'v') — call roastify_list_design_versions and increment. Required; reusing one is refused.
client_req_idNoYour idempotency key.
commit_messageNoA specific description of WHAT changed and WHY — a real commit message, not a placeholder like 'save this' or 'update'. Required.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full disclosure burden, and it does well: it explains git-tracked version commits, server-side refusal on invalid placement, overlap collision behavior, typography inheritance, and the no-new-upload rule for images. The phrase 'Typography is inherited for text, so a new text element matches the template' is slightly ambiguous because style_from is described as required for text in the schema.

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 dense but well organized: purpose first, then versioning, then placement rules, then text/image-specific behavior. Every sentence adds useful operational detail, and the length is justified for a complex 16-parameter mutation tool with no annotations.

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

Completeness4/5

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

For a tool this complex and with no annotations, the description covers the essential invocation context: versioning, related tools, placement constraints, panel/sheet behavior, and asset reuse rules. An output schema exists so return-value details are covered, but the ambiguity around style_from vs 'template' keeps it from being fully complete.

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 high at 94%, so the baseline is 3, and the description adds meaningful operational context beyond the schema: same design_id commitment, kind-specific src/src_from reuse, server-side placement validation, and no-upload enforcement. It does not add much about dpop_token, but that is a minor gap given the schema's high coverage.

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 opens with a specific verb and resource: 'Add a new element (text or image) to a design and commit a new version of it.' It clearly identifies the operation, the target design, and the versioning side effect, and it is easy to distinguish from siblings like update_design_text and move_elements.

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?

The description gives practical sequencing guidance by naming update_design_text and move_elements as the follow-up tools after the new element is created. It also explains when sheet-based placement applies vs panel-based placement, though it does not explicitly state 'use this when adding, not when editing' as a direct exclusion.

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.