Skip to main content
Glama
sketchflow-mcp

sketchflow-mcp

by 4Ship-ca

edit_items

List and modify existing sketch items: inspect IDs, types, bounds, and vertices, then delete, move, transform, style, adjust joints, dimensions, or 3D primitive sizes by ID.

Instructions

List or change existing items. list → ids, type groups (Lines, Strokes, Rectangles, Circles, Triangles, Polygons, Fills, Text, Dimensions, Images), bboxes, vertices and joints of a layer. color_by_type gives each type its own palette colour. style can also set name, hidden, locked. delete/move/transform/style by ids. move_joint moves every vertex at (x,y) to (to_x,to_y) so joined lines follow. set_dimension sets a dimension to a value (in board units) and moves the geometry to match (parametric; the height dimension of a 3D primitive rebuilds the primitive). set_size changes the width/depth/height/radius of a parametric 3D primitive and rebuilds it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "edit_items"
  }
}

Input Schema

NameRequiredDescriptionDefault
xNo
yNo
cxNo
cyNo
dxNo
dyNo
idNodimension id for set_dimension
idsNo
to_xNo
to_yNo
depthNo
layerNoLayer id, exact name, or index (0 = bottom). Defaults to the active layer.
scaleNo
styleNo{color,width,opacity,fill,line_type,text,size,font,name,hidden,locked; text only: along (line id to attach, "" to detach), offset (slide along the line px), lift (raise off the line px)}
valueNo
widthNo
actionYes
heightNo
radiusNo
rotateNodegrees
group_idNoset_size: a 3D primitive (or give id of any of its parts)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0-beta.1

TDQS

A3.5/5.0
Behavior4/5

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

With no annotations present, the description carries the full burden and does disclose genuinely non-obvious behavior: set_dimension is parametric and moves geometry to match, the height dimension of a 3D primitive rebuilds it, set_size rebuilds primitives, and move_joint relocates every vertex at (x,y). It stops short of stating irreversibility of delete, whether style changes are additive or replacing, or any size limits on list.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely dense with essentially no filler, and the core purpose is front-loaded. But it is a run-on of arrow-delimited fragments that mixes return-value documentation with action semantics, making it hard to scan for a specific action's contract.

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 nine-action, 21-parameter mega-tool with no annotations and no output schema, the description explains action behavior well but never states which parameters are required or meaningful per action, which is the main thing an agent needs to invoke it correctly. The list return shape is sketched but not fully specified.

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 24% across 21 parameters, so the description must compensate and does so for many: ids, id for set_dimension, x/y and to_x/to_y for move_joint, value for set_dimension, width/depth/height/radius for set_size, and the style sub-keys including text-only along/offset/lift. However cx, cy, dx, dy, scale, layer, and the action-to-parameter pairing remain unexplained, leaving a substantial gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ("List or change existing items") and then enumerates all nine actions with what each one does, including the exact type groups returned by list. It implicitly distinguishes itself from creation siblings like draw by scoping to "existing items", though it never names an alternative tool outright.

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?

The per-action clauses effectively give selection guidance within the tool (use move_joint for shared vertices, set_dimension for parametric dimension driving, set_size for 3D primitives). There is no explicit when-to-use-this-vs-siblings guidance and no stated prerequisite such as obtaining ids first via list.

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