Loading ToolBench
Design system governance over MCP. Thirteen tools, not a hundred.
tidy-core demonstrates strong naming conventions (verb_noun pattern: tidy_status, tidy_target, tidy_plan, tidy_apply) and comprehensive parameter descriptions with type constraints (enums, discriminated unions). However, 8 of 13 tools are unimplemented stubs with empty input schemas and placeholder descriptions, severely limiting practical quality assessment. The 5 implemented tools (tidy_status, tidy_target, tidy_context, tidy_plan, tidy_apply) show good schema structure using Zod with detailed parameter docs. Critical gap: no output schemas documented for any tool, responses are JSON-stringified but structure is not formally specified. Error handling is minimal; tools return status objects but lack recovery guidance. Tool descriptions are adequate (100-250 chars) but could better explain WHEN to call each tool vs. alternatives.
[NOT IMPLEMENTED YET] Instance counts, detach rate, override patterns, variant entropy, and the correlation between adoption and health. Persists a measurement on every call, which is what builds the series.
Execute a plan produced by tidy_plan, identified by its hash. This is the only tool in tidy-core that changes anything. It refuses plans it did not generate, plans that have expired, and plans whose targets have changed since the plan was built. On success it writes a decision entry recording what changed and why.
[NOT IMPLEMENTED YET] A ranked worklist: ghost variables, dead styles, unused tokens, raw colors, deprecation candidates. Ranked by impact over effort, not by count.
Get the design system contract in one call: collections, modes, token names grouped by intent, component variant axes, and the naming and binding conventions actually in use. Call this before writing anything into the file. Without it an agent guesses token names, and guessed names are how raw hex ends up in a component.
[NOT IMPLEMENTED YET] Search the decision record, find components with no recorded rationale, and detect decisions that contradict each other. Read-only.
8 of 13 tools are unimplemented stubs (tidy_health, tidy_adoption, tidy_drift, tidy_impact, tidy_cleanup, tidy_decisions, tidy_record_decision, tidy_gate) with empty input schemas ({}) and '[NOT IMPLEMENTED YET]' placeholder descriptions. These cannot be evaluated for quality and will fail at runtime.
No output schemas documented for any tool. Responses are JSON-stringified but the structure (fields, types, required vs optional) is not formally specified. LLMs cannot plan downstream calls or extract data reliably without knowing response shape.
Error handling is minimal. Tools return status objects but do not provide recovery guidance. E.g., tidy_apply refuses expired plans but does not tell the LLM to call tidy_plan again. Errors should classify as retryable/user-fixable/fatal and suggest next steps.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | <=2025-11-25 | v2 |
[NOT IMPLEMENTED YET] One drift report across four surfaces: design versus code specs, versus Storybook, versus docs, and page-to-page inside the file.
[NOT IMPLEMENTED YET] CI and pre-push verdict. Runs drift, cleanup regressions, publish readiness and decision compliance, then passes or fails with reasons.
[NOT IMPLEMENTED YET] Six-category health score plus the delta since the last snapshot plus what caused the delta. Persists a snapshot on every call, so the second run has a delta.
[NOT IMPLEMENTED YET] Blast radius for a token, component or style. What breaks if you rename it, what the migration costs, what the regression risk is. Read-only.
Build a reviewable plan for a set of variable changes, and return a hash for it. Never mutates anything. Covers create, rename, describe, set value, repoint alias and delete. For each target it reports what depends on it (alias references and layer bindings) and flags the risks, including refusing to issue a hash at all when an operation would break something: deleting a variable still in use, aliasing across mismatched types, or overwriting a name that already exists. Pair with tidy_apply, which is the only tool that can execute the plan.
[NOT IMPLEMENTED YET] Record why a change was made. Called automatically by tidy_apply, and manually when a decision happens in a meeting rather than in a diff.
Check where tidy-core is connected and where the next command will land. Read the `routing` field first: it says in plain language which Figma file commands go to. When nothing is connected it returns concrete fixes rather than just `connected: false`.
Pin every subsequent command to one connected Figma file. Accepts a file name (for example 'Design System') or a file key. Call with no arguments to see the current target, or clear: true to unpin. When several files are connected and no target is set, commands fail with a list of the files rather than guessing, because guessing means writing to the wrong file.
Tool descriptions lack WHEN-to-use guidance. E.g., tidy_context says 'Get the design system contract' but does not explain it must be called before tidy_plan, or that it is a prerequisite for safe token naming. Agents cannot infer tool ordering without explicit dependency hints.
tidy_plan and tidy_apply accept optional 'figmaFile' parameter to override target lock, but descriptions do not explain when this is safe or what happens if the file has changed since the plan was built. Undocumented parameter relationships invite misuse.