Loading ToolBench
Model Context Protocol server for the Strøk vector design toolkit. Provides tools for document creation, rendering, inspection, and manipulation via stdio JSON-RPC 2.0.
Strøk MCP server has 16 well-defined tools with explicit schemas and descriptions visible in source. Naming follows verb_noun convention (read, write, exec, render, inspect, query, measure, note_*). Descriptions are substantive (100-250 chars typical), explaining WHAT and WHEN. However, several critical gaps: (1) Parameters lack type constraints (enums, ranges), e.g., 'profile' accepts free-form strings instead of enum [icon-outline-round, icon-outline-angular, icon-solid, icon-mixed]; (2) Output schemas are not documented, tools return results but LLMs cannot see expected fields; (3) Error handling is minimal, no recovery guidance or actionable error messages; (4) No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels (READ_ONLY vs WRITE); (5) Composition is strong (tools chain well via file/source params) but some tools combine concerns (note_pin/note_unpin could be unified). Baseline: 194 chars avg description (this server ~150 chars), 4 params avg (this server ~2-3), 100% A+ tools have return docs (this server ~0%).
Read this first. Explains Strøk effort levels, tool discovery, construction order, visual feedback loops, and completion gates.
Append one or more raw DSL lines to a document. The result is validated by re-parsing before anything is written. With file, appends to the file and returns a confirmation; with source, returns the updated source.
Read the visual-quality workflow before authoring an illustration, icon, logo, or diagram. Covers style selection, geometry/text traps, and required review sizes.
Import an SVG file and convert it to a Strøk document. Returns the DSL source (or writes to file if specified).
Inspect a document: return its resolved scene as JSON (shapes, placements, geometry, styles). Optionally emit as SVG or DSL instead.
Measure geometry: return bounding boxes, dimensions, and anchor positions for shapes or placements.
Output schemas not documented. Tools return results (render → base64 PNG, inspect → JSON scene, query → metadata) but LLMs cannot see expected response fields. This forces LLMs to guess what data is available and risks failed downstream chaining.
Parameter constraints missing. 'profile' in new() accepts free-form strings; should be enum [icon-outline-round, icon-outline-angular, icon-solid, icon-mixed]. 'format' in inspect() should be enum [json, svg, dsl]. 'what' in query() should be enum [shapes, placements, points, anchors]. Free-form strings invite hallucinated values.
No tool annotations despite explicit risk levels. Tools marked WRITE (new, write, exec, note_pin, note_unpin, import_svg, token_sync) should declare destructiveHint=true. READ_ONLY tools should declare readOnlyHint=true. Annotations enable agents to reason about side effects and retry safety.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Create a new Strøk document. With file, writes it to disk and returns a confirmation; without, returns the DSL source. For icons, read the guide then choose an explicit visual profile.
Pin a new review note to a document (appends to the .notes.json sidecar).
Resolve a pinned review note: return its full content and metadata.
Unpin a review note from a document (removes it from the .notes.json sidecar).
List all pinned review notes for a document (from the .notes.json sidecar).
Query a document: return metadata about shapes, placements, or geometry. Supports filters like shape=name or placement=name.
Read a .strok document from disk and return its DSL source.
Render a document to PNG and return it as a base64-encoded MCP image content block. The agent sees the result inline. Optionally render a specific region or size.
Synchronize design tokens between a Strøk document and an external token system (DTCG, Tailwind, etc.).
Replace a .strok document on disk with new DSL source. The source is validated by parsing first; on error the file is left untouched and the caret diagnostics are returned. This is the general-purpose edit: read, modify the text, write.
Error handling lacks recovery guidance. No documented error cases, no actionable messages. E.g., if write() fails validation, what should the LLM do? Retry? Call inspect() first? Call read() to see current state? Bare error codes force agents to guess.
Mutually exclusive parameters not documented. new() has 'file' (write to disk) vs implicit return (return DSL source), unclear which takes precedence. exec() has 'file' vs 'source', docs say 'pass either source or file, not both' but no validation error is specified if both are passed.