Generate design systems: OKLCH colors, fluid type scales, spacing, shape, icon and motion tokens.
Scored across 10 tools
Each generate_* tool targets a clearly distinct token category (color, icon, motion, shape, space, type), and the read tools (get_design_system, export_design_system, get_design_rules, list_fonts) have well-separated purposes — decode vs. export vs. guidance vs. catalog lookup. Descriptions explicitly cross-reference each other (e.g. 'Use export_design_system for full CSS'), further reducing misselection risk.
Uniform snake_case verb_noun pattern throughout: generate_*, get_*, export_*, list_*. The generate_* family is highly predictable, and get_design_rules/get_design_system are parallel siblings. Noun variation (tokens/scale/palette) is intentional and still readable.
10 tools is a well-scoped, comfortable number for a design-system server, with each tool earning its place across a single coherent domain. No redundancy or filler tools are present.
The surface covers the full design-token lifecycle (generate individual token types, export combined code, decode/overview an existing system, rules, and font catalog), which is strong for the domain. Minor gaps exist — no explicit accessibility/contrast or shadow-only generation beyond shape tokens — but agents can work around these.
Generate the full token code for a design system URL in one format: "css" (CSS custom properties incl. semantic shadcn/ui-compatible tokens), "tailwind" (Tailwind v4 @theme), "design-tokens" (W3C DTCG JSON — typography, spacing & layout, shape, icons and motion; color is not part of it), "llm-briefing" (Markdown brief for AI code generation), or "font-embed" (Fontshare snippet). Optionally restrict to specific sections. Every format carries the standby.design/system share link. Always give that URL to the user alongside the code and keep it as a comment in the theme file of the target project — the link is the deliverable.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A standby.design URL or raw unified hash. | |
| format | Yes | Output format. | |
| sections | No | Which sections to include. Honoured by "css", "tailwind", "llm-briefing" and "design-tokens" (which has no color section). By default color, type, space, shape and motion are always included — with their defaults when the URL does not configure them — and symbol only when the URL configures it. Ignored by "font-embed". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds real context: every format carries the share link, that link must be surfaced to the user and kept as a comment in the theme file, and it is framed as the deliverable. It also discloses a non-obvious trait — design-tokens excludes color.
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 core action and format list, then the sections note, then the share-link instruction. Dense but every sentence carries operational value; the closing two sentences are slightly repetitive about the same link obligation.
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 describing what each format returns and how the sections filter behaves (and that font-embed ignores it). An agent has enough to invoke and to explain the result, though nothing is said about size/rate limits for large exports.
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, but the description goes beyond the enum by explaining what each format's payload contains (e.g., DTCG covers typography, spacing/layout, shape, icons, motion but not color) and that sections are optional. It does not add syntax details for 'url' beyond the schema's 'standby.design URL or raw unified hash'.
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?
Starts with a specific verb+resource: 'Generate the full token code for a design system URL in one format.' The word 'full' plus the per-format enumeration distinguishes it from siblings like generate_color_palette or generate_type_scale, which produce single sections.
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?
Each of the five formats is described with what it produces and who it's for (shadcn/ui tokens, Tailwind v4 @theme, W3C DTCG, AI briefings, Fontshare snippet), which effectively tells the agent when each choice applies. It does not explicitly state when to prefer this tool over the section-specific siblings, so no exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a perceptually uniform OKLCH color palette from a brand color: 18-step scales for brand/surface/error/accents, semantic tokens (shadcn/ui compatible), light+dark modes. Returns a shareable standby.design/system URL and a compact summary. Always give that URL to the user — the link is the deliverable; it opens the live system in the browser. Use export_design_system for full CSS/Tailwind output.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Existing standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing/motion settings from other tools are preserved. Omit to start fresh from defaults. | |
| mode | No | "balanced": step 500 is always the perceptual midpoint (even light/dark distribution). "exact": step 500 keeps the input color's lightness. | |
| accents | No | Up to 10 additional named accent colors. Replaces the existing accent list when provided; pass [] to remove all accents. Default: Success/Warning/Info, auto-derived. | |
| brandHex | No | Brand color as 6-digit hex, e.g. "#335A7F". The palette midpoint is derived from this. | |
| brandPin | No | Pin the primary token to the exact input hex instead of the palette step. | |
| errorPin | No | ||
| themeName | No | Name of the design system (appears in exports and page title). | |
| bgColorHex | No | Surface tint color as hex, or "auto" to derive from the brand color (default). | |
| brandInvert | No | For pinned brand: mirror lightness in dark mode (e.g. black buttons in light mode, white in dark). | |
| chromaScale | No | Surface saturation 0–1 (0 = grey surfaces, 1 = vibrant). Default 0.25. | |
| errorInvert | No | ||
| errorColorHex | No | Error/destructive color as hex, or "auto" to derive from the brand hue (default). | |
| fgContrastMode | No | Text color strategy on colored backgrounds. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only carry readOnlyHint/openWorldHint, so the description usefully adds that the output is a URL plus a compact summary and that the URL is the actual deliverable that opens a live system. It does not discuss auth, latency, or state persistence (whether the 'modify' via url param is server-side or hash-encoded), leaving a small 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 tight sentences, front-loaded with what is generated and what is returned, then the agent instruction. No filler, and the alternative tool is mentioned last where it does not dilute the primary purpose.
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 13-param tool with no output schema, the description covers the essential missing piece (what is returned: URL + summary) and defers per-field semantics to the 85%-covered schema. It stops short of explaining interactions between params (e.g. brandPin with brandInvert), so it is strong but not exhaustive.
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 85%, so the schema already documents params like mode, accents, chromaScale and the pin/invert flags in depth. The description adds almost no parameter-level detail beyond restating that scales derive from the brand color, so the baseline 3 is appropriate.
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 (OKLCH color palette) with concrete scope: 18-step scales, semantic tokens, light+dark modes. It also names its outcome artifact (a shareable standby.design URL), which lets an agent distinguish it from siblings like export_design_system.
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 export_design_system for full CSS/Tailwind output' names the alternative and the condition selecting it, and 'Always give that URL to the user' prescribes post-invocation behavior. This is exactly the when/when-not guidance the dimension asks for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pick an icon set and generate icon sizing tokens (xs–2xl + stroke width). Either select a specific set or state style preferences and get a recommendation. Available sets: material-outlined, material-filled, lucide, phosphor-regular, phosphor-bold, phosphor-thin, phosphor-fill, solar-linear, solar-bold, solar-broken, tabler-outline, tabler-filled, radix. Returns a shareable standby.design/system URL and a summary. Always give that URL to the user — the link is the deliverable.
| Name | Required | Description | Default |
|---|---|---|---|
| set | No | Icon set variant id to select explicitly, e.g. "material-outlined". One of: material-outlined, material-filled, lucide, phosphor-regular, phosphor-bold, phosphor-thin, phosphor-fill, solar-linear, solar-bold, solar-broken, tabler-outline, tabler-filled, radix. Pass "auto" to clear the selection and use the recommendation instead. | |
| url | No | Existing standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing/motion settings from other tools are preserved. Omit to start fresh from defaults. | |
| scale | No | Size scale ratio (default 1.272). | |
| style | No | Preferred icon style for the recommendation. | |
| weight | No | Preferred stroke weight. | |
| corners | No | Preferred corner style (sharp = corporate/precise, rounded = friendly). | |
| baseSize | No | Base icon size (md) in rem (default 1.25). | |
| snapTo4px | No | Round sizes to the 4px grid (default true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, and the description aligns with that by describing a generation action with a URL as deliverable, not a system mutation. It adds the crucial instruction to always return the URL, and explains preservation behavior when a URL is passed. This goes beyond what annotations provide.
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 moderately long but every sentence serves a purpose: listing sets, explaining usage modes, and highlighting the deliverable. It is front-loaded with the core function. It could be slightly tightened, but it avoids fluff.
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 8 parameters and no output schema, the description effectively covers what the tool returns (URL and summary) and how to handle the URL param. It also explains the 'auto' selection mechanism. An agent has enough context to invoke it correctly without missing critical information.
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 all parameters are described in the schema. The description adds value by explaining the 'auto' semantics for set/style/weight/corners, and gives concrete meaning for corners ('sharp = corporate/precise, rounded = friendly'). This enriches the schema without redundancy.
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 the specific verb and resource: 'Pick an icon set and generate icon sizing tokens (xs–2xl + stroke width).' It also lists the available sets and the deliverable (URL and summary). This clearly distinguishes it from sibling tools like generate_shape_tokens or generate_motion_tokens.
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 explains two usage paths: select a specific set or provide style preferences for a recommendation. It also clarifies the behavior of the 'set' parameter with 'auto', and notes that modifying an existing URL only changes this tool's section. It does not explicitly exclude other tools, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate spring-based motion tokens from two brand-character axes: energy (calm → lively, sets the tempo) and material (firm → elastic, sets how much spatial motion overshoots). Returns 6 primitive springs (spatial/effect × fast/default/slow), 11 semantic tokens (press, move, expand, enter, exit, fade, navigate., sheet., container) and the reduced-motion rule. Start from a preset, then fine-tune with energy/material. Returns a shareable standby.design/system URL and a summary. Always give that URL to the user — the link is the deliverable. Use export_design_system for CSS, design tokens or the LLM briefing; SwiftUI, Compose and Motion (JS) code is exported in the UI at standby.design/motion.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Existing standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing/motion settings from other tools are preserved. Omit to start fresh from defaults. | |
| energy | No | 0 = calm (slow, deliberate) … 100 = lively (quick, snappy). Default 50. | |
| preset | No | Starting character. "calm-firm" (energy 15, material 15; premium, finance, luxury), "calm-elastic" (energy 15, material 85; wellness, lifestyle), "balanced" (energy 50, material 50; most products), "lively-firm" (energy 85, material 15; productivity, sports, dev tools), "lively-elastic" (energy 85, material 85; playful consumer apps, games). energy/material override the preset. | |
| material | No | 0 = firm (no overshoot) … 100 = elastic (visible bounce on spatial motion). Default 50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false; the description is consistent with that by framing the operation as generation and returning a URL/summary. It adds useful behavioral context beyond annotations, such as the deliverable being the shareable URL and the instruction to always give that URL to the user, plus the exact output composition. No contradiction found.
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?
Every sentence earns its place: scope, output breakdown, workflow, deliverable emphasis, and routing to alternatives. It is detailed but tightly structured, with no filler or repeated boilerplate.
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 four optional parameters with 100% schema coverage, no output schema, and annotations covering safety, the description is complete for invocation. It states what is returned, what the deliverable is, which code exports are handled elsewhere, and how to start, making it sufficient for an agent to select and call correctly.
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 baseline is 3. The description raises this slightly by mapping the axes to experience ('energy ... sets the tempo', 'material ... sets how much spatial motion overshoots') and by prescribing the parameter relationship: 'Start from a preset, then fine-tune with energy/material.' These are meaningful, though partially redundant with the rich schema descriptions.
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 opens with a specific verb and resource: 'Generate spring-based motion tokens' from two named axes. It enumerates exact outputs (6 primitive springs, 11 semantic tokens, reduced-motion rule), which clearly distinguishes it from the color/icon/shape/space/type generator siblings and from export_design_system.
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 an explicit workflow: 'Start from a preset, then fine-tune with energy/material.' It also names an alternative and the condition for using it: 'Use export_design_system for CSS, design tokens or the LLM briefing; SwiftUI, Compose and Motion (JS) code is exported in the UI at standby.design/motion.' This tells the agent when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate shape tokens — radii, shadows, borders, focus rings — in one of four visual styles: "paper" (classic surfaces with layered shadows), "glass" (liquid glass), "neomorph" (soft neumorphism), "neobrutalism" (hard offset shadows). Returns a shareable standby.design/system URL and a summary. Always give that URL to the user — the link is the deliverable.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Existing standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing/motion settings from other tools are preserved. Omit to start fresh from defaults. | |
| style | No | Top-level visual style (default "paper"). | |
| glassBlur | No | Glass backdrop blur (default 1.0). | |
| ringStyle | No | Focus ring shape: "soft" (default) is a translucent halo at the edge plus a full-color border, "solid" is a hard outline set off by ringOffset. | |
| ringWidth | No | Focus ring width in px (default 2). | |
| glassDepth | No | Glass displacement intensity (default 0.2). | |
| ringOffset | No | Focus ring offset in px (default 2). | |
| shadowType | No | Shadow rendering for paper style. | |
| borderWidth | No | Border width in px (default 1). | |
| shadowScale | No | Elevation level spread ratio (default 1.272). | |
| borderRadius | No | Base radius in px; scales to a xs–xl radius set (default 8). | |
| ringColorHex | No | Custom focus ring color as hex, or "auto" (default). | |
| borderEnabled | No | ||
| shadowEnabled | No | ||
| shadowOffsetX | No | Brutalist shadow X offset in px (default 2). | |
| shadowOffsetY | No | Brutalist shadow Y offset in px (default 4). | |
| borderColorHex | No | Custom border color as hex, or "auto" (default). | |
| separationMode | No | How surfaces separate from the background. | |
| shadowColorHex | No | Custom shadow color as hex, or "auto" (default). | |
| shadowStrength | No | Shadow alpha multiplier (default 1.0). | |
| glassDispersion | No | Chromatic aberration intensity (default 0.5). | |
| shadowBlurScale | No | Shadow blur multiplier (default 1.0). | |
| brutalistVariant | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description adds real behavioral context: it returns a shareable standby.design/system URL plus a summary, and stresses that the URL is the deliverable and must be surfaced to the user. It does not, however, describe how the modify-existing-URL flow behaves in prose (the schema carries that).
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 sentences that are front-loaded with the verb and resource, followed by return behavior and the critical hand-off instruction. The style list is slightly dense but each parenthetical carries distinct meaning, and nothing is filler.
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 23-parameter tool with no output schema, the description covers the essentials: what it generates, the style taxonomy, and what it returns. It is nearly complete, missing only routing guidance among the sibling generator/token tools.
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 87%, so the baseline is 3. The description earns an extra point by going beyond the bare enum and explaining what each style means ('paper' = layered shadows, 'glass' = liquid glass, 'neomorph' = soft neumorphism, 'neobrutalism' = hard offset shadows), which is genuine semantic value for the most important parameter.
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 (shape tokens) and enumerates the sub-resources it covers — radii, shadows, borders, focus rings. The four named styles further distinguish it from siblings like generate_color_palette or generate_type_scale without needing to open any 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?
The description tells the agent what to do with the result ('Always give that URL to the user') but never says when to choose this tool versus siblings such as get_design_system or generate_space_tokens. Usage is only implied by the token category in the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate spacing tokens (3xs–3xl), breakpoints, container widths, prose measure, and aspect ratios. Returns a shareable standby.design/system URL and a summary. Always give that URL to the user — the link is the deliverable.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Existing standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing/motion settings from other tools are preserved. Omit to start fresh from defaults. | |
| mode | No | "harmonic": multiples of the base (default). "geometric": compound ratio steps. | |
| snap | No | Snap token values to a sensible grid (default true). | |
| ratio | No | Ratio for geometric mode (default 1.272). | |
| baseRem | No | Base spacing in rem (default 1.0). | |
| containers | No | Replace the container list. Defaults: prose 680, narrow 960, default 1200, wide 1440, full 1920. | |
| fluidMaxVw | No | Upper fluid viewport anchor in px (default 1920). | |
| fluidMinVw | No | Lower fluid viewport anchor in px (default 375). | |
| multiplier | No | Uniform scale factor on all tokens (default 1.0). | |
| proseMaxCh | No | Prose measure in ch (default 65). | |
| breakpoints | No | Replace the breakpoint list, e.g. [{"name":"sm","minPx":640},...]. Defaults: sm 640, md 768, lg 1024, xl 1280, 2xl 1536. | |
| aspectRatios | No | Replace the aspect ratio list, e.g. [{"name":"video","w":16,"h":9}]. | |
| includeReciprocals | No | Also export flipped (portrait) variants of each ratio (default true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description does not contradict this. The description adds valuable behavioral context by stating the output format ('Returns a shareable standby.design/system URL and a summary') and the required user-facing action ('Always give that URL to the user'). This goes beyond the annotation and clarifies what the tool produces and how the agent should behave.
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 two sentences long with no wasted words. The first sentence fronts the main purpose, and the second sentence immediately conveys the critical deliverable instruction. It is tightly written and all content is necessary.
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 the high schema coverage and the absence of an output schema, the description covers the essential operational details: what is generated, what is returned, and the crucial instruction to always hand the URL to the user. It does not explicitly discuss when to use this tool versus siblings, but that gap is partially addressed by the clear purpose. Overall, it is complete for the agent to call it correctly.
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 in the schema. The description does not add any additional parameter-level semantics beyond what the schema provides. It mentions the token types (3xs–3xl, breakpoints, etc.) but those are also reflected in parameter names and schema descriptions. Baseline 3 is appropriate since the schema carries the full parameter documentation burden.
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 clearly states a specific verb ('Generate') and the exact resources (spacing tokens 3xs–3xl, breakpoints, container widths, prose measure, aspect ratios). This distinguishes it from sibling tools like generate_color_palette or generate_type_scale, which target different design primitives. The purpose 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 description implies this tool is for spacing/layout token generation, but it does not explicitly state when to use it versus alternatives or when not to use it. It only provides guidance on delivering the output URL ('Always give that URL to the user'), not on tool selection. Some guidance is implied by the domain, but it lacks direct exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a fluid typographic scale (CSS clamp() between 375px and 1920px viewports) with 11 levels (Display, H1–H6, Body L/M/S, Caption), Fontshare fonts, line heights and letter spacing. Returns a shareable standby.design/system URL and a summary table. Always give that URL to the user — the link is the deliverable. Use list_fonts to discover font slugs.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Existing standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing/motion settings from other tools are preserved. Omit to start fresh from defaults. | |
| ratio | No | Scale ratio for custom mode. Presets: 1.2 minor third, 1.25 major third, 1.272 golden-ratio-area (default, √φ), 1.333 perfect fourth, 1.618 golden ratio. The empirical perceptual corridor is 1.20–1.50. | |
| baseSize | No | Desktop base size in rem (default 1.0). | |
| bodyFont | No | Fontshare font slug for body text. | |
| monoFont | No | Font slug for code. System stacks: "system-mono", "consolas", "sf-mono". | |
| scaleMode | No | "custom": compound ratio scale (default). "traditional": classical Renaissance point sizes per level. | |
| autoShrink | No | Percent reduction for the auto-derived mobile ratio (default 25). Only used when mobileRatio is not set. | |
| headingFont | No | Fontshare font slug for headings, e.g. "satoshi", "general-sans", "clash-display". | |
| mobileRatio | No | Explicit mobile scale ratio. Omit to auto-derive from ratio and autoShrink. | |
| headingWeight | No | Font weight for headings (default 500). | |
| mobileBaseSize | No | Mobile base size in rem (default = baseSize). | |
| lineHeightOverrides | No | Per-level line-height overrides, e.g. {"h1": 1.1, "body-m": 1.6}. Levels: display, h1–h6, body-l, body-m, body-s, caption. | |
| letterSpacingOverrides | No | Per-level letter-spacing overrides in em, e.g. {"display": -0.05}. | |
| traditionalAssignments | No | For traditional mode: desktop px size per level, e.g. {"display": 48, "h1": 36, ...}. | |
| traditionalMobileAssignments | No | For traditional mode: mobile px size per level. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description does not contradict this. The description adds a specific behavioral instruction that the URL is the deliverable and must always be given to the user, which is useful. However, it does not disclose other behavioral aspects like how existing URLs are modified (covered only in the url parameter description) or any side effects, so it adds modest value beyond the annotations.
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 two sentences that are front-loaded with the core function, then the deliverable, and a pointer to a sibling tool. There is no fluff; every sentence earns its place. This is an efficient and well-structured description.
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 the tool's complexity (15 params, nested objects), the description gives a high-level overview that communicates the purpose, output (URL and summary table), and a useful hint about using list_fonts. However, it omits the ability to modify an existing URL (only in the url parameter description) and does not specify the format of the summary table. These gaps are minor since the schema carries the detailed information, making the description adequate for an agent that reads the full schema.
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%, with each of the 15 parameters having detailed descriptions including presets, defaults, and examples. The main description adds little parameter-level detail beyond mentioning Fontshare fonts, so the description does not enhance what the schema already provides. A baseline of 3 is appropriate given the high schema coverage.
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 clearly states it generates a fluid typographic scale with CSS clamp, specifies the 11 levels (Display, H1–H6, Body L/M/S, Caption), and includes font, line-height, and letter-spacing. It distinguishes itself from sibling generator tools (color, icon, motion, etc.) by naming the exact resource and deliverable, making the purpose unmistakable.
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 gives a concrete pointer to list_fonts for discovering font slugs, which is a complementary tool, but it does not explicitly state when to use this tool versus other generate_* siblings or when not to use it. The usage context is implied by the domain rather than clearly articulated with exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Universal design rules for building UI with design tokens: layout, flow (empty, loading and error states, dialogs), shape, surfaces, interaction and keyboard access, forms, content structure, states, typography, color and stack rules for Tailwind/React Native. The tokens say which values exist; these rules say how to use them. Call this before building or reviewing views. Without arguments it returns every rule as one line (61 rules); pass rules (slugs) or a category with detail "full" for the complete text including how to detect violations in code. Rule texts are in German. Categories: Layout, Fluss, Form, Fläche, Bedienung, Formular, Inhalt, Zustand, Typografie, Farbe, Stack.
| Name | Required | Description | Default |
|---|---|---|---|
| rules | No | Rule slugs (from the summary) to return in full. | |
| scope | No | "universal" applies to every project, "stack" to one technology (e.g. Tailwind, React Native). | |
| detail | No | "summary" (default): one line per rule. "full": complete rule text. Defaults to "full" when rules are given. | |
| category | No | Only rules from this category: Layout, Fluss, Form, Fläche, Bedienung, Formular, Inhalt, Zustand, Typografie, Farbe, Stack. | |
| platform | No | Only rules that apply to this platform. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint, so the description adds real context: the default return is one line per rule, that 61 rules exist, that full detail includes violation-detection guidance, and that rule texts are in German. A note on rate limits or ordering is absent, but this is substantive beyond the annotations.
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 purpose and the token-vs-rules distinction, then the invocation modes. It is a long single block and the 'Rule texts are in German' caveat and category enumeration are appended after the actionable content, but almost every sentence carries usable information.
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 and no required parameters, the description carries the return-shape burden and does so: one line per rule by default, full text with detection guidance on request, plus the language of the content. An agent has everything needed to invoke it correctly on a first try.
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% and the category list, scope meaning, and the detail default ('Defaults to full when rules are given') are already stated in the schema. The description's parameter-adjacent content largely restates this, adding little syntax or semantic detail beyond the structured fields, so the 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?
The description names a specific resource (universal design rules for building UI with design tokens) and enumerates the domains covered, then contrasts itself against the token tools: 'The tokens say which values exist; these rules say how to use them.' An agent can separate this from get_design_system without opening either 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?
It gives explicit timing guidance ('Call this before building or reviewing views') and explains the retrieval modes (no arguments = all 61 rules; rules/category with detail 'full' = complete text). It does not, however, state when to prefer the sibling token tools or any exclusion cases, so the guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode a standby.design URL (or raw hash) and return an overview of the full design system: color palette, type scale, spacing & layout, shape tokens, motion springs, and icons — plus per-tool edit links. Always give the standby.design/system URL to the user — the link is the deliverable.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A standby.design URL or raw unified hash (e.g. from a previous generate_* call or copied from the browser). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, covering the lack of side effects. The description adds behavioral context by specifying that the tool returns an overview and that the URL is the deliverable to be presented to the user. This goes beyond the annotations and gives practical invocation guidance.
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 two sentences with no redundancy. The action and key output are front-loaded, and the deliverable instruction is concise and actionable. Every sentence earns its place.
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 the tool's simplicity (one parameter, read-only) and lack of output schema, the description adequately covers the return content (overview of design system components) and the deliverable. It does not explicitly state the output structure (e.g., JSON object), but that is not essential for a read-only overview tool with clear component listing.
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% and the description repeats the same input concept ('standby.design URL or raw hash') without adding syntax, formatting, or edge-case details. The schema description already mentions 'from a previous generate_* call or copied from the browser,' so the description does not enhance parameter understanding.
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 ('Decode') and resource ('standby.design URL or raw hash') and enumerates the output components (color palette, type scale, spacing, shape tokens, motion springs, icons, and per-tool edit links). It clearly distinguishes from sibling generation tools by focusing on inspection rather than creation, and from get_design_rules by covering the full system overview.
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 implies usage when a standby.design URL or raw hash is available and an overview is needed, but it does not explicitly contrast with alternatives like export_design_system or get_design_rules. The deliverable instruction ('Always give the standby.design/system URL to the user') is useful but not about when to choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Fontshare font slugs usable in generate_type_scale (headingFont/bodyFont/monoFont), grouped by category. This is the bundled seed catalog — any valid Fontshare slug works even if not listed here.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description adds that it is a bundled seed catalog and that valid slugs not listed still work, providing extra context beyond the annotations.
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 two sentences, front-loading the main purpose and resource, with no redundant information.
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?
Despite having no output schema, the description fully explains what the tool returns (font slugs grouped by category) and its usage context, making it complete for the tool's simple functionality.
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?
There are no parameters, and schema coverage is 100% (empty). The description is not required to add parameter info, but it provides complete context for the tool's input.
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 clearly states the tool lists Fontshare font slugs usable in generate_type_scale, grouped by category. It differentiates from sibling tools which are generation or export tools.
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 explicitly links the tool to generate_type_scale usage and notes that any valid Fontshare slug works even if not listed, guiding when to use it. No exclusion criteria are given, but the context is clear.
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.
export_design_system1 field changedInput schema / properties / sections / descriptionPrevious value: -"Which sections to include. Honoured by \"css\", \"tailwind\", \"llm-briefing\" and \"design-tokens\" (which only knows type, space and motion). By default color, type, space, shape and motion are always included — with their defaults when the URL does not configure them — and symbol only when the URL configures it. Ignored by \"font-embed\"."New value: +"Which sections to include. Honoured by \"css\", \"tailwind\", \"llm-briefing\" and \"design-tokens\" (which has no color section). By default color, type, space, shape and motion are always included — with their defaults when the URL does not configure them — and symbol only when the URL configures it. Ignored by \"font-embed\"."generate_color_palette2 fields changedInput schema / properties / accents / descriptionPrevious value: -"Up to 3 additional named accent colors. Replaces the existing accent list when provided; pass [] to remove all accents. Default: Success/Warning/Info, auto-derived."New value: +"Up to 10 additional named accent colors. Replaces the existing accent list when provided; pass [] to remove all accents. Default: Success/Warning/Info, auto-derived."Input schema / properties / accents / maxItemsPrevious value: -3New value: +10generate_shape_tokens1 field changedInput schema / properties / glassDispersion / descriptionPrevious value: -"Chromatic aberration intensity (default 0.4)."New value: +"Chromatic aberration intensity (default 0.5)."get_design_rules1 field changedInput schema / properties / category / descriptionPrevious value: -"Only rules from this category: Layout, Fluss, Form, Fläche, Bedienung, Zustand, Typografie, Farbe, Stack."New value: +"Only rules from this category: Layout, Fluss, Form, Fläche, Bedienung, Formular, Inhalt, Zustand, Typografie, Farbe, Stack."export_design_system2 fields changedInput schema / properties / sections / descriptionPrevious value: -"Which sections to include. Only honoured by \"css\", \"tailwind\" and \"llm-briefing\". By default color, type, space and shape are always included — with their defaults when the URL does not configure them — and symbol only when the URL configures it. Ignored by \"design-tokens\" (typography and spacing only) and \"font-embed\"."New value: +"Which sections to include. Honoured by \"css\", \"tailwind\", \"llm-briefing\" and \"design-tokens\" (which only knows type, space and motion). By default color, type, space, shape and motion are always included — with their defaults when the URL does not configure them — and symbol only when the URL configures it. Ignored by \"font-embed\"."Input schema / properties / sections / items / enumPrevious value: -[
- "color",
- "type",
- "space",
- "shape",
- "symbol"
-]New value: +[
+ "color",
+ "type",
+ "space",
+ "shape",
+ "symbol",
+ "motion"
+]generate_color_palette1 field changedInput schema / properties / url / descriptionPrevious value: -"Existing standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing settings from other tools are preserved. Omit to start fresh from defaults."New value: +"Existing standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing/motion settings from other tools are preserved. Omit to start fresh from defaults."generate_icon_tokens1 field changedInput schema / properties / url / descriptionPrevious value: -"Existing standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing settings from other tools are preserved. Omit to start fresh from defaults."New value: +"Existing standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing/motion settings from other tools are preserved. Omit to start fresh from defaults."generate_motion_tokensgenerate_shape_tokens1 field changedInput schema / properties / url / descriptionPrevious value: -"Existing standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing settings from other tools are preserved. Omit to start fresh from defaults."New value: +"Existing standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing/motion settings from other tools are preserved. Omit to start fresh from defaults."generate_space_tokens1 field changedInput schema / properties / url / descriptionPrevious value: -"Existing standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing settings from other tools are preserved. Omit to start fresh from defaults."New value: +"Existing standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing/motion settings from other tools are preserved. Omit to start fresh from defaults."generate_type_scale1 field changedInput schema / properties / url / descriptionPrevious value: -"Existing standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing settings from other tools are preserved. Omit to start fresh from defaults."New value: +"Existing standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing/motion settings from other tools are preserved. Omit to start fresh from defaults."get_design_rulesexport_design_system1 field changedInput schema / properties / sections / descriptionPrevious value: -"Which sections to include. Default: all configured sections (symbol only when configured)."New value: +"Which sections to include. Only honoured by \"css\", \"tailwind\" and \"llm-briefing\". By default color, type, space and shape are always included — with their defaults when the URL does not configure them — and symbol only when the URL configures it. Ignored by \"design-tokens\" (typography and spacing only) and \"font-embed\"."generate_icon_tokens1 field changedInput schema / properties / set / descriptionPrevious value: -"Icon set variant id to select explicitly, e.g. \"lucide-outlined\". One of: material-outlined, material-filled, lucide, phosphor-regular, phosphor-bold, phosphor-thin, phosphor-fill, solar-linear, solar-bold, solar-broken, tabler-outline, tabler-filled, radix. Pass \"auto\" to clear the selection and use the recommendation instead."New value: +"Icon set variant id to select explicitly, e.g. \"material-outlined\". One of: material-outlined, material-filled, lucide, phosphor-regular, phosphor-bold, phosphor-thin, phosphor-fill, solar-linear, solar-bold, solar-broken, tabler-outline, tabler-filled, radix. Pass \"auto\" to clear the selection and use the recommendation instead."generate_shape_tokens1 field changedInput schema / properties / ringStyleAdded value: +{
+ "description": "Focus ring shape: \"soft\" (default) is a translucent halo at the edge plus a full-color border, \"solid\" is a hard outline set off by ringOffset.",
+ "enum": [
+ "soft",
+ "solid"
+ ],
+ "type": "string"
+}generate_space_tokens1 field changedInput schema / properties / containers / descriptionPrevious value: -"Replace the container list. Defaults: prose 680, narrow 880, default 1200, wide 1440."New value: +"Replace the container list. Defaults: prose 680, narrow 960, default 1200, wide 1440, full 1920."export_design_systemgenerate_color_palettegenerate_icon_tokensgenerate_shape_tokensgenerate_space_tokensgenerate_type_scaleget_design_systemlist_fontsBuild and manage your design system with AI: tokens, themes, components, icons, Figma and code.
Give your agent a real design system: tokens, measured WCAG contrast, and rules to follow.
18 color tools: OKLCH, WCAG and APCA contrast fixes, palettes, gradients, color blindness, tokens.
On-demand drift checks: declared CSS color, radius, spacing & type vs your own tokens or a pack
Add one secure layer between your agents and this server.
