Perceptual Thread Matching Instrument - A color analysis and cross-stitch pattern generation MCP server with DMC thread matching, image processing, and aesthetic profile application
ColorWizard has 11 tools with reasonable naming (verb-prefixed) and complete input schemas visible in code. However, descriptions are generic and lack LLM-optimization guidance. Most tools have 1-2 sentence descriptions (avg ~80 chars) that state WHAT but not WHEN or WHY. Parameters are typed but many lack actionable constraints (e.g., 'radius' has no range, 'hoop_size_inches' accepts any number). No output schemas documented. Error handling is minimal, no recovery guidance or categorization. Tool composition is reasonable (single responsibility mostly observed), but several tools appear redundant (generate_blueprint, generate_blueprint_v1, generate_blueprint_v2 do similar work). Security: no secrets exposed as params (good), but no audit logging or permission gates visible.
Extracts precise pixel data from a local image file at specified coordinates
Modifies an input color array to match specific aesthetic profiles (Lynchian, Southern Gothic, Brutalist)
Transforms an input image into a vector paint-by-number SVG blueprint (Instrument CW-05)
Generates a paint-by-number blueprint from an image with optional DMC thread matching
Advanced blueprint generation with enhanced region processing and vectorization
Transforms a raw image into a symbol-coded cross-stitch grid with matching DMC manifest. Supports optional aesthetic profile application (CW-03)
Three blueprint generation tools (generate_blueprint, generate_blueprint_v1, generate_blueprint_v2) perform overlapping functionality. LLMs cannot distinguish when to use each variant. Consolidate into a single tool with version negotiation or feature flags.
Descriptions lack actionable guidance on WHEN to call each tool. E.g., 'Samples a color from a registered or provided image' does not explain when to use sample_color vs analyze_image_region. Add dependency hints and use-case context.
Numeric parameters lack range constraints. 'radius' in sample_color has no min/max. 'hoop_size_inches' in generate_stitch_pattern accepts any number (should be enum: 5, 8, 10, etc.). 'max_colors' in generate_stitch_pattern has no upper bound. Add explicit constraints to descriptions and schemas.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
Returns server health status
Registers and processes a base64-encoded image, storing it for later reference
Matches a color to the nearest DMC thread using perceptual color distance (CIEDE2000)
Health check tool that echoes back a message
Samples a color from a registered or provided image at specified coordinates
No output schemas documented. Tools return complex objects (e.g., generate_stitch_pattern returns 'symbol-coded cross-stitch grid with matching DMC manifest') but the exact response structure is not specified. LLMs cannot plan downstream calls without knowing return fields.
Error handling is absent. No recovery guidance, error categorization, or actionable messages visible. If image_register fails on invalid base64, the LLM receives no hint on how to retry or what went wrong.