Skip to main content
Glama
lucasr1b

sketchdex

by lucasr1b
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

import_svg

Convert SVG markup into editable, hand-drawn Excalidraw elements on a scene, turning paths, shapes, and text into real grouped objects you can revise.

Instructions

Draw by writing SVG. THE way to draw anything that has to look like something: a character, creature, object, vehicle, logo, illustration. This is what produces good figures; stacking shapes with add_elements does not.

The result is hand-drawn, not pasted: every path becomes a real editable Excalidraw element (grouped as one piece), curves are re-spaced to hand-sized strokes and drawn with the sketchy pen, // become native shapes. Write the SVG for SHAPE, PROPORTION and COLOUR and let the canvas supply the pen - do not fake wobble or hatching in the SVG.

A recipe that works for a figure:

  • viewBox about 300 x 600 for a standing figure; import at width 350-450.

  • ONE closed path per body region - torso, each leg, each arm - tapered like a real limb (forearm ~60% of the upper arm, calf into a narrow ankle), plus head, hands, feet. Let them overlap; later paths draw on top. Then detail as separate strokes OVER the silhouette: plates, seams, webbing, a knee line. A few, not many.

  • Every shape: fill=<vibrant, character-accurate hex> stroke=<the scene ink from describe_scene, or a deep shade of the fill> stroke-width 2 to 2.5. Filled shapes with no stroke read as flat.

  • Flat colour, no shading. One solid fill per part; a darker part is a darker hex, not a hatched overlay or a shadow shape. The sketchy outline carries the drawing - texture on top of it looks overworked.

  • Proportion from a rule: 7-8 heads tall for heroic, 5-6 for stylised. Head first, derive the rest.

  • Then render_scene and LOOK; fix what is off. The first pass is usually mis-proportioned, the second is right.

Supported: path (all commands), rect, circle, ellipse, line, polyline, polygon, g, transform, /class, /, presentation attributes, text. viewBox honoured exactly. Gradients flatten to their first stop; pass holeColor to punch compound-path holes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNoWhere to place it on the canvas. Default 0.
yNoDefault 0.
svgYesComplete SVG markup, including the <svg> element and its viewBox.
stepNoAnchor spacing for curves in sketch mode, in canvas px. Default 18. Lower keeps more of the source curve; higher is looser.
groupNoGroup the result as one unit. Default true.
labelYesShort description of what this change is doing, e.g. 'add the dog illustration'. Shown next to the snapshot in the history sidebar, which is how the user decides whether to keep or revert it. Always set it.
sceneYesScene id, exact name, or a unique part of the name. Use list_scenes if unsure.
styleNosketch (default): hand-drawn treatment - anchors re-spaced, curves as curves, roughness 1, native circles/rects. precise: every flattened vertex kept, roughness 0 - for a logo or a drawing that must be exact.
widthNoScale the artwork to this width, keeping its aspect ratio. Height follows.
heightNoOptional bound on height.
fillStyleNoFill for every filled shape. Default solid. hachure for a lighter, sketchier piece (small shapes stay solid); cross-hatch for weight.
holeColorNoBackdrop colour used to punch compound-path holes.
roughnessNo0 precise, 1 sketchy (default in sketch mode), 2 very sketchy.
toleranceNoCurve flattening, in source units. Default 3. Lower is smoother and heavier.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A4.7/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 does so: paths become real editable Excalidraw elements grouped as one piece, curves are re-spaced to hand-sized strokes, circle/ellipse/rect become native shapes, gradients flatten to their first stop, and viewBox is honoured exactly. The label/snapshot note also discloses reversibility context.

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 lead sentence is front-loaded and states the core value before the recipe. The body is long, but the bulleted recipe is dense and task-relevant rather than filler, so it earns most of its length for a complex drawing tool.

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 14-parameter mutation tool with no output schema, the description covers the workflow and result behavior thoroughly, and the schema already documents all parameters. Minor gap: it never states permissions or limits, though those are less relevant for a local canvas tool.

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 100%, so baseline is 3, but the description adds real meaning beyond the schema: concrete guidance on import width (350-450), how style modes behave (sketchy pen vs exact), and the holeColor compound-path hole behavior. It does not restate every parameter, leaving step/tolerance to the schema.

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?

Claims a specific verb+resource ('Draw by writing SVG') and immediately scopes it ('anything that has to look like something: a character, creature, object, vehicle, logo, illustration'). It also differentiates from the sibling add_elements by name, saying stacking shapes 'does not' produce good figures.

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?

Explicitly routes the agent: use import_svg for representational drawing, not add_elements for shape-stacking. It adds a full when/how recipe (viewBox sizing, one path per body region, stroke rules, proportion rule) plus the render_scene-and-look loop.

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

Deploy Server

Other Tools