Loading ToolBench
Mosvera MCP demonstrates solid foundational quality with 17 well-named tools, explicit schemas for all tools, and consistent tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools have descriptions (avg ~100 chars, within baseline 34-392 range). However, parameter descriptions are largely absent, most input schemas define types and enums but lack the per-parameter descriptions required by pattern:tool-description. For example, 'merge_strategies' is typed as object but never explained; 'conflict_strategy' vs 'strategy_conflict' in preview_aesthetic_import creates ambiguity without clarification. Output schema is generic (ok, message, passthrough) and does not document the actual response structure agents will receive. Error handling is minimal, no recovery guidance, no actionable error messages, no distinction between retryable vs fatal failures. Tool composition is sound (each tool has one responsibility), but parameter relationships (e.g., when 'pack' vs 'path' should be used) are undocumented.
Compile a named/inline aesthetic or canonical model into portable design tokens and CSS variables.
Advanced: deterministically compile a named/inline aesthetic into a provider payload. No provider HTTP call is made.
Delete a registry document from the active local registry.
Draft a valid composition document without saving it to disk.
Export a named aesthetic and its registry dependencies as a portable .mosvera.json pack.
Fetch a template, modifier, palette, composition, or capability manifest from the active registry.
Parameter descriptions missing across all tools. Input schemas define types and enums but lack descriptions explaining what each parameter controls, expected format, or constraints. E.g., 'merge_strategies' (object type) has no explanation; 'conflict_strategy' vs 'strategy_conflict' in preview_aesthetic_import creates ambiguity.
Output schema is generic and undocumented. All tools return {ok, message, ...passthrough} but the actual response structure (what fields agents receive, their types, how to chain to downstream tools) is not documented. Agents cannot plan downstream calls without knowing response shape.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2025-06-18+ | v2 |
Import an aesthetic pack into the active local registry, writing files and updating manifests.
List named aesthetics available in the active local Mosvera registry.
Preview importing an aesthetic pack into the active local registry without writing files.
Resolve a named or inline aesthetic composition into the canonical Mosvera model.
Create or update a named aesthetic composition in the active local registry.
Advanced: create or update a template, modifier, palette, composition, or capability manifest in the active local registry.
Show the active Mosvera registry path, write mode, versions, document counts, and diagnostics.
Validate an inline or local .mosvera.json aesthetic pack.
Validate one Mosvera document against a schema kind. Invalid documents return valid=false, not a thrown protocol error.
Validate the active local registry and return Mosvera diagnostics.
Advanced: replace the active registry's merge-strategies.json with deterministic JSON.
No error handling guidance. Tools do not document what errors can occur, whether they are retryable, or what the agent should do next. E.g., delete_registry_document offers no recovery path if the document does not exist or deletion fails.
Ambiguous parameter relationships. preview_aesthetic_import and import_aesthetic_pack both accept 'conflict_strategy' and 'strategy_conflict' (same enum values, different names). No documentation explains when to use which or why both exist. Agents will guess incorrectly.
Destructive operations lack confirmation step. delete_registry_document is marked destructiveHint=true but offers no dry-run or confirmation mechanism. Agents can irreversibly delete documents without a safety gate.