Loading ToolBench
Variant-authority and radix-primitives MCP servers - component contracts that power design-to-code lifecycle tooling
Mixed quality across 9 tools. All tools have descriptions (10 - 194 chars, within baseline range) and basic Zod schemas with parameter descriptions. However, schemas are minimal, most accept only 1 - 2 parameters with generic object types (e.g., 'manifest' as z.record(z.string(), z.unknown())). Output schemas are undocumented; responses are JSON strings, not structured objects. Error handling is present but generic ('not found' messages lack recovery guidance). No tool annotations (readOnlyHint, destructiveHint). set_manifest is a write operation but lacks confirmation/dry-run pattern. Naming is clear and verb-first (get_, set_, list_, diff_, validate_). Composition is reasonable, tools chain logically (get_manifest → validate_usage → set_manifest). No pagination, no batch operations.
Diffs two manifest versions and classifies changes as major, minor, or patch.
Returns known issues, workarounds, and version-specific behavior for a Radix primitive.
Returns the recommended Radix primitive(s) and composition pattern for a given component type.
Returns the full variant manifest for a component: variant definitions, slots, tokens, authority map, and timestamps.
Returns the primitive API, accessibility contract, composition pattern, and known caveats for a Radix UI primitive.
Scans the current working directory for files that import the given component and returns a list of consumer file paths.
Output schemas undocumented. All tools return JSON strings wrapped in content arrays; LLMs cannot parse structure without explicit schema documentation. Responses should be structured objects with typed fields.
set_manifest accepts 'manifest' as z.record(z.string(), z.unknown()), overly permissive. No validation of required fields (component, version, figmaFileKey, etc.) at schema level; validation happens at runtime. Schema should enforce VariantManifest structure.
set_manifest is a destructive write operation but lacks confirmation/dry-run pattern. No tool annotation (destructiveHint). Agents can overwrite manifests without safeguards.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Returns all available Radix primitives with a one-line description.
Writes or updates the registry entry for a component. Validates the manifest before writing.
Validates a usage object against the manifest: checks variant values, required slots, and component-level deprecation. Returns pass or fail with a list of violations.
Error messages are generic ('not found', 'Invalid manifest'). No recovery guidance. E.g., 'Primitive "Dialog" not found. Use list_primitives to see available primitives' is good, but most errors lack this pattern.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot infer which tools are safe to retry or which modify state without explicit hints.