Loading ToolBench
A persistent design layer for your codebase, driven by the agent you already use. Provides tools for design system management, page creation, token management, asset handling, and user interviews.
Caret MCP server demonstrates solid tool design with 24 well-named, action-verb tools covering design system operations. All tools have descriptions (avg 180 chars, within 10-1024 baseline). Input schemas are present and typed with Zod validation. However, output schemas are not documented in the visible code, LLMs cannot predict return structures. Parameter descriptions are present but inconsistent in depth. Error handling guidance is minimal. Tool composition is strong (each does one thing), but some tools like propose_variants and propose_design_update lack clarity on expected return formats and error recovery paths.
Writes the foundation the user picked and regenerates the rules files every agent session reads. Call this immediately after present_options returns a candidateId — an interview that is never committed leaves the project with no foundations at all.
Completes a sync operation and applies the proposed changes to the design layer.
Writes a new page to the design layer. The source is a React component; the metadata declares its place in the flow and any states it supports. Returns the page id and the full metadata so you can see what was written.
Writes or updates the description and tags of an asset. The asset must already exist in the library; to add a new one, use generate_asset.
Generates a new asset (image, icon, or 3D model) and adds it to the library. Returns the asset tag and metadata.
Output schemas not documented. LLMs cannot predict return structures for tools like get_project, get_page, propose_variants, propose_design_update. This forces agents to guess at response fields and risks failed downstream tool calls.
Sync workflow tools (start_sync, propose_design_update, report_sync_mapping, complete_sync) lack error recovery guidance. If a sync fails mid-operation, LLMs have no guidance on rollback or retry strategy.
propose_variants and propose_design_update descriptions are vague about what 'proposals' or 'changes' are. No schema shown for the 'changes' array structure or expected proposal format. LLMs cannot validate input or interpret results.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
The asset library: every image, icon, or 3D model in this project, with its metadata and where it is used.
The flow graph (which page leads where, including error paths) and each page's declared states.
The prose guide to this project's design system — the part that genuinely needs reading rather than parsing. Includes the design principles, usage notes, and any custom guidance the team has written.
The full source and metadata of a single design page.
The structure of this project's design layer: every page with its metadata, every flow, and the current sync state. Call this first — it is the map.
A rendered screenshot of a design page's FULL scroll height, captured fresh at 1440px wide and delivered as 900px-tall frames (top to bottom) so nothing is downscaled. A long page arrives in parts; the result says how many frames remain and which part to request next. Use this to look at your own work: after writing a page, screenshot it and check the whole page renders the way you intended.
This project's foundation tokens — colour, typography, spacing, radius. These are binding: styling that does not come from here will look wrong next to everything that does.
Installs an allowlisted catalog component into this project. The component must be in Caret's curated catalog; arbitrary npm packages are not supported.
Shows two to six assets that are ALREADY in this project's library as options against one question ("Which hero image?") and waits for the user to pick. It renders in the chat beside the canvas, so use it mid-conversation whenever a plan turns on which existing asset to use — do not make the user open the Assets tab to answer. Tags must name assets that exist; to make a new one, use generate_asset instead. Returns the picked tag, or null when the user dismissed the choice.
Renders complete foundations as live specimens — real typefaces, palettes applied to sample components — and waits for the user to point at one. Pass the vibe tags you inferred from their answers and Caret narrows its curated library; you cannot pass your own colours or font names, by design. Returns the chosen candidate id for commit_foundation. Tags are matched exactly against a fixed vocabulary, so use words FROM THIS LIST ONLY: ${LIBRARY_TAGS.join(", ")} Pick the 3-6 that best fit what the user told you. Tags outside this list are rejected rather than silently ignored.
Shows the user a plain-language question with a few choices and waits for them to pick. Use this to run the foundation interview. Ask about the product and how it should feel — never about design terms like type scale, radius or saturation, which the user has no way to answer. Caret's suggested questions are in the caret://interview prompt.
Proposes a design update to reconcile the design layer with changes in the codebase. Part of the sync workflow.
Asks the agent to generate design variants for a page or component. Returns a set of proposals the user can review and accept.
Reports the mapping between design pages and codebase components during a sync operation.
Sets a parameter value on a page or component instance. Parameters are the design-time knobs that control how a component renders.
Begins a sync operation to detect changes in the codebase and propose design updates. Returns a sync id and the list of changes detected.
Writes new foundation tokens. The tokens are binding — every page that does not style from here will look wrong next to everything that does. Pass the whole token tree; partial updates are not supported.
Writes or updates a flow definition. A flow is a graph of pages and transitions; this tool creates one or updates an existing one by id.
Overwrites an existing page's source and metadata. The page must already exist; to make a new one, use create_page. Returns the full metadata so you can see what was written.
present_options enforces a fixed vocabulary (LIBRARY_TAGS) but the description does not explain what happens if an LLM passes an invalid tag. Does it silently ignore? Reject? Return an error? This ambiguity invites misuse.
No tool supports dry-run or confirmation for destructive operations (write_page, update_tokens, write_flow, complete_sync). Agents can irreversibly overwrite design state without user confirmation.