tidy-core
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| tidy_statusA | Check where tidy-core is connected and where the next command will land. Read the |
| tidy_targetA | 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. |
| tidy_contextA | 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. |
| tidy_planA | Build a reviewable plan for a set of changes, and return a hash for it. Never mutates anything. 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. Pair with tidy_apply, which is the only tool that can execute the plan. |
| tidy_applyA | 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. |
| tidy_healthA | [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. |
| tidy_adoptionC | [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. |
| tidy_driftD | [NOT IMPLEMENTED YET] One drift report across four surfaces: design versus code specs, versus Storybook, versus docs, and page-to-page inside the file. |
| tidy_impactB | [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. |
| tidy_cleanupB | [NOT IMPLEMENTED YET] A ranked worklist: ghost variables, dead styles, unused tokens, raw colors, deprecation candidates. Ranked by impact over effort, not by count. |
| tidy_decisionsA | [NOT IMPLEMENTED YET] Search the decision record, find components with no recorded rationale, and detect decisions that contradict each other. Read-only. |
| tidy_record_decisionA | [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. |
| tidy_gateA | [NOT IMPLEMENTED YET] CI and pre-push verdict. Runs drift, cleanup regressions, publish readiness and decision compliance, then passes or fails with reasons. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Tools like tidy_plan and tidy_apply have clear separation (read vs. execute), and tidy_status/tidy_target handle connection vs. targeting. However, some tools like tidy_health, tidy_impact, and tidy_cleanup all involve analysis of the design system, and their distinct purposes might not be immediately obvious without reading descriptions closely, though descriptions do help.
All tools use the pattern 'tidy_' prefix followed by a lowercase verb or noun in snake_case, e.g., tidy_status, tidy_target, tidy_plan, tidy_apply. This is perfectly consistent and predictable.
13 tools is within the recommended range. However, 8 of them are marked as not implemented yet, which might make the server feel thin in terms of actual functionality, but the planned surface is of appropriate size for a comprehensive design system management toolkit.
The implemented tools cover status, targeting, context, planning, and applying changes, which are core operations. However, many permanent capabilities like adoption, drift, health, impact, cleanup, decisions, and gating are not yet implemented, leaving notable gaps in the intended functionality.