Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Ensemble MCP Build a design system from #0F766E and export it as Tailwind config"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Give your AI agent design taste.
Website · Documentation · Get API Key
Ensemble MCP is a Model Context Protocol server that gives AI agents access to professional design tools. Generate color palettes, pair typography, create shadow systems, and export complete design tokens - all through natural conversation.
10 tools. One API. Infinite possibilities.
Tool | What it does | Its main argument |
| A full color system from one brand color |
|
| Heading, body and mono fonts with a type scale |
|
| A spacing system tuned to the type |
|
| Elevation shadows tinted by the palette |
|
| Responsive grid: breakpoints, columns, gutters |
|
| Durations, easing curves and transition presets |
|
| A complete dark mode from the light system |
|
| Which palette pairs pass WCAG, and what to fix |
|
| The whole system as CSS, JSON, Tailwind or SCSS |
|
| Check one color pair for accessibility (FREE, no key needed) |
|
Every builder takes a brand color and an optional preferences object, so tools called
separately agree with each other. Results are deterministic: the same color and preferences
always give the same system.
------|--------------|
| harmony_generate_palette | Generate harmonious color palettes from a single color |
| duet_pair_fonts | Pair heading and body fonts that complement each other |
| tempo_generate_scale | Create type scales and spacing systems |
| chord_generate_shadows | Generate 5-level shadow elevation systems |
| bridge_generate_theme | Auto-generate dark mode from light theme colors |
| cadence_set_grid | Configure CSS Grid layouts with presets |
| pitch_create_gradient | Create linear, radial, and conic gradients |
| riff_set_easing | Set cubic-bezier easing curves |
| compose_export | Export complete design system (CSS, Tailwind, SCSS, JSON) |
| a11y_validate | Check color contrast accessibility (FREE, no key needed) |
Related MCP server: web-stylebook-mcp
Add to your claude_desktop_config.json:
{
"mcpServers": {
"ensemble": {
"command": "npx",
"args": ["-y", "@hearthbyte/ensemble-mcp"],
"env": {
"ENSEMBLE_API_KEY": "your-api-key-here"
}
}
}
}{
"ensemble": {
"command": "npx",
"args": ["-y", "@hearthbyte/ensemble-mcp"],
"env": {
"ENSEMBLE_API_KEY": "your-api-key-here"
}
}
}npm install -g @hearthbyte/ensemble-mcp
ensemble-mcpOnce installed, try these with your AI:
"Generate a triadic color palette from #6366F1"
"Give me a classical font pairing and an airy spacing system to go with it"
"Check if #FFFFFF text on #6366F1 background is accessible"
"Build a design system from #0F766E with dramatic shadows and export it as Tailwind config"
"Audit the contrast of the palette you just made and tell me what fails"
The builders call the Ensemble API, which needs a Pro key ($4.99/month, or $39/year).
Free tool: a11y_validate - accessibility validation with no API key required.
Ensemble tools are built on these principles:
One color in, design system out - Start with a single value, get a complete system
Cross-tool sync - Colors flow to typography, typography informs spacing
Export everywhere - CSS, Tailwind, SCSS, JSON
Accessibility first - WCAG 2.1 + APCA checking built in
🌐 Ensemble Web Tools - Use in browser, no install
Built with 🧡 by HearthByte
Your work. Your choice. Always.
Check one foreground and background color pair for accessibility (WCAG 2.1 and APCA).
FREE - No API key required.
Returns the contrast ratio, pass or fail for normal and large text, and suggested fixes.
| Name | Required | Description | Default |
|---|---|---|---|
| fontSize | No | Font size in pixels (affects the large-text thresholds) | |
| algorithm | No | Contrast algorithm (default: both) | |
| background | Yes | Background color in hex | |
| foreground | Yes | Text color in hex |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does well: it discloses that the tool is read-only in effect (a check/compute that needs no API key), names the two algorithms, and describes the return content (contrast ratio, pass/fail for normal and large text, suggested fixes). It does not mention error handling for malformed hex, which is the main remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded lines: purpose first, then the cost/auth note, then the return shape. Every sentence earns its place and nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description explicitly enumerates the return values, so an agent knows what to expect from a four-parameter computation tool. Only edge-case/error behavior is unspecified, a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents foreground/background hex, fontSize pixels, and the algorithm enum. The description only alludes to large-text thresholds and algorithm choice, adding no syntax or format detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Check) and a precisely scoped resource (one foreground/background color pair) and names the standards covered (WCAG 2.1 and APCA). The 'one ... pair' scoping cleanly distinguishes it from the sibling pitch_audit_contrast, which implies bulk auditing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Check one foreground and background color pair' implies the single-pair use case, and 'FREE - No API key required' gives a practical prerequisite. There is no explicit guidance on when to prefer this over pitch_audit_contrast or which algorithm enum value to choose for a given situation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a complete dark mode from the light system built on a brand color: dark surfaces and text, adjusted palette, shadows and spacing, with contrast checked.
| Name | Required | Description | Default |
|---|---|---|---|
| color | Yes | Brand color in hex (e.g. #6366F1). The whole system is built from it. | |
| colors | No | Additional brand colors in hex (up to 5 colors in total, including `color`). | |
| preferences | No | Other design preferences, so tools called separately stay consistent with each other. Pass the same values to every tool. | |
| color_scheme | No | The palette the dark theme is derived from (default analogous) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the output contents (surfaces, text, palette, shadows, spacing) and that contrast is validated internally. However, it says nothing about determinism, output format/side effects, or whether it writes files or returns a spec, which an agent would want to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence listing the generated artifacts with zero preamble or filler. It is dense but every clause (surfaces/text, palette, shadows, spacing, contrast) maps to real output, so nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with a nested preferences object, the description adequately conveys what is produced and the schema fully documents inputs, and no output schema means return values need not be explained. The remaining gaps are behavioral (output format, side effects) and routing against the ten sibling generators, which leave the definition only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents color, colors, preferences, and the color_scheme enum in detail. The description adds only the framing that the system is 'built on a brand color,' which is already in the schema. Baseline 3 is correct when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Generate) and resource (a complete dark mode theme), enumerating the concrete artifacts produced: dark surfaces and text, adjusted palette, shadows, spacing, with contrast checked. This makes it distinguishable from narrower siblings like harmony_generate_palette or chord_generate_shadows, though it never explicitly names or routes against them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no exclusions, and no mention of the alternatives among the many generation siblings (harmony_generate_palette, chord_generate_shadows, pitch_audit_contrast, etc.). 'Contrast checked' weakly implies pitch_audit_contrast may be redundant, but this is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a responsive grid: breakpoints, column counts, gutters and max widths, sized from the spacing system.
density: compact, balanced (the default), airy.
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | Brand color in hex. Optional here; defaults to #3B82F6. | |
| colors | No | Additional brand colors in hex (up to 5 colors in total, including `color`). | |
| density | No | How tight or generous the gutters are (default balanced) | |
| preferences | No | Other design preferences, so tools called separately stay consistent with each other. Pass the same values to every tool. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses what is generated and that sizing derives from the spacing system, but it does not explain side effects, permissions, return format, or whether the operation is read-only or deterministic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. The density line is partly redundant with the schema enum, but overall it remains tight and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should ideally clarify the return format or how the generated grid is consumed. It names the grid components but omits integration details such as whether preferences affect grid output or how results are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameter documentation is already handled by the schema. The description repeats the density options and default, but adds no meaningful semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: generating a responsive grid, and names the concrete outputs: breakpoints, column counts, gutters, and max widths. It also distinguishes the tool from siblings like palette, font, shadow, and motion generators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not say when to use this tool versus alternatives, nor does it state prerequisites or exclusions. Usage is only implied by the tool name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a shadow and elevation system tinted by the palette: elevation levels, a focus ring and a glow.
shadow_intensity: flat (borders, no depth), subtle (the default), pronounced, dramatic.
| Name | Required | Description | Default |
|---|---|---|---|
| color | Yes | Brand color in hex (e.g. #6366F1). The whole system is built from it. | |
| colors | No | Additional brand colors in hex (up to 5 colors in total, including `color`). | |
| preferences | No | Other design preferences, so tools called separately stay consistent with each other. Pass the same values to every tool. | |
| color_scheme | No | The palette the shadows are tinted from (default analogous) | |
| shadow_intensity | No | How strong the elevation shadows are (default subtle) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the produced artifacts (elevation levels, focus ring, glow), which is useful, but says nothing about determinism, whether the palette is derived or required as input, or what form the result takes. Adequate but thin for a generator with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler. The shadow_intensity legend slightly duplicates the enum in the schema, but it is compact and arguably adds nuance, so it still earns its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should ideally convey the return shape (design tokens, CSS variables, etc.) and how the extracted shadow system is meant to be consumed. It names the artifacts but not their format, leaving a real gap for a nested-object, no-output-schema generator.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented. The description adds a small amount of meaning for shadow_intensity ("flat (borders, no depth)"), but does not explain the relationship between the top-level color_scheme/shadow_intensity and their duplicates inside preferences, which is the genuinely ambiguous part of this schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Generate a shadow and elevation system") and names the concrete artifacts it produces — elevation levels, focus ring, glow. It clearly separates this from palette/type/grid siblings by output domain, though it doesn't explicitly name a sibling it differs from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites (e.g. that a palette must exist first), and no mention of alternatives among the nine siblings. The second paragraph only enumerates shadow_intensity values, which is reference data rather than invocation guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build the whole design system from one brand color and export it: colors, typography, spacing, shadows, grid, motion and accessibility notes, as ready-to-use files.
formats: css (custom properties), json, tailwind (config) and scss. Pass the same preferences you used with the other tools so the export matches them.
| Name | Required | Description | Default |
|---|---|---|---|
| color | Yes | Brand color in hex (e.g. #6366F1). The whole system is built from it. | |
| colors | No | Additional brand colors in hex (up to 5 colors in total, including `color`). | |
| corners | No | Corner radius character (default rounded) | |
| density | No | Spacing density (default balanced) | |
| formats | No | Export formats (default ["css", "json"]) | |
| type_style | No | Typography character (default modern) | |
| preferences | No | Other design preferences, so tools called separately stay consistent with each other. Pass the same values to every tool. | |
| color_scheme | No | How the palette is derived (default analogous) | |
| animation_style | No | Motion character (default minimal) | |
| shadow_intensity | No | Shadow strength (default subtle) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses what gets generated and the available export formats, but says nothing about how the output is delivered (inline strings vs. files), whether generation is deterministic, or any limits/auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight paragraphs, front-loaded with the core action and followed by the format list and the preference-consistency note. No filler sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter, nested-schema tool with no output schema, the description should say more about what the caller receives (file contents, paths, bundle). It covers formats and preference reuse but leaves the return shape unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented with defaults and enum meanings; the baseline of 3 applies. The description restates the format list but adds no syntax or interaction detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: build a whole design system from one brand color and export it as files, enumerating what is produced (colors, typography, spacing, shadows, grid, motion, accessibility). This implicitly distinguishes it from siblings that each generate a single artifact, though it never names them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: 'Pass the same preferences you used with the other tools so the export matches them,' which is a concrete coordination instruction. It lacks an explicit when-not or a named alternative for partial exports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pick a heading, body and monospace font pairing with a type scale, chosen for a typographic character.
type_style: modern (clean sans), classical (serif-led), minimalist (restrained), expressive (display-led). Returns font families, weights, fallbacks and the size scale.
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | Brand color in hex. Optional here; defaults to #3B82F6. | |
| colors | No | Additional brand colors in hex (up to 5 colors in total, including `color`). | |
| type_style | No | The typographic character to pair for (default modern) | |
| preferences | No | Other design preferences, so tools called separately stay consistent with each other. Pass the same values to every tool. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does disclose the return contents (font families, weights, fallbacks, size scale), which is useful, but says nothing about determinism, whether results are idempotent for the same type_style, or what happens with no parameters at all (all optional). Adequate but incomplete for an annotation-free tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the purpose is front-loaded, followed by the enum glossary and the return summary. No filler, though the enum expansion is slightly list-like rather than prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by naming the returned artifacts, and the nested preferences object is fully documented in the schema. Missing only edge-behavior details (defaults when nothing is passed, determinism) for a fully self-contained definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the description earns above baseline by expanding the type_style enum into meaningful characterizations (clean sans, serif-led, restrained, display-led). It also frames the preferences object's purpose (consistency across sibling tools) that the schema only partially conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: pick a heading/body/monospace font pairing with a type scale. The resource (typography pairing) is clearly distinct from sibling resources like palettes, shadows, grids and motion. It does not explicitly name or disambiguate from siblings, but the resource alone is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The type_style enum values are glossed (modern = clean sans, classical = serif-led, etc.), which implies when each mode applies, but there is no explicit guidance on when to call this tool versus a sibling, nor any prerequisites or exclusions. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a working color system from one brand color: primary, secondary and accent ramps, neutrals, and semantic colors (success, warning, error, info).
color_scheme decides how the secondary and accent hues are derived: • monochromatic — one hue, many shades (elegant, unified) • analogous — neighbors on the wheel (calm, cohesive; the default) • complementary — the opposite hue (high contrast) • triadic — three evenly spaced hues (balanced, colorful) • split-complementary — the two hues beside the complement (nuanced contrast)
| Name | Required | Description | Default |
|---|---|---|---|
| color | Yes | Brand color in hex (e.g. #6366F1). The whole system is built from it. | |
| colors | No | Additional brand colors in hex (up to 5 colors in total, including `color`). | |
| preferences | No | Other design preferences, so tools called separately stay consistent with each other. Pass the same values to every tool. | |
| color_scheme | No | How the palette is derived from the brand color (default analogous) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the burden. It discloses real behavioral content — that the scheme choice determines how secondary/accent hues are derived and the character of each option — but says nothing about determinism, whether output is tokens or raw hex, or how multiple input colors interact. Return behavior is entirely undisclosed and no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the outcome, then a tight bulleted list that earns its space by disambiguating the non-obvious enum. Slight redundancy: color_scheme is described both at top level and inside preferences, and its enum values are repeated in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a generation tool with no annotations and no output schema, the description covers inputs well but leaves the return value opaque — an agent cannot tell whether it receives hex ramps, design tokens, or a theme object. The nested preferences object is only lightly explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description goes beyond the schema by explaining what each color_scheme enum value actually produces (elegant/unified, calm/cohesive, high contrast, balanced, nuanced). The other parameters (corners, density, type_style, etc.) get no added meaning in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb (generate) and resource (working color system) and enumerates exactly what ships: primary/secondary/accent ramps, neutrals, semantic colors. Combined with the sibling set (fonts, scale, shadows, motion), an agent can tell this is the palette tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use/when-not and no named alternative among siblings. The one piece of guidance, that preferences should be passed identically to every tool for cross-tool consistency, is useful workflow context but not routing advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit the contrast of the palette built from a brand color: which text and background pairs pass WCAG, which fail, and what to change. Returns a contrast matrix, the failures and recommendations.
To check one specific foreground and background pair, use a11y_validate (free, no key). audit_all_combinations checks every pair in the palette, not just the meaningful ones.
| Name | Required | Description | Default |
|---|---|---|---|
| color | Yes | Brand color in hex (e.g. #6366F1). The whole system is built from it. | |
| colors | No | Additional brand colors in hex (up to 5 colors in total, including `color`). | |
| preferences | No | Other design preferences, so tools called separately stay consistent with each other. Pass the same values to every tool. | |
| color_scheme | No | The palette to audit (default analogous) | |
| contrast_algorithm | No | wcag2 (the default) or apca | |
| audit_all_combinations | No | Check every pair in the palette, not just the meaningful ones |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses output structure (contrast matrix, failures, recommendations), which tells the agent what to expect. It omits access/permission or rate-limit context, but the audit framing makes the read-only, non-destructive nature evident.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. Purpose and deliverable are front-loaded, and the second sentence is devoted entirely to routing the agent to the correct sibling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter tool with a nested preferences object and no output schema, the description supplies the return shape and the key alternative-routing context. It is nearly complete; only authentication/usage constraints are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well documented, including enum meanings. The description adds no syntax or format detail for color/colors beyond what the schema provides. Baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Audit the contrast') on a specific resource ('the palette built from a brand color') and enumerates the deliverable (pass/fail pairs, what to change). It is immediately distinguishable from a11y_validate (single pair) and audit_all_combinations (every pair).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: use a11y_validate for a single foreground/background pair, and notes audit_all_combinations covers every pair rather than the meaningful ones. Conditions for choosing alternatives are stated, not implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a motion system: durations, easing curves (cubic-bezier) and ready-made transition presets.
animation_style: none (reduced motion), minimal (the default), fluid (smooth, longer), energetic (snappy, springy).
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | Brand color in hex. Optional here; defaults to #3B82F6. | |
| colors | No | Additional brand colors in hex (up to 5 colors in total, including `color`). | |
| preferences | No | Other design preferences, so tools called separately stay consistent with each other. Pass the same values to every tool. | |
| animation_style | No | The character of the motion (default minimal) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden and does not meet it. It never says whether this is a pure generation call, what the returned tokens look like, whether anything is written or persisted, or how the result interacts with the separately generated theme.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short lines, front-loaded with the deliverable and with zero filler. The second line is spent entirely on one parameter's values while the other four go unmentioned, which is a reasonable but slightly lopsided allocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter, all-optional generation tool with no annotations and no output schema, the description covers purpose and one enum well but omits the nature of the return value and any consistency contract beyond the schema's note about passing the same preferences to every tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the 3 baseline applies; the description exceeds it by explaining each animation_style value qualitatively — none as reduced motion, fluid as smooth/longer, energetic as snappy/springy — which the schema only labels as 'Motion character'. It stops short of explaining how animation_style differs from preferences.animation_style, which is left to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — generate a motion system — and enumerates the concrete artifacts produced (durations, cubic-bezier easing curves, transition presets). The motion/animation domain is clearly distinct from the sibling resources (palette, fonts, scale, shadows, grid), though the description never names an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance, no prerequisites, and no routing to alternatives such as bridge_generate_theme or compose_export. The description only enumerates option values, which is parameter information rather than usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a spacing system tuned to the type: a base unit, a spacing scale, semantic spacing (padding, gaps, sections) and layout measures.
density: compact (dense UIs), balanced (the default), airy (generous whitespace).
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | Brand color in hex. Optional here; defaults to #3B82F6. | |
| colors | No | Additional brand colors in hex (up to 5 colors in total, including `color`). | |
| density | No | How tight or generous the spacing is (default balanced) | |
| type_style | No | The typography the spacing is tuned to (default modern) | |
| preferences | No | Other design preferences, so tools called separately stay consistent with each other. Pass the same values to every tool. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the artifact set the tool emits, but says nothing about determinism, whether repeated calls are stable, or side effects. For a pure generation tool the risk is low, so this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core purpose front-loaded. The second line singling out only density is slightly unbalanced against the five-parameter surface, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the output artifacts, which matters since there is no output schema. However, the nested preferences object and the other enum parameters are left entirely to the schema, and no guidance ties the tool to its many generate-* siblings, so the definition is adequate rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds modest value by expanding 'balanced' into 'the default' and giving intuitive glosses ('dense UIs', 'generous whitespace') for the density enum, but it ignores the other four parameters and the nested preferences object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Generate') and resource ('a spacing system'), then enumerates the concrete outputs: base unit, spacing scale, semantic spacing, and layout measures. This distinguishes it from most siblings, though it never names the closest alternatives (cadence_generate_grid, bridge_generate_theme) that might also touch spacing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'tuned to the type' hints that type_style drives the result, but there is no explicit when-to-use guidance, no prerequisites, and no routing to or away from siblings. The density line explains an option rather than saying when to pick this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0a11y_validatebridge_generate_themecadence_generate_gridchord_generate_shadowscompose_exportduet_pair_fontsharmony_generate_palettepitch_audit_contrastriff_generate_motiontempo_generate_scaleScored across 10 tools
Each tool targets a clearly distinct part of the design system lifecycle: palette, typography, spacing, shadows, grid, motion, dark mode, contrast audit, export, and standalone a11y validation. The only mild overlap is between pitch_audit_contrast and a11y_validate, but their descriptions clearly distinguish full-palette auditing from single-pair checking.
All names use lowercase snake_case with a consistent [prefix]_[verb]_[object] structure for most tools. Minor deviations exist: a11y_validate drops the musical prefix, and compose_export lacks an object noun, but the overall pattern remains predictable and readable.
Ten tools is well-scoped for generating a complete design system from one brand color. Each tool maps to a necessary subsystem or audit step, and none feel redundant or excessive.
The surface covers all major design-system token categories named in the export description: colors, typography, spacing, shadows, grid, motion, accessibility, and dark mode. The inclusion of both a full-palette contrast audit and a free single-pair validator makes the accessibility workflow robust with no obvious dead ends.
Give your agent a real design system: tokens, measured WCAG contrast, and rules to follow.
Build and manage your design system with AI: tokens, themes, components, icons, Figma and code.
Generate design systems: OKLCH colors, fluid type scales, spacing, shape, icon and motion tokens.
Give your AI agents a design superpower. Generate, edit, and publish publication-grade decks, reports, landing pages, resumes, and marketing visuals directly within your agent workflow. Delivering frontier-level design quality at 3× the speed and 53× lower cost -from conversational prompt to live link or vector PDF in minutes.
