Loading ToolBench
Compositor API for self-contained SVG artifacts from semantic parameters. Use hw_compose for any artifact type (returns {envelope, url}, never inline SVG). Use hw_validate to check a spec without rendering. Use hw_discover to see available genomes, motions, glyphs, and frame types.
HyperWeave MCP server has serious definition quality gaps. The three tools (hw_compose, hw_validate, hw_discover) have drastically incomplete schemas, vague or missing parameter descriptions, and lack error handling guidance. hw_compose accepts 33 parameters, most with generic type hints (str, dict, list) and no meaningful descriptions beyond repeating parameter names. The input schema visible in the source shows only type and description fields without enum constraints, format validation, or range limits. Tool descriptions are present but generic ('Compose a HyperWeave artifact') without explaining when to use each tool versus others or what actual errors the LLM should expect. Parameter descriptions are almost entirely absent, e.g., 'genome' has no description, 'regime' has none, 'motion' is undefined. Output schemas are not documented in the server code, forcing LLMs to guess what hw_compose returns. No error messages, recovery guides, or parameter validation examples are visible. The instruction text is adequate but parameters lack the specificity needed for reliable LLM planning. Compared to production baselines (avg tool description 194 chars, 100% of A+ tools have param descriptions), this server falls far short.
Compose a HyperWeave artifact. Returns ``{envelope, url, width, height, genome, variant}`` — the actionable hwz/1 envelope plus a content-addressed handle to the pixels. The SVG bytes are cached and served at ``url``; they never travel inline (emit ````, not tens of KB of markup). With ``render_target='markdown'`` returns the text shadow string instead. Set ``respond='svg'`` to get the raw SVG markup inline instead of the ``{envelope, url}`` handle — for a caller that must embed the pixels directly (the artifact is still cached under ``url``).
Discover available genomes, motions, glyphs, and frame types. Returns what composition options are available.
Validate a HyperWeave spec without rendering. Check if a composition is valid before attempting to render.
hw_compose: 33 parameters with no or generic descriptions. 'genome', 'regime', 'speeds', 'connector_data', 'glyph_tint' and most others lack descriptions entirely or repeat the parameter name. LLMs cannot infer what these control without explicit guidance.
hw_compose: Input schema contains only type and description fields. No enum constraints (e.g., 'motion' should be enum of valid motion types), no format validation (e.g., 'size' should specify allowed values), no range limits for numeric params. LLMs will hallucinate invalid values like motion='spin_fast' when only 'static' or specific modes are valid.
Output schemas not documented. hw_compose description mentions returns '{envelope, url, width, height, genome, variant}' in prose but no structured schema in tool definition. hw_validate and hw_discover return types are undocumented. LLMs cannot plan downstream tool calls without knowing return field names and types.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | <=2025-11-25 | v2 |
hw_compose: Description does not explain when to use this vs hw_validate. No guidance on error conditions, invalid parameter combinations, or recovery paths. An LLM calling with invalid genome will get an error with no hint about next steps.
hw_validate: Description ('Validate a HyperWeave spec without rendering. Check if a composition is valid before attempting to render.') is generic. Does not explain when LLM should use this before hw_compose, what specific validations it performs, or what errors it detects.
hw_compose: Parameters like 'type' (expecting 'envelope', 'svg', 'json') should be enum, not free-form string. 'render_target', 'format', 'respond' are also choice fields but presented as strings. Enums would prevent hallucinated values.
No parameter dependencies documented. hw_compose has params like 'respond=svg' and 'render_target=markdown' that may conflict or depend on 'type'. No description explains these relationships, forcing LLM to guess or trial-and-error.
hw_compose: Complex nested params (telemetry_data, genome_override, connector_data, matrix, diagram) accept 'dict[str, Any]' with no schema. LLMs have no way to know what keys or structure these dicts require. Should document expected shapes (enums of allowed keys, value types, or link to a schema resource).