Click on "Install 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., "@UI Preset MCP Server Apply the client-fintech preset and autocorrect this React component code"
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.
MCP server for auto-configuring React UI against a swappable design preset system. Integrates with your Monaco IDE to enforce design uniformity across all business builds. Supports glassmorphism, neumorphism, neon cyberpunk, brutalism, soft pastels, aurora gradients, and more — a baby Canva for frontend development.
ui-preset-mcp-server/
├── src/
│ ├── index.ts # Server entry point (stdio + HTTP transports)
│ ├── constants.ts # Shared constants and paths
│ ├── types/
│ │ └── index.ts # All TypeScript types (tokens, presets, corrections)
│ ├── schemas/
│ │ └── toolSchemas.ts # Zod validation schemas for every tool
│ ├── services/
│ │ ├── presetLoader.ts # Reads + deep-merges preset files with caching
│ │ ├── sessionState.ts # Active preset session management + overrides
│ │ ├── uiCorrector.ts # AST correction engine (10 correction passes)
│ │ ├── tokenResolver.ts # Resolves {{token:x.y.z}} placeholders + export generators
│ │ └── fileWatcher.ts # Hot-reload presets on disk changes (dev mode)
│ ├── tools/
│ │ ├── presetTools.ts # load_preset, swap_template, list_presets, diff_presets, scaffold_preset
│ │ ├── correctionTools.ts # autocorrect_component, validate_ui, generate_component, generate_tokens, apply_token_overrides
│ │ └── styleTools.ts # generate_color_palette, suggest_style, list_style_categories
│ ├── routes/
│ │ └── uiRoutes.ts # REST API + Design Studio dashboard (GET /, /api/*)
│ └── ui/
│ └── dashboardHtml.ts # Embedded Design Studio HTML (9 sections)
└── presets/
├── glassmorphic-base/ # Core preset (all others inherit from this)
│ ├── manifest.json
│ ├── tokens.json # Full design token system
│ ├── components/
│ │ ├── shell/Sidebar.json
│ │ ├── surfaces/GlassCard.json
│ │ ├── settings/OptionGroup.json
│ │ └── navigation/NavGroup.json
│ └── layouts/DashboardLayout.json
├── client-fintech/ # Blue accent, dense spacing
├── client-saas/ # Purple accent, wider cards
├── client-dark-minimal/ # Monochrome, reduced glass intensity
├── style-neumorphic/ # Light soft UI, extruded shadows, no blur
├── style-neon-cyberpunk/ # Pitch-dark + neon accents, monospace type
├── style-brutalist/ # Raw B&W, zero radius, heavy typography
├── style-soft-pastel/ # Lavender background, pastel accents, generous rounding
└── style-aurora/ # Deep navy + iridescent aurora purple/teal accentsRelated MCP server: @manansiingh/figma-react-mcp-server
Tool | Description |
| Activate a preset bundle by ID |
| Hot-swap active preset without restart |
| List all available presets |
| Compare token/component differences between two presets |
| Generate a new preset directory from a parent |
| Check active preset and runtime overrides |
Tool | Description |
| Auto-fix React component against active preset |
| Validate component and get conformance score (0–100) |
| Generate a component from a preset template |
| Export tokens as CSS vars, JS, JSON, or Tailwind config |
| Layer runtime token overrides on the active preset |
Tool | Description |
| Generate a harmonious color palette from a seed hex color using color theory (complementary, triadic, analogous, monochromatic, split-complementary, tetradic) |
| Get preset + token override suggestions from a natural-language aesthetic description (e.g. "dark hacker terminal", "friendly pastel kids app") |
| List all available design style categories with principles, descriptions, and associated presets |
Category | Preset | Description |
Glassmorphic |
| Frosted-glass with backdrop blur, dark substrate |
Neumorphic |
| Soft extruded shapes, dual shadows, light background |
Neon Cyberpunk |
| Pitch-dark + vivid neon accents, monospace type |
Brutalist |
| Raw B&W, zero border-radius, maximum contrast |
Soft Pastel |
| Lavender base, pastel accents, generous rounding |
Aurora Gradient |
| Deep navy + iridescent aurora purple/teal accents |
npm install
npm run buildnode dist/index.jsTRANSPORT=http PORT=3001 node dist/index.jsWATCH_PRESETS=true node dist/index.jsWhen running in HTTP mode, a Design Studio mini UI is served at GET /.
Section | Description |
Dashboard | Active preset overview with component/layout stats and color palette preview |
Presets | Browse all presets in cards; click Load to activate any preset instantly |
Style Gallery | Visual style category browser — each card shows design principles and a color preview strip; load any style with one click |
Palette | Color palette generator — pick a seed color, choose a color harmony rule, and generate a full palette with shades and semantic aliases; apply directly to active preset |
Tokens | Visual token viewer — color swatches, typography scale, blur, spacing, animation |
Validate | Paste React code and get a conformance score (0–100) with issue list |
Correct | Auto-correct React code against the active preset; choose context and mode |
Export | Generate CSS custom properties, TypeScript const, JSON, or Tailwind config |
Scaffold | Form to create a new preset from any parent with optional accent color |
The UI communicates with the server via a REST API also available at /api/*.
Endpoint | Method | Description |
| GET | List all presets with metadata |
| POST | Load and activate a preset |
| GET | Get active preset and override state |
| GET | Get effective tokens for the active preset |
| POST | Export tokens `{ format: 'css' |
| POST | Apply runtime token overrides |
| POST | Validate React code |
| POST | Autocorrect React code |
| POST | Create new preset |
| GET | List all design style categories with metadata |
| POST | Generate color palette |
1. list_style_categories() # Discover available aesthetics
2. suggest_style("dark sci-fi dashboard") # Get preset recommendation
3. load_preset("style-neon-cyberpunk") # Activate chosen style
4. const palette = generate_color_palette({ seed_color: "#00ff88", harmony: "triadic" })
5. apply_token_overrides({
overrides: {
colors: {
accent: {
primary: palette.semantic.accent,
highlight: palette.semantic.highlight
}
}
}
})
6. autocorrect_component(code) # Fix component on save
7. validate_ui(code) # Get conformance score
8. generate_tokens({ format: "css" }) # Export CSS variables
9. scaffold_preset({ preset_id: "client-x", extends: "style-aurora" })New presets only need to override tokens that differ from the parent:
// presets/client-newbrand/tokens.json
{
"colors": {
"accent": {
"primary": "#e11d48"
}
}
}// presets/client-newbrand/manifest.json
{
"id": "client-newbrand",
"name": "New Brand",
"extends": "glassmorphic-base",
"version": "1.0.0",
"styleCategory": "glassmorphic",
"designPrinciples": ["backdrop-blur", "dark-substrate"],
"tags": ["custom"],
"components": [],
"layouts": []
}All base tokens, components, and layouts are inherited automatically.
The correction engine enforces these rules on every component:
no-hardcoded-colors (error): All color values must use CSS custom properties
no-hardcoded-spacing (warning): Spacing should use the token scale
enforce-glass-surface (error): Surface elements must have backdropFilter + semi-transparent bg
no-hardcoded-font-family (error): Font families must use typography tokens
use-animation-tokens (warning): Transitions must use animation tokens
enforce-sidebar-components (error): Sidebar content must use NavGroup/NavItem
enforce-settings-components (error): Settings UI must use OptionGroup/OptionRow
a11y-img-alt (warning): Images must have alt attributes
a11y-icon-button-label (warning): Icon buttons need aria-label
In your Monaco editor, call autocorrect_component on the save event:
editor.onDidSaveModel(async () => {
const code = editor.getValue();
const result = await mcpClient.callTool('autocorrect_component', {
code,
context: 'auto',
dry_run: false
});
if (result.corrected !== code) {
editor.setValue(result.corrected);
}
});Apply runtime token overrides on top of the active preset (deep merged). Overrides are applied in memory only unless persist: true writes them to disk. Useful for per-client accent color changes without creating a full preset.
Args:
overrides (object): Partial DesignTokens object (deeply merged over active tokens)
persist (boolean): Write overrides to preset/overrides.json on disk (default: false)
Example overrides: { "colors": { "accent": { "primary": "#2563eb" } } }
Returns: Confirmation of applied override paths. Requires active preset.
| Name | Required | Description | Default |
|---|---|---|---|
| overrides | Yes | Partial DesignTokens object (deeply merged over active tokens) | |
| persist | No | Write overrides to preset/overrides.json on disk |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover basic hints (readOnlyHint=false, destructiveHint=false), but the description adds valuable behavioral context: it explains that overrides are 'applied in memory only unless persist: true', clarifies the merge behavior ('deeply merged'), and mentions the output ('Returns: Confirmation of applied override paths'). This goes beyond what annotations provide without contradiction.
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 well-structured and front-loaded: the first sentence explains the core purpose, followed by key behavioral details, usage guidelines, parameter documentation, an example, and prerequisites. Every sentence adds value without redundancy, making it efficient for an agent to parse.
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 (runtime overrides with persistence options), the description provides complete context: it covers purpose, usage, behavior, parameters, and output. While there is no output schema, the description specifies the return value ('Confirmation of applied override paths'), and annotations fill in safety aspects. This is sufficient for effective agent use.
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 both parameters ('overrides' and 'persist') fully documented in the schema. The description repeats this information in the 'Args' section and adds an example, but does not provide additional semantic meaning beyond what the schema already states. Baseline 3 is appropriate given 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 the specific action ('apply runtime token overrides'), the resource ('on top of the active preset'), and the mechanism ('deep merged'). It distinguishes from sibling tools like 'load_preset' or 'scaffold_preset' by focusing on runtime modifications rather than preset management or creation.
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 states when to use this tool ('Useful for per-client accent color changes without creating a full preset') and provides a clear alternative scenario ('persist: true writes them to disk'). It also specifies a prerequisite ('Requires active preset'), guiding the agent on proper context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a React component and auto-correct it against the active preset. Corrects: hardcoded colors, missing glass treatment, wrong typography tokens, wrong animation tokens, non-conforming sidebar/settings structure.
Args:
code (string): React component source code (max 10,000 chars)
context ('sidebar'|'settings'|'dashboard'|'surface'|'navigation'|'form'|'auto'): Component context hint for targeted rules (default: 'auto')
dry_run (boolean): Return issues without changing code (default: false)
Returns:
corrected: Fixed component code
issues: Array of UIIssue objects with severity, rule, message, fix
appliedFixes: List of changes made
score: Conformance score before correction (0-100)
Requires active preset (run load_preset first).
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | React component source code (max 10,000 chars) | |
| context | No | Component context hint for targeted rules | auto |
| dry_run | No | Return issues without changing code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations. Annotations indicate it's not read-only, not open-world, not idempotent, and not destructive, but the description clarifies it 'auto-corrects' code, explains what specific issues it fixes, mentions the 'dry_run' option for previewing changes, and notes the prerequisite of an active preset. This provides practical implementation details not covered by 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 well-structured and front-loaded: it starts with the core purpose, lists specific corrections, details parameters and returns in clear sections, and ends with a prerequisite. Every sentence adds value without redundancy, making it efficient and easy to scan.
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 (analyzing and correcting code), the description is complete despite no output schema. It explains what the tool does, what it corrects, all parameters, return values (corrected code, issues, applied fixes, score), and a key prerequisite. This provides sufficient context for an agent to use it effectively, especially with annotations covering safety aspects.
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?
With 100% schema description coverage, the schema already fully documents all parameters. The description repeats some parameter details (e.g., 'code (string): React component source code (max 10,000 chars)') but adds minimal extra semantics—it briefly explains the 'context' parameter's purpose ('Component context hint for targeted rules') and the 'dry_run' effect ('Return issues without changing code'), which slightly enhances understanding. Baseline 3 is appropriate when schema does most of the work.
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's purpose with specific verbs ('analyze', 'auto-correct') and resources ('React component'), and distinguishes it from siblings by specifying what it corrects (hardcoded colors, missing glass treatment, etc.). It explicitly mentions it works 'against the active preset', differentiating it from tools like 'validate_ui' or 'suggest_style'.
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 provides explicit usage guidance: it states 'Requires active preset (run load_preset first)', which is a clear prerequisite. It also distinguishes when to use this tool by listing specific corrections it performs, helping differentiate it from siblings like 'validate_ui' (which might only check) or 'generate_component' (which creates new components).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two presets and return what changed between them. Useful for understanding what a client override changes vs the base.
Args:
preset_a (string): First preset ID
preset_b (string): Second preset ID
scope ('tokens' | 'components' | 'layouts' | 'all'): What to compare (default: 'all')
Returns: Object with added, removed, and changed keys with before/after values.
| Name | Required | Description | Default |
|---|---|---|---|
| preset_a | Yes | First preset ID | |
| preset_b | Yes | Second preset ID | |
| scope | No | What to compare | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context beyond annotations: it explains the tool's purpose in understanding client overrides. Annotations already cover safety (readOnlyHint=true, destructiveHint=false) and idempotency, so the bar is lower. The description doesn't contradict annotations and adds practical application context.
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 front-loaded with the core purpose in the first sentence, followed by usage guidance and parameter/return details. Every sentence earns its place with no wasted words, making it efficient and well-structured.
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 read-only comparison tool with full schema coverage and clear annotations, the description is complete. It explains the purpose, usage context, parameters, and return structure. No output schema exists, but the description adequately describes the return format with added/removed/changed keys.
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 all parameters thoroughly. The description adds minimal extra semantics (e.g., 'what to compare' for scope), but doesn't provide significant value beyond the schema. Baseline 3 is appropriate when 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?
The description clearly states the specific action ('compare two presets'), the resource ('presets'), and the outcome ('return what changed between them'). It distinguishes this tool from siblings like 'list_presets' or 'load_preset' by focusing on comparison rather than listing or loading.
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 states when to use this tool: 'Useful for understanding what a client override changes vs the base.' This provides clear context for usage (comparing overrides vs base) and implicitly distinguishes it from siblings that don't involve comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a harmonious color palette from a seed hex color using color theory.
Args:
seed_color (string): 6-digit hex color (e.g. '#6366f1')
harmony ('complementary'|'triadic'|'analogous'|'monochromatic'|'split-complementary'|'tetradic'): Color harmony rule (default: 'complementary')
include_shades (boolean): Include 10-step lightness shades 50–900 (default: true)
Returns:
seed: Input color
hsl: Hue, saturation, lightness of seed
harmony: Harmony type used
colors: Named harmony colors (primary, complement, etc.)
semantic: foreground, background, muted, surface aliases
shades: 50–900 shade scale (if include_shades is true)
Use the result to populate apply_token_overrides or scaffold_preset.
| Name | Required | Description | Default |
|---|---|---|---|
| seed_color | Yes | Seed hex color to generate the palette from | |
| harmony | No | Color harmony rule to apply | complementary |
| include_shades | No | Include 10-step lightness shades (50–900) for the primary color |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by detailing the return structure (e.g., 'hsl', 'semantic', 'shades'), which is valuable since annotations only cover read-only, non-destructive, and idempotent traits. It doesn't contradict annotations, which correctly indicate a safe read operation, and provides useful output information not in 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 well-structured and front-loaded with the core purpose, followed by organized sections for arguments and returns, and ends with usage guidance. Every sentence earns its place without redundancy, making it efficient and easy to parse.
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 moderate complexity, rich annotations, and 100% schema coverage, the description is complete enough. It explains the purpose, parameters, return values, and usage context, compensating for the lack of an output schema by detailing the return structure, which ensures the agent can effectively use the 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?
The description includes an 'Args' section that lists parameters with brief explanations, but since schema description coverage is 100%, the schema already provides detailed descriptions for each parameter. The description adds minimal value beyond the schema, such as example values for 'seed_color', but doesn't significantly enhance parameter understanding, meeting the baseline of 3 for 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 the tool's purpose with specific verbs ('generate a harmonious color palette') and resources ('from a seed hex color using color theory'), distinguishing it from siblings like 'generate_tokens' or 'suggest_style' by focusing on color palette generation rather than tokens or style suggestions.
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 provides usage guidance by stating 'Use the result to populate apply_token_overrides or scaffold_preset,' naming specific sibling tools as alternatives for downstream actions, which helps the agent understand when to use this tool versus others in the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a React component from a preset template, with tokens resolved. Templates come from the active preset's component library.
Args:
template_name (string): Component template to generate (e.g. 'GlassCard', 'Sidebar', 'OptionGroup')
props (object): Props to inject into the template (default: {})
variant (string, optional): Template variant (e.g. 'compact', 'wide', 'collapsible')
Returns:
code: Generated React component with tokens resolved
templateUsed: Name of the resolved template
availableProps: Schema of props the template accepts
Run list_presets with include_metadata to see available templates. Requires active preset.
| Name | Required | Description | Default |
|---|---|---|---|
| template_name | Yes | Component template to generate (e.g. 'GlassCard', 'Sidebar') | |
| props | No | Props to inject into the template | |
| variant | No | Template variant (e.g. 'compact', 'wide') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover key behavioral traits (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false). The description adds useful context about token resolution and template sources, but doesn't disclose additional behavioral details like rate limits, error conditions, or authentication needs 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 well-structured with clear sections (purpose, args, returns, usage notes) and appropriately sized. Every sentence earns its place, though the 'Args' section could be more concise since it duplicates schema information. It's front-loaded with the core 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?
Given the tool's complexity (3 parameters, nested objects, no output schema) and rich annotations, the description is mostly complete. It explains the purpose, parameters, returns, and prerequisites. However, it doesn't fully describe the return format or error handling, which would be helpful despite the annotations.
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 all parameters thoroughly. The description's 'Args' section repeats this information without adding significant semantic value beyond what's in the schema. The baseline score of 3 is appropriate 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?
The description clearly states the specific action ('Generate a React component from a preset template, with tokens resolved'), identifies the resource ('React component'), and distinguishes it from siblings by specifying it uses templates from the active preset's component library. It's not a tautology of the name/title.
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 states when to use this tool ('Requires active preset') and provides an alternative action ('Run list_presets with include_metadata to see available templates') for discovering templates. It clearly differentiates from siblings like 'list_presets' or 'load_preset' by focusing on generation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the active preset's design tokens in various formats for use in your project.
Args:
format ('css'|'js'|'json'|'tailwind'): Output format (default: 'css')
css: :root { --color-surface: ...; } CSS custom properties
js: TypeScript const export for use with style objects
json: Raw token JSON
tailwind: theme.extend config for tailwind.config.js
include_comments (boolean): Add section headers in output (default: true)
Returns: Token file content as a string. Requires active preset.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format for token export | css |
| include_comments | No | Add section headers in output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a read-only, non-destructive, idempotent operation, but the description adds valuable context: it specifies that the output is 'Token file content as a string' and mentions the dependency on an active preset. This goes beyond annotations by clarifying the return type and prerequisite condition, though it doesn't detail rate limits or auth needs.
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 front-loaded with the core purpose in the first sentence, followed by structured parameter details and return information. Every sentence adds value: the first explains the tool's function, the Args section clarifies parameters, and the Returns/Requires lines provide essential context without redundancy.
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 moderate complexity, rich annotations (covering safety and behavior), and full parameter documentation in the schema, the description is complete. It explains the purpose, parameters, return value, and prerequisite, leaving no gaps for the agent to understand how to invoke it correctly, even without an output 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?
With 100% schema description coverage, the schema fully documents both parameters. The description adds minimal value by listing format options with brief examples (e.g., 'css: :root { --color-surface: ...; }'), but doesn't provide additional syntax or usage details beyond what's in the schema. This meets the baseline for 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 the specific action ('Export'), the resource ('active preset's design tokens'), and the purpose ('for use in your project'). It distinguishes from siblings like 'generate_color_palette' or 'generate_component' by focusing on token export rather than generation or manipulation of design elements.
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 states 'Requires active preset' as a prerequisite, providing clear context for when to use this tool. However, it does not specify when to choose this over alternatives like 'list_presets' or 'load_preset' for preset management, or differentiate from other export/formatting tools if they existed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current session state including active preset ID, load time, and any runtime token overrides.
Returns:
activePresetId: Currently loaded preset
loadedAt: When the preset was activated
hasOverrides: Whether runtime overrides are applied
overrideKeys: Top-level override keys
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide key behavioral hints (read-only, non-destructive, idempotent, closed-world), but the description adds valuable context by specifying what data is returned (active preset ID, load time, override status) and clarifying the scope ('current session state'). It does not contradict annotations, as 'Returns' aligns with read-only behavior.
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 front-loaded with the core purpose in the first sentence, followed by a bulleted list of return values for clarity. Every sentence earns its place by providing essential information without redundancy or 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?
Given the tool's simplicity (0 parameters, rich annotations, no output schema), the description is mostly complete. It explains what the tool returns, which compensates for the lack of output schema. However, it could briefly mention idempotency or typical use cases for better context.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on return values instead, adding semantic meaning to the output fields (e.g., explaining what 'activePresetId' and 'hasOverrides' represent).
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's purpose with a specific verb ('Returns') and resource ('current session state'), and it distinguishes itself from siblings by focusing on session state retrieval rather than preset management (list_presets, load_preset) or token operations (apply_token_overrides, generate_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 implies usage for checking session state details like active preset and overrides, but it does not explicitly state when to use this tool versus alternatives (e.g., list_presets for preset listings or apply_token_overrides for override management). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available presets in the presets directory. Optionally includes full manifest metadata for each preset.
Args:
include_metadata (boolean): Include full manifest for each preset (default: false)
Returns: Array of preset IDs, or array of preset manifests if include_metadata is true.
| Name | Required | Description | Default |
|---|---|---|---|
| include_metadata | No | Include full manifest for each preset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only, non-destructive, and idempotent traits, but the description adds valuable context: it specifies the source ('presets directory') and the optional metadata inclusion behavior. This clarifies what 'list' entails beyond basic safety, though it doesn't detail rate limits or auth needs.
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 front-loaded with the core purpose in the first sentence, followed by optional behavior and clear Args/Returns sections. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
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 low complexity, rich annotations, and 100% schema coverage, the description is nearly complete. It explains the action, parameter effect, and return values, though no output schema exists. A minor gap is lack of error handling or pagination details, but it suffices for basic use.
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 the parameter 'include_metadata' fully documented in the schema. The description repeats this in the Args section but adds minimal extra meaning, such as the return type implication. Baseline 3 is appropriate as the schema handles 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?
The description clearly states the verb 'List' and the resource 'all available presets in the presets directory,' with specific scope. It distinguishes from siblings like 'load_preset' (loads one) and 'scaffold_preset' (creates) by focusing on enumeration without modification.
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 for viewing presets, but lacks explicit guidance on when to use this versus alternatives like 'load_preset' for detailed inspection or 'list_style_categories' for categorization. No exclusions or prerequisites are mentioned, leaving context inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available design style categories with descriptions, design principles, and associated presets.
Args:
include_presets (boolean): Include preset IDs for each category (default: true)
Returns: Array of style categories with metadata. Use with suggest_style and load_preset to explore the design system.
| Name | Required | Description | Default |
|---|---|---|---|
| include_presets | No | Include the list of preset IDs for each category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide comprehensive behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false). The description adds some context about the return format ('Array of style categories with metadata') and mentions related tools, but doesn't disclose additional behavioral traits like rate limits, authentication needs, or specific constraints beyond what annotations cover.
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 well-structured and front-loaded with the core purpose in the first sentence. The Args and Returns sections are clearly separated, and every sentence adds value without redundancy. It efficiently conveys necessary information in a compact format.
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 low complexity (1 parameter, no output schema), rich annotations, and 100% schema coverage, the description is reasonably complete. It covers purpose, basic usage, and related tools. However, it could benefit from more detail on the return structure or example use cases to achieve full completeness.
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 fully documents the single parameter 'include_presets'. The description adds minimal value beyond the schema by mentioning the parameter in the Args section and noting the default, but doesn't provide additional semantic context or usage examples. Baseline 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 the verb 'List' and resource 'all available design style categories' with specific details about what information is included (descriptions, design principles, associated presets). It distinguishes from sibling tools like 'list_presets' by focusing specifically on style categories rather than presets.
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 provides explicit guidance on when to use this tool by mentioning 'Use with suggest_style and load_preset to explore the design system,' which gives clear context about its role. However, it doesn't explicitly state when NOT to use it or provide alternatives for similar functionality among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Activate a UI preset bundle by ID. Loads all tokens, component templates, and layout templates. Resolves inheritance (extends) chain automatically, deep-merging parent tokens. Must be called before any correction, validation, or generation tools.
Args:
preset_id (string): Folder name in /presets (e.g. 'glassmorphic-base', 'client-fintech')
force_reload (boolean): Bypass cache and re-read from disk (default: false)
Returns: Preset manifest summary and token count confirmation. Error: "Preset 'x' not found" if the preset directory doesn't exist.
| Name | Required | Description | Default |
|---|---|---|---|
| preset_id | Yes | Preset folder name in /presets (e.g. 'glassmorphic-base') | |
| force_reload | No | Bypass cache and re-read from disk |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read/write status (readOnlyHint=false), idempotency (idempotentHint=true), and safety (destructiveHint=false). The description adds valuable behavioral context beyond annotations: it explains that the tool 'Resolves inheritance (extends) chain automatically, deep-merging parent tokens,' describes caching behavior with 'force_reload,' and specifies error conditions like 'Preset not found.' No contradictions with annotations exist.
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 well-structured and front-loaded: the first sentence states the core purpose, followed by key behavioral details, usage prerequisites, parameter explanations, and return/error info. Each sentence adds value without redundancy, making it efficient for an agent to parse.
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 (activating presets with inheritance resolution), the description provides comprehensive context: it covers purpose, usage sequence, behavioral traits, parameters, returns, and errors. Although there's no output schema, the return description ('Preset manifest summary and token count confirmation') is sufficient. Annotations fill in safety and idempotency, making this complete for agent use.
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 clear descriptions for both parameters in the schema. The description repeats some parameter info (e.g., 'preset_id' as folder name) but adds minimal extra semantics, such as example values ('glassmorphic-base', 'client-fintech') and the default behavior explanation for 'force_reload.' This meets the baseline for 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 the specific action ('Activate a UI preset bundle by ID') and resource ('loads all tokens, component templates, and layout templates'), distinguishing it from siblings like 'list_presets' (listing) or 'scaffold_preset' (creating). It explicitly mentions what gets loaded, providing precise differentiation.
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 provides explicit usage guidance: 'Must be called before any correction, validation, or generation tools.' This clearly indicates when to use it (as a prerequisite) and implicitly when not to use it (after those operations), helping the agent sequence actions correctly among siblings like 'autocorrect_component' or 'validate_ui'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new preset directory with manifest and token override scaffold, inheriting from a parent preset. Generates a ready-to-customize preset structure on disk.
Args:
preset_id (string): Kebab-case ID for the new preset (e.g. 'client-banking')
extends (string): Parent preset to inherit from (default: 'glassmorphic-base')
name (string): Human-readable display name
description (string): Short description
accent_color (string, optional): Override accent color in the scaffolded tokens
Returns: Path to new preset directory and files created.
| Name | Required | Description | Default |
|---|---|---|---|
| preset_id | Yes | Kebab-case ID for the new preset | |
| extends | No | Parent preset to inherit from | glassmorphic-base |
| name | Yes | Human-readable display name | |
| description | Yes | Short description | |
| accent_color | No | Override accent color in the scaffolded tokens |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-readOnly, non-destructive, non-idempotent, non-openWorld operation. The description adds useful context beyond annotations: it specifies that the tool creates files on disk and generates a ready-to-customize structure. However, it doesn't mention important behavioral aspects like whether the operation requires specific permissions, what happens if the preset_id already exists, or any rate limits.
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 perfectly structured and concise: it starts with the core purpose, explains what it generates, then lists parameters with brief explanations, and ends with return information. Every sentence earns its place with zero wasted words, and the information is front-loaded appropriately.
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 tool with 5 parameters, 100% schema coverage, and no output schema, the description is quite complete. It explains what the tool does, what it creates, the parameters, and what it returns. The main gap is the lack of output schema, but the description compensates by specifying the return value ('Path to new preset directory and files created'). It could be more complete by mentioning error conditions or prerequisites.
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 fully documents all parameters. The description's Args section repeats what's in the schema without adding significant additional meaning (e.g., it doesn't explain the significance of kebab-case format or provide examples beyond what's in the schema). The baseline of 3 is appropriate 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?
The description clearly states the specific action ('Create a new preset directory with manifest and token override scaffold'), the resource ('preset'), and distinguishes it from siblings by specifying it creates a ready-to-customize structure on disk. It explicitly mentions inheritance from a parent preset, which differentiates it from tools like 'generate_tokens' or 'load_preset'.
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 provides clear context about when to use this tool: when you need to create a new preset directory with scaffolded files that inherits from a parent. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools (like 'generate_tokens' for creating tokens without directory structure).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a style preset and token override suggestions based on a natural-language aesthetic description.
Args:
description (string): Describe the desired look and feel (e.g. 'dark hacker terminal', 'friendly pastel kids app', 'professional fintech dashboard')
output_format ('preset_id'|'tokens'|'full'): What to return (default: 'full')
preset_id: Just the best matching preset ID
tokens: Just the suggested token overrides
full: Preset ID, token overrides, category info, and reasoning
Returns matching preset and style suggestions.
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | Natural-language description of the desired aesthetic or use-case (e.g. 'dark hacker terminal', 'friendly kids app') | |
| output_format | No | What to return: just the preset ID, just token overrides, or both with reasoning | full |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, and idempotentHint=true, covering safety and idempotency. The description adds valuable context beyond this: it explains the tool's generative nature (suggestions based on description) and output options (preset_id, tokens, full with reasoning), which are not captured in annotations. No contradictions exist.
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 front-loaded with the core purpose in the first sentence, followed by a structured 'Args' section with clear bullet points and examples. Every sentence adds value without redundancy, and the 'Returns' statement succinctly summarizes the output. It is efficiently sized for the tool's complexity.
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 moderate complexity (2 parameters, 100% schema coverage, no output schema), the description is largely complete. It covers purpose, parameters with examples, and output behavior. However, it lacks details on potential limitations (e.g., accuracy of suggestions, handling of ambiguous descriptions) or error cases, which could enhance completeness.
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 fully documents parameters. The description adds meaning by providing concrete examples for 'description' (e.g., 'dark hacker terminal') and clarifying the purpose of 'output_format' options (e.g., 'full' includes 'category info, and reasoning'), enhancing understanding beyond schema definitions.
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's purpose: 'Get a style preset and token override suggestions based on a natural-language aesthetic description.' It specifies the verb ('Get'), resources ('style preset and token override suggestions'), and input mechanism ('natural-language aesthetic description'), distinguishing it from siblings like 'list_presets' (which lists) or 'load_preset' (which loads a specific preset).
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 context by mentioning 'natural-language aesthetic description' and provides examples (e.g., 'dark hacker terminal'), but does not explicitly state when to use this tool versus alternatives like 'list_presets' or 'generate_tokens'. It offers clear guidance on the input but lacks sibling differentiation or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hot-swap the active preset without restarting the server. Useful for switching between client presets while building. Optionally preserves any runtime token overrides applied in the current session.
Args:
preset_id (string): The preset to switch to
preserve_overrides (boolean): Keep current overrides after swap (default: false)
Returns: New active preset summary.
| Name | Required | Description | Default |
|---|---|---|---|
| preset_id | Yes | The preset to switch to | |
| preserve_overrides | No | Keep current overrides after swap |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover basic hints (non-readOnly, non-destructive, etc.), but the description adds valuable context: it explains the 'hot-swap' behavior (runtime change without restart), mentions optional preservation of runtime token overrides, and hints at session state implications. This goes beyond annotations without contradicting them.
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 front-loaded with the core action and benefit, followed by a concise explanation of optional behavior. The Args and Returns sections are structured clearly without redundancy. Every sentence earns its place, making it efficient and easy to parse.
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 moderate complexity (runtime preset swapping), lack of output schema, and rich annotations, the description is mostly complete. It covers purpose, usage, parameters, and return summary, but could benefit from more detail on error cases or side effects (e.g., impact on active sessions).
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?
With 100% schema description coverage, the baseline is 3. The description adds value by explaining the purpose of 'preserve_overrides' in context ('preserves any runtime token overrides applied in the current session'), which enriches the schema's technical description. However, it doesn't detail the 'preset_id' pattern or default behavior 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 clearly states the action ('hot-swap'), the resource ('active preset'), and the key benefit ('without restarting the server'). It distinguishes from siblings like 'load_preset' by emphasizing the runtime nature and 'preserve_overrides' functionality, making the purpose specific and well-differentiated.
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 provides clear context for when to use it ('while building' and 'switching between client presets'), but doesn't explicitly state when NOT to use it or name alternatives like 'load_preset' or 'diff_presets'. The guidance is helpful but lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a React component against the active preset rules without modifying code. Returns a conformance score (0–100) and detailed issue list.
Args:
code (string): React component source code
include_suggestions (boolean): Include info-level suggestions (default: true)
Returns:
valid (boolean): No errors found
score (number): 0–100 conformance score
issues: Array of { severity, rule, message, fix } objects
presetUsed: Which preset was applied
Requires active preset.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | React component source code to validate | |
| include_suggestions | No | Include info-level suggestions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and idempotent behavior, which the description reinforces with 'without modifying code.' The description adds valuable context beyond annotations: it specifies the return format (score, issues, presetUsed) and the prerequisite of an active preset, which are not covered by 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 well-structured and front-loaded with the core purpose, followed by details. It uses bullet points for clarity, but the 'Args' and 'Returns' sections slightly repeat schema information, making it slightly verbose. Overall, it remains efficient and easy to scan.
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 (validation with scoring), rich annotations (read-only, idempotent), and no output schema, the description is complete: it explains the purpose, parameters, return values, and prerequisites. It adequately compensates for the lack of output schema by detailing the return structure.
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 fully documents both parameters. The description adds minimal semantics beyond the schema, only restating parameter purposes in the 'Args' section without additional context like validation rules or examples. Baseline 3 is appropriate given 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 the specific action ('validate a React component against the active preset rules') and resource ('React component'), distinguishing it from siblings like 'autocorrect_component' (which modifies code) or 'list_presets' (which lists presets). It explicitly notes 'without modifying code' to differentiate from mutation 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 provides clear context for when to use it ('validate a React component against the active preset rules') and includes a prerequisite ('Requires active preset'), but does not explicitly state when not to use it or name alternatives among siblings (e.g., 'autocorrect_component' for fixing issues).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes, but there is some overlap between autocorrect_component and validate_ui, as both analyze React components for conformance. However, autocorrect_component focuses on auto-correction while validate_ui is for validation only, and their descriptions clarify this difference. All other tools target clearly separate operations like preset management, token generation, and style suggestion.
All tool names follow a consistent snake_case pattern with clear verb_noun structures, such as apply_token_overrides, generate_color_palette, and load_preset. There are no deviations in naming conventions, making the set predictable and easy to understand.
With 14 tools, the server covers a comprehensive scope for UI preset management, including preset loading, token manipulation, component generation, correction, validation, and style suggestion. Each tool serves a specific function without redundancy, fitting well within the typical 3-15 tool range for a focused domain.
The tool set provides complete coverage for UI preset workflows, including CRUD-like operations for presets (list, load, scaffold, swap), token handling (apply, generate, diff), component interaction (generate, autocorrect, validate), and auxiliary functions like style suggestion and session state. There are no obvious gaps, enabling agents to perform end-to-end tasks without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live React design-system APIs, patterns, and code validation so AI agents build real UI, not slop.
Build and manage your design system with AI: tokens, themes, components, icons, Figma and code.
On-demand drift checks: declared CSS color, radius, spacing & type vs your own tokens or a pack
Access and maintain design system docs, tokens, components, skills, and contexts across any project.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ncsound919/OG-Glass'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
