Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Ink/Stitch MCP Bridge Convert logo.svg to DST with 0.5mm satin stitches"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives AI assistants full headless access to Ink/Stitch machine-embroidery tooling — no Inkscape installation required.
SVG designs go in; stitch-ready machine files (DST, PES, JEF, EXP, VP3, and ~17 more), PNG previews, validation reports, and digitized lettering come out.
The image above is the bridge's own output: generate_lettering("Hello", "Amitaclo") →
machine-ready DST → render_png_preview.
MCP client (Claude Code / Claude Desktop)
│ stdio (JSON-RPC)
▼
inkstitch-mcp server (FastMCP, this package)
├── native tools ──────────► pystitch + lxml (stats, PNG render, format
│ conversion, param editing, font/format lists)
└── subprocess tools ──────► .venv-inkstitch python
vendor/inkstitch/inkstitch.py --extension=…
(export, import, lettering, validation,
stitch-plan previews, transforms)Tool | What it does |
| Verify toolchain; optional end-to-end smoke export |
| Machine formats Ink/Stitch reads (~50) and writes (~22) |
| 140 bundled digitized lettering fonts |
| All legal per-element stitch parameters (~136) |
| Inventory an SVG: ids, labels, stitch type (fill/stroke/satin), params |
| Read/write |
| SVG → machine file (format from output extension) + stitch stats |
| Machine file → editable stitch-plan SVG |
| One SVG → many formats in a ZIP, optional panelization |
| Stitch/jump/trim/color counts, threads, size (mm) of a machine file |
| Machine file → machine file (e.g. DST → PES) |
| PNG image of the stitches (from machine file or SVG) |
| Plain-text thread/color report |
| Structured validation: errors/warnings with positions & fixes |
| Stitch-density heat-map layer (thread-break risk) |
| Render the actual stitch plan into an SVG layer |
| Remove problem-causing tiny objects (dry-run by default) |
| stroke_to_satin, auto_satin, auto_run, fill_to_stroke, jump_to_stroke, break_apart, outline |
| Strip embroidery params/commands from an SVG |
| Text → embroidered lettering in any bundled font |
Related MCP server: imagetosvg-mcp
Requires Python 3.11 (Ink/Stitch's pinned dependencies do not support newer interpreters) and git. Developed and tested on Windows 11; the code paths are OS-aware but only Windows has been exercised.
# --recursive pulls the Ink/Stitch submodule AND its fonts submodule (140 fonts)
git clone --recursive https://github.com/GreerBK/InkStitchMCP
cd InkStitchMCP
py -3.11 -m venv .venv-inkstitch
# inkex's repo has a test file exceeding Windows path limits; scope the fix to this install:
set GIT_CONFIG_COUNT=1&& set GIT_CONFIG_KEY_0=core.longpaths&& set GIT_CONFIG_VALUE_0=true
.venv-inkstitch\Scripts\python -m pip install -r requirements-inkstitch.txt
.venv-inkstitch\Scripts\python -m pip install -e .If you cloned without --recursive: git submodule update --init --recursive.
Verify everything with the health_check tool (or run the test suites below).
Paths are overridable via INKSTITCH_MCP_ROOT / INKSTITCH_MCP_REPO /
INKSTITCH_MCP_PYTHON / INKSTITCH_MCP_OUTPUT (see src/inkstitch_mcp/config.py),
plus INKSTITCH_MCP_TIMEOUT / INKSTITCH_MCP_SLOW_TIMEOUT (seconds) and
INKSTITCH_MCP_TRACE=1 for stderr tracing of subprocess calls.
Claude Code — either copy .mcp.json.example to .mcp.json (auto-loads for this
project) and fill in your path, or register globally:
claude mcp add inkstitch -- <path-to-InkStitchMCP>\.venv-inkstitch\Scripts\python.exe -m inkstitch_mcpClaude Desktop — add to %APPDATA%\Claude\claude_desktop_config.json:
{
"mcpServers": {
"inkstitch": {
"command": "<path-to-InkStitchMCP>\\.venv-inkstitch\\Scripts\\python.exe",
"args": ["-m", "inkstitch_mcp"]
}
}
}.venv-inkstitch\Scripts\python tests\e2e.py # 34 checks, every tool, real designs
.venv-inkstitch\Scripts\python tests\protocol_smoke.py # real MCP stdio round-tripThese are the traps this bridge encodes; they matter if you modify runner.py:
Exit codes lie. Ink/Stitch exits 0 for parse errors, "no embroiderable elements", and domain errors — with the explanation on stderr and an empty payload. Success is judged per-tool from payload presence, never from the return code.
stdout is binary. Embroidery/ZIP payloads come over stdout (the Inkscape
convention); the output extension switches stdout to O_BINARY on Windows. Always
capture bytes; stderr is UTF-8, flushed once at process exit.
stdin=DEVNULL is load-bearing. Under an MCP client, the server's stdin is the
live JSON-RPC pipe; letting a child inherit it deadlocks the child interpreter at
startup on Windows (diagnosed via py-spy: zero CPU, no Python frames).
Legacy SVGs summon an invisible dialog. Every extension's load() runs the
version migrator with a blocking wx prompt for unversioned files containing
Ink/Stitch attributes — including --extension=update_svg itself. The preflight in
runner.py detects the condition (same XPath as lib/update.py) and migrates via
_migrate_helper.py, which calls the migrator directly with the prompt disabled.
Never expose raster preview modes. png_realistic, png_simple, realistic-DPI
stitch plans, and the ZIP --format-png-realistic/simple flags all shell out to an
inkscape binary. PNG previews here use pystitch's native renderer instead.
The output extension's parser is hand-rolled. Options must be single
--name=value tokens, --format is mandatory, values containing = crash it, and
--output is swallowed (hence stdout capture there, --output=<tmpfile> elsewhere).
Arg spelling is per-extension. Some use hyphens, some underscores, some both
(batch_lettering mixes them in one parser). Flags are hardcoded per tool from the
vendored argparsers — don't "normalize" them.
--del_params must always be passed to remove_embroidery_settings: its
argparse default is the Python bool True with type=str, which crashes when omitted.
batch_lettering dumps the input SVG on validation failure with exit 0 — the
ZIP magic (PK) check is what actually detects failure.
Documents parameterized by this bridge are version-stamped. set_element_params
writes the current inkstitch_svg_version metadata; without it, the next tool call
would run the v0→v4 legacy migration on freshly written modern params and silently
change their meaning (e.g. solid strokes forced to zigzag_stitch).
Slow tools run off the event loop. Subprocess-backed tools are registered via
blocking_tool (async + anyio.to_thread); registering them as plain sync tools
freezes all MCP traffic for the duration of an export.
custom_file_name is a path fragment inside the zip extension — it is
validated against a strict character allowlist to prevent writing outside the
target directory.
This bridge code: MIT (see LICENSE). Ink/Stitch is referenced as a git submodule —
not distributed in this repository — and is GPL-3.0-or-later; pystitch and other
dependencies carry their own licenses. If you distribute a bundle that includes the
vendor/inkstitch checkout, GPL terms apply to that component.
Remove tiny/empty objects that would cause thread breaks. dry_run=True (default) only reports what would be removed.
| Name | Required | Description | Default |
|---|---|---|---|
| dry_run | No | ||
| svg_path | Yes | ||
| remove_fills | No | ||
| remove_satins | No | ||
| remove_strokes | No | ||
| output_svg_path | No | ||
| fill_threshold_mm2 | No | ||
| satin_threshold_mm | No | ||
| remove_empty_groups | No | ||
| stroke_threshold_mm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses removal of objects and dry run mode, but with no annotations, it misses details on whether the operation is reversible, what the default output path behavior is (in-place or to output_svg_path), and how thresholds are applied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that front-load purpose. Every word is necessary; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and no annotations, the description fails to provide sufficient context for proper tool invocation. Missing parameter explanations and return value info make it incomplete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains only the 'dry_run' parameter. Other 9 parameters (thresholds, flags, paths) are not described, leaving the agent without meaning for most options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes tiny/empty objects that cause thread breaks, using a specific verb (remove) and resource (document). While it doesn't explicitly distinguish from siblings, the embroidery context makes it distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions dry_run behavior and default, implying usage for inspecting removals before committing. However, it lacks guidance on when not to use this tool vs alternatives like transform_elements or remove_embroidery_settings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert one machine embroidery file to another format directly (e.g. mydesign.dst -> mydesign.pes). Format taken from the output extension.
| Name | Required | Description | Default |
|---|---|---|---|
| input_path | Yes | ||
| output_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description adds that conversion is 'direct' and format is from extension, but fails to disclose potential issues like overwriting, supported formats, permissions, or error handling. Minimal behavioral context beyond basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero wasted words. The core action is front-loaded, followed by a clarifying example and a crucial detail about format inference. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description minimally covers the tool's function given its simplicity (2 string params, no output schema). However, it lacks completeness on return values, error cases, and format support, leaving gaps for an agent to fully understand tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must explain parameters. It provides no per-parameter details; only indirectly clarifies input_path and output_path via the example. The agent gains little extra meaning beyond the schema field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'convert' and the specific resource 'machine embroidery file', with an explicit example (dst to pes) that distinguishes it from sibling tools like import/export or listing formats. The note about format taken from output extension adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to change format), but does not explicitly state when not to use or mention alternatives like list_formats or import/export. No exclusion criteria or context for agent to differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Annotate an SVG with a stitch-density heat map layer (red/yellow/green markers per stitch).
| Name | Required | Description | Default |
|---|---|---|---|
| svg_path | Yes | ||
| indicator_size | No | ||
| output_svg_path | No | ||
| num_neighbors_red | No | ||
| density_radius_red | No | ||
| num_neighbors_yellow | No | ||
| density_radius_yellow | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It mentions 'annotate' but does not specify side effects like file modification, overwrite behavior, or required permissions. The output_svg_path parameter suggests optional output, but this is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but extremely brief. It could be improved by front-loading key details about parameters and behavior while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no annotations, no output schema), the description is severely incomplete. It fails to provide essential context about parameters, output, or typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 7 parameters with 0% description coverage, yet the tool description provides no explanation of any parameter (e.g., indicator_size, num_neighbors_red). Without additional context, the agent cannot understand parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: annotating an SVG with a stitch-density heat map layer using red/yellow/green markers. It distinguishes itself from sibling tools by being focused on density visualization, which is unique among the listed sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. With 20 sibling tools, there is no mention of use cases or exclusions, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stitch statistics for a machine embroidery file: stitch/jump/trim counts, color changes, threads, size in mm.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description implies a read operation but does not explicitly state non-destructiveness, required permissions, or error handling (e.g., invalid file).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys what the tool does and what outputs to expect. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description lists the output metrics but lacks details on return format, error behavior, or whether it modifies state. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. The description does not elaborate on the file_path parameter (e.g., format, constraints). It only implicitly references it via 'machine embroidery file'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides stitch statistics for a machine embroidery file, listing specific metrics (stitch/jump/trim counts, color changes, threads, size in mm). This distinguishes it from sibling tools like density_map or preview_stitch_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives (e.g., troubleshoot, density_map). It does not provide any context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compile an SVG design into a machine embroidery file (format from the output extension: .dst, .pes, .jef, .exp, .vp3, ...). Returns stitch statistics.
Defaults to /.dst when output_path is omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| svg_path | Yes | ||
| laser_mode | No | ||
| output_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It mentions returning stitch statistics and default output path, but does not disclose file overwrite behavior, error handling, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with key information front-loaded. No redundant or unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters and no output schema, description covers core function and one parameter default. Lacks details on laser_mode, return format of stitch statistics, and potential errors. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description should compensate. It explains output_path default but not laser_mode, and svg_path is self-explanatory. Minimal added value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Compile' and resource 'SVG design into a machine embroidery file', lists output formats, and distinguishes from siblings like import_embroidery and convert_machine_format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear default behavior for output_path, implying usage context. However, lacks explicit when-to-use or alternative tool guidance, which is partially mitigated by context signals like sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export an SVG design to several formats at once as a ZIP (e.g. ["dst","pes","svg","threadlist"]). x/y_repeats panelize copies with the given spacing (mm).
| Name | Required | Description | Default |
|---|---|---|---|
| formats | Yes | ||
| svg_path | Yes | ||
| x_repeats | No | ||
| x_spacing | No | ||
| y_repeats | No | ||
| y_spacing | No | ||
| output_path | No | ||
| custom_file_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It discloses the panelization feature (x/y_repeats, spacing) but omits whether the operation is destructive, required permissions, or error behavior. Adds some context but lacks safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The main action and key features (panelization) are front-loaded. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description covers the core export and panelization but omits output path customization and file name. It is adequate but not fully complete for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% in the schema itself, but the description explains the formats array and panelization parameters. However, it fails to describe svg_path, output_path, and custom_file_name. The explanation adds meaning for covered params but missing for 3 out of 8.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports SVG designs to multiple formats as a ZIP, with explicit examples (e.g., ["dst","pes","svg","threadlist"]). It distinguishes from siblings like export_embroidery which handles single formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when multiple formats or panelization is needed, but does not explicitly state when not to use it or mention alternative tools (e.g., export_embroidery, convert_machine_format). Guidance is vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create machine-embroidered text using Ink/Stitch's digitized fonts.
font is the font name from list_fonts (e.g. "Amitaclo"). formats defaults to ["dst", "svg"]. scale_percent is clamped to the font's supported range. NOTE: each newline-separated line of text becomes a SEPARATE design (own file set) — that is the batch semantics of the underlying extension. trim: off/line/word/glyph. color_sort: off/all/line/word. text_align: left/center/right/block/letterspacing. Extracted files land in output_dir (default: /lettering_).
| Name | Required | Description | Default |
|---|---|---|---|
| font | Yes | ||
| text | Yes | ||
| trim | No | off | |
| formats | No | ||
| color_sort | No | off | |
| output_dir | No | ||
| text_align | No | left | |
| line_height | No | ||
| word_spacing | No | ||
| scale_percent | No | ||
| letter_spacing | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses batch semantics (each line becomes separate design), scale_percent clamping, default formats, output directory behavior, and trim/color_sort/text_align options. With no annotations, this fully informs the agent of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense paragraph front-loads purpose then systematically lists parameter details using colons. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, 0% schema coverage, no output schema, and no annotations, the description covers constraints, defaults, and side effects thoroughly. The only minor gap is undefined numeric parameters, but overall it's remarkably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Explains font, formats, scale_percent clamping, trim/color_sort/text_align enums, output_dir default, and batch behavior of text. However, numeric parameters like line_height, word_spacing, letter_spacing are only named with defaults, lacking units or interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool creates machine-embroidered text using digitized fonts. The verb 'Create' and resource 'machine-embroidered text' are precise. Distinguishes from siblings like import_embroidery and export_embroidery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: font must come from list_fonts, newline-separated lines become separate designs. Does not explicitly exclude other uses or compare to siblings, but the specific nature of lettering implies when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Ink/Stitch parameters from SVG elements (all parameterized elements, or only the given ids).
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | ||
| svg_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states 'Read' implying no mutation, but omits details on error handling (e.g., invalid svg_path or ids), return format, or any side effects. Basic operation is implied but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It efficiently conveys the core functionality, but could benefit from a bit more detail on parameters without becoming overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should hint at return values. It does not describe the structure or content of the parameters returned. With 0% schema coverage and no output schema, the description leaves significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description should clarify parameter semantics. It explains the 'ids' parameter's dual behavior (all vs specific), but does not describe 'svg_path' at all, leaving its purpose and format unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads Ink/Stitch parameters from SVG elements, with a specific verb 'Read' and resource 'SVG elements'. It distinguishes from sibling tools like set_element_params (write) and list_known_params (lists all known parameters, not per element).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions filtering by ids, but gives no guidance on when to use this tool vs alternatives like list_elements or list_known_params. No explicit when-to-use or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the Ink/Stitch toolchain is ready (venv, checkout, fonts, pystitch).
With run_smoke_test=True, also exports a tiny test design to DST end-to-end (takes a few seconds).
| Name | Required | Description | Default |
|---|---|---|---|
| run_smoke_test | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states the tool verifies readiness and that the smoke test exports a design and takes a few seconds. It does not describe potential failure modes, return values, or side effects beyond the time cost, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main purpose, and every word serves a purpose. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional boolean parameter, no output schema), the description covers the core functionality and parameter behavior. It could be enhanced by briefly indicating the output/return value, but it remains fairly complete for a health check utility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does so by explaining that with run_smoke_test=True, the tool exports a tiny test design end-to-end and notes it takes a few seconds. This adds context beyond the boolean type, though it omits explicit mention of the default behavior (no smoke test means just checking readiness).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Verify' and the resource 'Ink/Stitch toolchain', listing the components checked (venv, checkout, fonts, pystitch). It differentiates from sibling tools which focus on import, export, listing, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for checking toolchain readiness. It explains when to use the optional smoke test parameter (to run an end-to-end test). However, it does not explicitly state when not to use this tool or mention alternatives, though the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a machine embroidery file (dst/pes/jef/exp/vp3/hus/...) into an SVG of its stitch plan, editable in Inkscape.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| output_svg_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral burden. It indicates a read-convert-write operation without side effects on input, but omits details like required permissions, error behavior, or whether it modifies the original file. Some transparency is provided via input format list but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys purpose. However, it could briefly mention output path without harming conciseness. Still, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 0% schema coverage, the description provides adequate high-level purpose but lacks details on return values, error conditions, or parameter behaviors. It is minimally complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It implies file_path is the embroidery file and mentions output is SVG, but does not describe output_svg_path's role or default behavior. Both parameters lack explicit semantic explanation beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts machine embroidery files to SVG stitch plans, listing common input formats and noting editability in Inkscape. This verb-resource pair is specific and distinguishes it from siblings like export_embroidery or render_png_preview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when an SVG stitch plan is needed, but lacks explicit when-to-use, when-not-to-use, or alternatives among siblings like preview_stitch_plan or convert_machine_format. Guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inventory embroiderable elements in an SVG: ids, labels, inferred stitch type (fill/stroke/satin), and existing Ink/Stitch params.
| Name | Required | Description | Default |
|---|---|---|---|
| svg_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It describes what is returned but does not explicitly state that the tool is read-only, idempotent, or non-destructive. These traits are implied but not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 15 words, front-loaded with the action and outcomes. No redundant information. Perfectly sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain the output structure or format. It does not, and it also lacks clarity on what constitutes an 'embroiderable element' or any limitations. The tool is simple, but the description leaves the agent guessing about the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It mentions 'SVG' in the description, hinting at the svg_path parameter, but does not describe its format (e.g., file path vs. URL) or any constraints. The list of returned data adds some semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Inventory' clearly indicates a listing operation. The description specifies exactly what is listed (ids, labels, stitch type, existing params), which distinguishes it from siblings like get_element_params or set_element_params. However, it could be more explicit about the tool's role in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_element_params. No usage context, prerequisites, or exclusions are mentioned, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List embroidery lettering fonts available to generate_lettering (name, scale limits, description).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. While 'list' implies a read-only operation, the description does not explicitly state it is non-destructive, does not mention any side effects, caching, or rate limits. It adds the specific fields returned, which is helpful, but overall transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, and every word provides value. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description sufficiently explains what the tool returns (name, scale limits, description). The purpose is fully covered, and the agent can correctly use the tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so per rules the baseline is 4. The description adds no parameter meaning because none exist, but it correctly implies no inputs are needed. Schema coverage is trivially 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('list') and a clear resource ('embroidery lettering fonts'), and distinguishes itself from sibling tools like generate_lettering by noting these fonts are available for that tool. The fields returned (name, scale limits, description) are listed, eliminating ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage before generate_lettering by stating the fonts are 'available to generate_lettering'. This gives context for when to use the tool, though it does not explicitly mention when not to use it or compare to other siblings. For a simple list tool, this is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List machine-embroidery file formats Ink/Stitch can read and write (dst, pes, jef, exp, vp3, ...).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly discloses that the tool lists formats (a read-only, non-destructive operation) with no side effects. It does not detail return format or side effects, but given the tool's simplicity (no parameters, no mutations), this is adequate. A high score is justified as there are no hidden behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource, with parenthetical examples. Every word earns its place; there is no redundancy or filler. It is concise yet fully informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description provides all necessary context: it lists readable/writable formats and names examples. No additional details are required for an agent to correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (no parameters to describe). The baseline for 0-param tools is 4. The description adds no parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource as 'machine-embroidery file formats Ink/Stitch can read and write', with concrete examples (dst, pes, jef, exp, vp3). This clearly distinguishes it from sibling tools like import_embroidery, export_embroidery, and convert_machine_format, which involve file operations rather than listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool lists readable and writable formats, providing clear context for use. While it does not explicitly mention when not to use it, the sibling names (e.g., convert_machine_format) imply that this tool is for informational queries, not conversion. A brief 'when not to use' could elevate the score, but current guidance is sufficient for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every legal Ink/Stitch per-element parameter name usable with set_element_params.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states what is listed, not behavioral traits like read-only nature, authentication needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and resource, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately complete for a simple listing tool with no parameters, but lacks mention of return format or ordering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Baseline 4 applies as description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'list' and resource 'legal Ink/Stitch per-element parameter name', clearly distinguishing from sibling tools like set_element_params which modifies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage before set_element_params, but lacks explicit when-to-use or when-not-to-use guidance and does not mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a rendered stitch-plan layer to an SVG (what will actually be sewn). mode: 'simple' or 'realistic-vector'.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | simple | |
| svg_path | Yes | ||
| render_jumps | No | ||
| needle_points | No | ||
| output_svg_path | No | ||
| layer_visibility | No | unchanged |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions adding a layer and mode options but does not state side effects (e.g., whether the SVG is modified in place or a copy is created), permission requirements, or effects on original data. The output_svg_path parameter hints at output behavior, but this is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with only one sentence plus a mode hint. No wasted words, but could benefit from a brief structure or list to improve scannability. The core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain the return value (likely the modified SVG or a path), the effect of 'layer_visibility', or the purpose of 'render_jumps' and 'needle_points'. Agents are left with many unknowns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only adds meaning for 'mode' by listing two values ('simple' or 'realistic-vector'). Other parameters like 'svg_path', 'render_jumps', 'needle_points', 'output_svg_path', and 'layer_visibility' are not described, leaving agents to infer from names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a rendered stitch-plan layer to an SVG, specifying what will be sewn. It distinguishes from siblings like 'render_png_preview' (renders PNG) and export tools by focusing on a specific visualization. The verb 'add' and resource 'rendered stitch-plan layer' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., 'render_png_preview' for bitmap previews, 'design_stats' for analysis). Does not mention prerequisites or conditions for effective use, such as requiring an existing stitch plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Strip Ink/Stitch parameters and/or command symbols from an SVG, returning it to a plain vector design.
| Name | Required | Description | Default |
|---|---|---|---|
| svg_path | Yes | ||
| remove_params | No | ||
| output_svg_path | No | ||
| remove_commands | No | ||
| remove_print_settings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions 'returning it to a plain vector design' but does not clarify whether the operation is destructive (modifies in-place), what error conditions exist, or how the output is handled. The 'strip' action implies mutation, but safety context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise, but it lacks structure. It does not break down information into readable parts (e.g., parameters, usage, effects). While every word contributes, the density of information is low.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 5 parameters, no output schema, and no annotations, the description is severely incomplete. It does not describe return values, parameter options, or behavioral nuances. An agent would need additional information to correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 5 parameters. The description only hints at 'parameters and command symbols', corresponding to 'remove_params' and 'remove_commands', but fails to explain 'remove_print_settings', 'output_svg_path', or 'svg_path'. The agent cannot infer parameter semantics from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Strip') and clearly identifies the resource ('Ink/Stitch parameters and/or command symbols from an SVG'). It explains the tool's purpose unambiguously and distinguishes it from siblings like 'cleanup_document' by focusing on embroidery-specific data removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when converting an SVG with embroidery settings to a plain vector design, but it does not mention when to avoid using it (e.g., when retaining embroidery data) or compare it to similar tools like 'cleanup_document'. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a PNG preview of a design's stitches. Accepts a machine file (dst/pes/...) or an SVG (which is compiled first). Returns the image.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| output_png_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must handle behavioral disclosure. It mentions that SVGs are compiled first, which is useful, but does not state whether the tool is read-only, modifies any files, or has side effects. Additional context about safety would improve score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences, front-loading the key purpose. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description covers the core purpose and input types. However, it omits details about the output format, error handling, and the optional output_png_path parameter, which are important for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate. It only indirectly mentions file_path by describing accepted input types. The output_png_path parameter is not described at all, leaving its purpose and default behavior unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (render), resource (PNG preview of design's stitches), and input types (machine file or SVG). It distinguishes from siblings like export_embroidery or preview_stitch_plan by focusing on raster preview output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when a PNG preview is needed) but does not provide guidance on alternatives like preview_stitch_plan or when not to use this tool. No explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set or remove Ink/Stitch stitch parameters on SVG elements.
updates maps element id -> {param_name: value}; value null removes the param. Param names must come from list_known_params (e.g. angle, row_spacing_mm, running_stitch_length_mm, satin_column, fill_underlay). Booleans are written as true/false; *_mm values are millimeters. Overwrites the input SVG unless output_svg_path is given.
| Name | Required | Description | Default |
|---|---|---|---|
| updates | Yes | ||
| svg_path | Yes | ||
| output_svg_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool overwrites the input SVG unless output_svg_path is provided, a critical destructive behavior. It also specifies boolean and millimeter value formats. However, it does not mention error handling, idempotency, or whether multiple calls accumulate changes. Still, the key behavioral trait is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact paragraph with the purpose upfront, followed by details. It avoids redundancy but could be slightly better structured (e.g., bullet points for parameter guidelines). Every sentence adds information, and it is reasonably concise for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a complex object parameter, the description covers purpose, parameter usage, and a key behavior (overwrite). However, it does not describe the return value (likely success indicator or modified SVG) or error conditions (e.g., invalid param names, missing elements). For a mutation tool, these are notable omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains the updates parameter structure (element id -> {param: value}) and that null removes a param. It lists example param names from list_known_params. It clarifies the output_svg_path role. But it does not explain the svg_path parameter beyond being required, leaving a small gap. Overall, adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Set or remove Ink/Stitch stitch parameters on SVG elements.' It uses a specific verb ('set or remove') and identifies the resource (SVG elements with stitch parameters). It distinguishes itself from siblings like get_element_params (read) and list_known_params (list valid param names).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the updates parameter: maps element id to param-value pairs, with null to remove. It also mentions that param names must come from list_known_params, giving examples. It notes the overwrite behavior with output_svg_path as a safeguard. However, it does not explicitly compare to other mutation tools like transform_elements or cleanup_document, lacking explicit when-not alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plain-text thread/color report for an SVG design: design size, stitch counts, thread order.
| Name | Required | Description | Default |
|---|---|---|---|
| svg_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It hints at a read-only report but does not explicitly state whether it modifies the design, requires authentication, or affects state. For a simple report tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it lacks structure. It is concise but could benefit from bullet points or clearer separation of output fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of an output schema, the description mentions key output fields but omits details like the exact format (e.g., plain-text lines) and any tool constraints (e.g., file must exist).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add any meaning to the 'svg_path' parameter beyond its name. It fails to clarify whether the path is local or remote, required format, or any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a 'Plain-text thread/color report' for an SVG design, listing design size, stitch counts, and thread order. This distinguishes it from sibling tools like design_stats or density_map.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used when a text report of threads/colors is needed for an SVG design, but it lacks explicit guidance on when not to use it or how it compares to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply an Ink/Stitch conversion to SVG elements and save the result.
operation: stroke_to_satin (center-line pair -> satin column), auto_satin (route satins optimally), auto_run (route strokes into one running stitch), fill_to_stroke (fill -> centerline), jump_to_stroke (connect jumps with strokes, whole document), break_apart (split multi-part fill paths), outline (fill -> outline stroke). ids selects target elements (required for all but jump_to_stroke; get them from list_elements). options overrides operation-specific flags, e.g. {"threshold_mm": 5}.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | ||
| options | No | ||
| svg_path | Yes | ||
| operation | Yes | ||
| output_svg_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavior but only partially does. It describes operations and mentions saving the result, but it does not clarify whether the tool overwrites files, requires permissions, or handles errors. Key behavioral traits like file modification are ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loads the purpose. The list of operations is compact, though the abbreviations could be clearer. Overall, it is economical with words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 5 parameters, no schema descriptions, no output schema, and no annotations, the description is incomplete. It lacks details on input/output paths, error conditions, and default behaviors, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It covers operation (with examples), ids (usage note), and options (example). However, svg_path and output_svg_path are not described at all, missing essential semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Apply an Ink/Stitch conversion to SVG elements and save the result.' It lists specific operations and distinguishes itself from siblings like list_elements and set_element_params.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that ids is required for all but jump_to_stroke and suggests getting them from list_elements. However, it does not provide explicit guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a design's embroidery elements; returns structured errors/warnings with positions and suggested fixes.
| Name | Required | Description | Default |
|---|---|---|---|
| svg_path | Yes | ||
| show_errors | No | ||
| show_warnings | No | ||
| show_type_warnings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it returns structured errors/warnings, but does not disclose if it modifies state, requires auth, or has rate limits. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, front-loaded with the core action and output summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters and no output schema, the description should cover more. It fails to explain parameters, return structure details, or behavior beyond the basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%: the description does not explain the svg_path, show_errors, show_warnings, or show_type_warnings parameters. It adds no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool validates embroidery elements and returns structured errors/warnings with positions and suggested fixes. It's a specific verb-resource pair, distinguishing it from sibling tools like health_check or cleanup_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like health_check or cleanup_document. There is no mention of conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0cleanup_documentconvert_machine_formatdensity_mapdesign_statsexport_embroideryexport_zipgenerate_letteringget_element_paramshealth_checkimport_embroiderylist_elementslist_fontslist_formatslist_known_paramspreview_stitch_planremove_embroidery_settingsrender_png_previewset_element_paramsthread_listtransform_elementstroubleshootEach tool targets a distinct operation: import, list resources, health check, export, transform, validate, generate lettering, etc. No two tools have overlapping purposes; even similar tools like preview_stitch_plan and render_png_preview are clearly differentiated by output (SVG layer vs PNG image).
All tool names follow a consistent snake_case verb_noun or verb_noun_noun pattern, with clear action and target. Examples: import_embroidery, list_fonts, set_element_params, etc. No mix of conventions.
With 21 tools, the server covers a broad range of embroidery design workflows. While slightly above the typical 3-15 range, each tool serves a distinct purpose and the count feels justified for the domain.
The tool set covers the full lifecycle of embroidery design: importing, inspecting, modifying, generating, validating, previewing, exporting, and housekeeping. Obvious gaps like creating elements from scratch are handled by the SVG-first workflow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate vector art, vectorize images, and return SVG, PNG, and logo kits to AI agents.
Generate and vectorize clean, editable SVG graphics from text, images, or both.
AI-agent design tools: fonts, font recognition, palettes, color naming, contrast, code, SVG, CSS.
Multilingual semantic SVG icon search with previews for AI coding agents. 20,000+ icons.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/GreerBK/InkStitchMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
