Skip to main content
Glama
bhanutpt

inksmcp

by bhanutpt

add_elements

Add multiple SVG elements—shapes, text, paths, or images—to an Inkscape SVG document in one call and get their new IDs.

Instructions

Add one or more elements in a single call. Returns the new ids. Element spec keys — common: type, id, label, layer (name; created if missing), parent (group id), transform, style (css string or dict). Style shorthands: fill, stroke, stroke_width, opacity, fill_opacity, stroke_opacity, stroke_dasharray, stroke_linecap, stroke_linejoin, font_size, font_family, font_weight, font_style, text_anchor. Geometry per type: rect: x, y, width, height, rx, ry, fit_to, fit_padding, fit; circle: cx, cy, r; ellipse: cx, cy, rx, ry; line: x1, y1, x2, y2, marker_start, marker_end; polyline: points, marker_start, marker_end; polygon: points; path: d, marker_start, marker_end; text: x, y, text, line_height, vertical_anchor, width, halo, halo_width; group: -; arrow: x1, y1, x2, y2, shaft_width, head_width, head_length; image: x, y, width, height, href, object_fit, embed; use: x, y, width, height, href. points = [[x,y],...]. text supports '\n' for multiple lines; font_size is in user units. Coordinates are in the parent's system: inside a transformed layer or group (e.g. after layout moved it, or a scaled plan group) they are offset/scaled with it. use: href "symbol_id" places a symbol (or any element) of this document; "library.svg#symbol_id" copies that symbol from a file first (list a library's symbols: document_open it, inspect find {"type": "symbol"}); width/height scale a symbol that has a viewBox. clip: an element id (its current shape) or [x, y, w, h] — the element is cut to it and the clip then moves with the element; null removes it. text halo: '#ffffff' outlines the glyphs behind the fill so text reads over lines (halo_width default 0.3 x font size; 'none' removes). place: {"below": id, "gap": 1.5} (or above / left_of / right_of; "align": start|center|end on the other axis) puts the element beside the MEASURED box of another (real glyph extents, any script) and keeps it there when that element changes; inside repeat, ids are template names; null frees it. Responses warn about overlaps among the touched elements: text on text, text across a shape's edge, text crossed by a line (a text with a halo may cross lines). rect fit_to: [ids] sizes the rect around them after wrapping (fit_padding: n | [v, h] | [t, r, b, l]; fit: both | height | width, e.g. height keeps a card's width); it re-fits when those elements are edited (update_elements {"id": rect} re-fits after moves; fit_to: null frees it). defaults is merged into every element (only keys valid for its type), e.g. {"font_size": 2.2, "fill": "#2a8a4a", "layer": "Labels"}. elements_path: a JSON file (a list of specs, or {"elements": [...], "defaults": {...}}) instead of elements — for generated geometry, so it never passes through the conversation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
doc_idNo
previewNo
defaultsNo
elementsNo
elements_pathNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/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 burden and does so well: it discloses that ids are returned, that overlap warnings are emitted for the touched elements, how clip and place bindings persist and are freed with null, how fit_to re-fits on edits, and how defaults are merged. It still omits permission/auth needs, whether the operation is undoable, and what the preview flag actually does.

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 return contract are front-loaded, and given the complexity of the element spec almost every clause documents a real key or behavior that exists nowhere else. It is dense and delivered as one long block rather than grouped by type, which slightly hurts scanability, but little of it is 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?

For a mutation tool with no annotations, no output schema, and five undocumented parameters, the description covers element content thoroughly. It nonetheless leaves gaps an agent needs: the meaning/optionality of doc_id, what preview does, and any statement about reversibility or error behavior.

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 description coverage is 0% and the elements array is only additionalProperties:true, so this description is the sole documentation of the per-type geometry keys, defaults merging, and elements_path file format — a large amount of meaning added. However doc_id and preview are never explained in the text, leaving two of five parameters undocumented in both places.

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 opening sentence gives a specific verb and resource ('Add one or more elements in a single call') plus the return value ('Returns the new ids'), which cleanly separates it from update_elements and delete_elements in the sibling list. The subsequent text never drifts from that scope, so an agent can identify the tool without opening the schema.

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

Usage Guidelines3/5

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

Usage is implied by the extensive spec-key documentation rather than stated: there is no explicit 'use this when creating new elements vs. editing existing ones' guidance, and no prerequisites or when-not conditions. It does give one useful routing hint inside the tool ('elements_path ... for generated geometry, so it never passes through the conversation'), but only for a sub-choice, not for tool selection.

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