Skip to main content
Glama
bhanutpt

inksmcp

by bhanutpt

repeat

Duplicate a template block once per data row to build timelines, card grids, tables, legends, or map symbols in one call.

Instructions

Stamp a block of elements once per data row — timelines, card grids, tables, legends, map symbols — in one call. template: element specs as for add_elements, drawn for the FIRST row. "{key}" in any string is replaced from the row ("{year}"; a value that is exactly "{w}" keeps the row's number), in geometry and style alike ("fill": "{colour}"); "{n}" is the row number (1-based) and "{i}" the index, so rows can't use the keys n and i. Ids are local names: "card" becomes card-1, card-2, ... A "parent" may name another template element (e.g. a group holding a card and its texts); fit_to and clip may name template elements of the same row. Each row goes into a group - moved by n-1 steps: step [dx, dy], or a grid with columns (step = [column pitch, row pitch]), filled row by row or, with order "column", column by column. cell ["col", "row"]: each row is placed by its own 1-based column/row values (gaps and fractions allowed: periodic tables, calendars, timetables, lanes); the template is drawn for cell (1, 1) and step is the [column, row] pitch. Components (a character, a node, a symbol placed at data positions): a template group with "transform": "translate({x},{y}) scale({s})" and step [0, 0], parts drawn around a local origin, pose/shape parts as placeholders ("d": "{arms}"). mirror {"x": 148.5, "rows": "even"|"odd"|"all"} (or "y") mirrors those rows about the axis: shapes are reflected (pointers flip), texts and groups keep their reading direction and move as blocks — group a card with its texts so they cross together. Per element "mirror": "reflect"|"block"|"none" overrides. rows_path: a .json (list of row objects) or .csv file (header line = keys, numbers parsed) instead of rows, so data never passes through the conversation. Returns the row groups, ids per template name (runs shortened to "card-1..card-12"), wrapped_lines, fitted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cellNo
rowsNo
stepYes
layerNo
orderNorow
doc_idNo
mirrorNo
columnsNo
previewNo
defaultsNo
templateYes
id_prefixNorow
rows_pathNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and thoroughly discloses behavior: templating and replacement rules, id generation, parent/fit_to/clip references, row grouping, step/grid/cell placement, mirror semantics, rows_path file input, and returned values. It does not cover permissions or rate limits, but for a non-annotated tool it is unusually rich.

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 long and dense, but it front-loads the core purpose and each sentence adds technical detail needed for a complex 13-parameter tool. Some parameter explanations could be more scannable, but there is little pure repetition or filler.

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?

Given high complexity, no annotations, and no output schema, the description explains return values and many mechanics in useful detail. It is still incomplete for several parameters, so an agent may need to infer layer, doc_id, preview, and defaults 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%, so the description must compensate, and it explains template, step, columns, order, cell, mirror, rows_path, and id_prefix in depth. It leaves rows, layer, doc_id, preview, and defaults unexplained, so the compensation is strong but incomplete.

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 ('Stamp') and resource ('block of elements once per data row') and gives concrete use cases such as timelines, card grids, tables, legends, and map symbols. It distinguishes itself from sibling add_elements by referencing its template specs while emphasizing one-call row repetition.

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?

Provides clear context through use-case examples and the 'in one call' framing, implying when to use it over repeated add_elements calls. However, it does not explicitly state when not to use it or name direct alternatives beyond referencing add_elements for template specs.

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