How do I use fluentui-mcp-server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fluentui-mcp-server What are the props for the Avatar component?" 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.

fluentui-mcp-server

by aminvishvam

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

🚀 Fluent UI MCP Server

TypeScript Node.js MCP Fluent UI

A comprehensive Model Context Protocol (MCP) server that provides intelligent assistance for Fluent UI React component development. This server acts as your AI-powered companion for creating, validating, and maintaining Fluent UI applications following v9 design system patterns.

What is MCP? The Model Context Protocol enables AI assistants to securely access external data sources and tools. This server extends AI capabilities with deep Fluent UI knowledge.

✨ Key Features

🧠 Intelligent Component Knowledge

📚 Comprehensive database of 50+ Fluent UI v9 components
🔍 Smart component search and discovery
📖 Complete props, slots, and usage documentation
💡 Real-world examples and best practices
🎯 Context-aware recommendations

🎨 Design System Mastery

🌈 45+ design tokens across 6 categories (colors, typography, spacing, shadows, borders, motion)
✅ Token validation and usage guidance
🎭 Semantic color system with accessibility compliance
📏 Consistent spacing and typography scales
🎬 Motion and animation guidelines

🛠️ Advanced Code Generation

⚡ Generate complete v9 component implementations
🪝 Create custom hooks following Fluent UI patterns
💅 Generate styles using makeStyles and design tokens
📝 TypeScript interfaces with full type safety
🏗️ Template-based scaffolding for common patterns

✅ Smart Validation & Analysis

🔍 Real-time component validation against design specs
♿ Accessibility compliance checking (WCAG 2.1)
📊 Pattern analysis with scoring (0-100)
🚨 Anti-pattern detection and warnings
� Actionable improvement suggestions

Related MCP server: UI Toolkit MCP Server

🚀 Quick Start

npx fluentui-mcp-server

Prerequisites

Node.js 18+
npm or yarn
MCP-compatible client

Installation & Setup

# Clone or download the server
cd fluentui-mcp-server

# Install dependencies
npm install

# Build the server
npm run build

# Test the server
npm run test

Running the Server

# Start the MCP server
npm start

# Or run in development mode with hot reload
npm run dev

The published CLI executable points directly to dist/server.js.

🔧 Available Tools

The server provides 12 powerful tools organized into 4 categories:

📚 Component Knowledge Tools

`get_component_info`

Get comprehensive information about any Fluent UI component.

{
  "name": "get_component_info",
  "arguments": {
    "componentName": "Button"
  }
}

Returns: Complete component documentation including description, props, slots, examples, and accessibility guidelines.

`search_components`

Find components based on functionality, category, or keywords.

{
  "name": "search_components",
  "arguments": {
    "query": "form input",
    "category": "inputs",
    "limit": 5
  }
}

`get_component_props`

Get detailed property information for a specific component.

{
  "name": "get_component_props",
  "arguments": {
    "componentName": "Avatar",
    "propName": "size"
  }
}

`get_component_examples`

Retrieve usage examples for components.

{
  "name": "get_component_examples",
  "arguments": {
    "componentName": "Card",
    "exampleType": "advanced"
  }
}

🎨 Design System Tools

`get_design_tokens`

Access design tokens by category with usage guidance.

{
  "name": "get_design_tokens",
  "arguments": {
    "category": "colors",
    "includeUsage": true
  }
}

Categories: colors, typography, spacing, shadows, borders, motion

`validate_design_tokens`

Check code for proper token usage and suggest improvements.

{
  "name": "validate_design_tokens",
  "arguments": {
    "code": "const styles = makeStyles({ color: '#0078d4' });"
  }
}

🛠️ Code Generation Tools

`generate_component`

Generate complete component implementations with TypeScript.

{
  "name": "generate_component",
  "arguments": {
    "componentName": "CustomCard",
    "componentType": "layout",
    "requirements": "A card component for user profiles with avatar and bio"
  }
}

Component Types: form-input, layout, feedback, navigation

`generate_component_hook`

Create custom hooks following Fluent UI patterns.

{
  "name": "generate_component_hook",
  "arguments": {
    "componentName": "CustomButton",
    "hookType": "state-management"
  }
}

`generate_component_styles`

Generate makeStyles implementations with design tokens.

{
  "name": "generate_component_styles",
  "arguments": {
    "componentName": "CustomCard",
    "slots": ["root", "header", "content", "footer"]
  }
}

✅ Validation & Analysis Tools

`validate_component_design`

Comprehensive design validation with scoring.

{
  "name": "validate_component_design",
  "arguments": {
    "componentCode": "const Button = () => { ... }",
    "componentName": "Button"
  }
}

Returns: Validation score (0-100), issues found, and improvement suggestions.

`check_accessibility`

Analyze components for accessibility compliance.

{
  "name": "check_accessibility",
  "arguments": {
    "componentCode": "const Component = () => { ... }"
  }
}

`analyze_component_patterns`

Detect patterns and anti-patterns in component code.

{
  "name": "analyze_component_patterns",
  "arguments": {
    "componentCode": "const Component = () => { ... }"
  }
}

📦 Component Database

The server includes comprehensive knowledge for 50+ Fluent UI v9 components across all categories:

Button (+ variants: CompoundButton, MenuButton, SplitButton, ToggleButton)
Checkbox, Radio, Switch - Selection controls
Input, Textarea, SpinButton - Text input components
Combobox, Dropdown, Select - Selection components
Slider, Rating - Value input components
SearchBox, TagPicker - Advanced input patterns

Avatar, AvatarGroup - User representation
Badge, CounterBadge, PresenceBadge - Status indicators
Text, Label - Typography components
Image, Skeleton - Media and loading states
List, DataGrid, Table - Data presentation
Tree, Accordion - Hierarchical data

Card (+ variants: CardHeader, CardPreview, CardFooter)
Divider, Drawer - Space division
Dialog, Modal - Overlay components
Field, FieldGroup - Form layout

Breadcrumb, Link - Navigation aids
Menu, MenuList - Action menus
Nav, TabList - Primary navigation
Toolbar, CommandBar - Action toolbars

MessageBar, InfoBar - System messages
Toast, Notification - Temporary feedback
Popover, Tooltip - Contextual information
TeachingPopover - Educational overlays
ProgressBar, Spinner - Loading states

🎨 Design Token System

Access to the complete Fluent UI design token system with 45+ tokens across 6 categories:

🌈 Colors (8 tokens)

colorNeutralForeground1; // #242424 - Primary text
colorNeutralBackground1; // #ffffff - Default background
colorBrandBackground; // #0078d4 - Primary brand
colorStatusSuccessBackground1; // Success states
colorStatusErrorBackground1; // Error states
// ... and more

📝 Typography (9 tokens)

fontFamilyBase; // 'Segoe UI', system fonts
fontSizeBase100; // 10px
fontSizeBase200; // 12px
fontSizeBase300; // 14px
fontWeightRegular; // 400
fontWeightSemibold; // 600
// ... complete scale

📏 Spacing (11 tokens)

spacingHorizontalXS; // 2px
spacingHorizontalS; // 4px
spacingHorizontalM; // 8px
spacingHorizontalL; // 12px
spacingHorizontalXL; // 16px
// ... full spacing scale

🌫️ Shadows (4 tokens)

shadow2; // Subtle elevation
shadow4; // Card elevation
shadow8; // Dialog elevation
shadow16; // Maximum elevation

🔲 Borders (7 tokens)

borderRadiusNone; // 0px
borderRadiusSmall; // 2px
borderRadiusMedium; // 4px
borderRadiusLarge; // 6px
strokeWidthThin; // 1px
strokeWidthThick; // 2px

🎬 Motion (6 tokens)

durationUltraFast; // 50ms
durationFaster; // 100ms
durationFast; // 150ms
durationNormal; // 200ms
curveAccelerateMax; // Easing curves
curveDecelerateMax;

💡 Usage Examples

Example 1: Getting Component Information

echo '{"jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": {"name": "get_component_info", "arguments": {"componentName": "Button"}}}' | node dist/server.js

Example 2: Generating a Custom Component

echo '{"jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": {"name": "generate_component", "arguments": {"componentName": "UserCard", "componentType": "layout", "requirements": "A card showing user avatar, name, and role"}}}' | node dist/server.js

Example 3: Validating Component Design

echo '{"jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": {"name": "validate_component_design", "arguments": {"componentCode": "const Button = () => <button>Click</button>", "componentName": "Button"}}}' | node dist/server.js

🏗️ Architecture

Server Structure

src/
├── server.ts              # Main MCP server implementation
├── types.ts              # TypeScript interfaces
└── tools/
    ├── component-tools.ts    # Component knowledge & search
    ├── design-tools.ts       # Design tokens & validation
    ├── generation-tools.ts   # Code generation templates
    └── validation-tools.ts   # Design & accessibility validation
data/
├── components.json       # Component database
└── patterns.json        # Design patterns & templates

Key Technologies

MCP SDK: Model Context Protocol implementation
TypeScript: Full type safety and IntelliSense
Node.js: Runtime environment
JSON-RPC 2.0: Communication protocol

🔧 Development

Development Workflow

# Install dependencies
npm install

# Development mode with hot reload
npm run dev

# Build for production
npm run build

# Run tests
npm test

# Lint code
npm run lint

# Type checking
npm run type-check

Project Scripts

npm start - Start the MCP server
npm run dev - Development mode with tsx
npm run build - TypeScript compilation
npm test - Test server functionality
npm run lint - ESLint code checking

Testing the Server

# Test that server starts and lists tools
npm run test

# Manual testing with curl/echo
echo '{"jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {}}' | node dist/server.js

🤝 Integration

MCP Client Integration

This server is compatible with any MCP client. Here's how to integrate:

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "fluentui": {
      "command": "npx",
      "args": ["-y", "fluentui-mcp-server"]
    }
  }
}

Custom MCP Client

import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";

const client = new Client(
  {
    name: "my-app",
    version: "1.0.0",
  },
  {
    capabilities: {},
  },
);

const transport = new StdioClientTransport({
  command: "npx",
  args: ["-y", "fluentui-mcp-server"],
});

await client.connect(transport);

📋 Validation Rules

The server implements comprehensive validation rules:

Design Validation

✅ Proper use of design tokens
✅ Consistent spacing and typography
✅ Color contrast compliance
✅ Component composition patterns

Accessibility Validation

✅ ARIA attributes and roles
✅ Keyboard navigation support
✅ Focus management
✅ Screen reader compatibility
✅ Color contrast ratios (WCAG 2.1)

Code Quality Validation

✅ TypeScript type safety
✅ Fluent UI v9 patterns
✅ Performance best practices
✅ Component composition

🚀 Contributing

We welcome contributions! Here's how to get started:

1. Fork & Clone

git clone https://github.com/yourusername/fluentui-mcp-server.git
cd fluentui-mcp-server

2. Create Feature Branch

git checkout -b feature/new-component-support

3. Make Changes

Add new components to data/components.json
Implement new tools in src/tools/
Add tests for new functionality
Update documentation

4. Test Changes

npm run build
npm test
npm run lint

5. Submit Pull Request

Ensure all tests pass
Add documentation for new features
Follow existing code style

Areas for Contribution

🆕 New Components: Add more Fluent UI components
🛠️ Enhanced Tools: Improve existing tool capabilities
📊 Better Validation: Add more validation rules
🎨 Design Patterns: Expand pattern library
📖 Documentation: Improve guides and examples

📄 License

MIT License - see LICENSE file for details.

📚 Fluent UI React Components - Official documentation
🎨 Design Tokens - Token system guide
🏗️ Component Implementation Guide - Development patterns
🔄 Migration Guide - v8 to v9 migration
🔌 Model Context Protocol - MCP specification
🤖 Claude Desktop - MCP-compatible AI assistant

Built with ❤️ for the Fluent UI community

Made with Model Context Protocol • Fluent UI v9 • TypeScript

Available Tools

12 tools

analyze_component_patternsB

Analyze component code for adherence to Fluent UI v9 patterns

ParametersJSON Schema

Name	Required	Description	Default
`componentCode`	Yes	Component code to analyze

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must fully disclose behavioral traits. It states the tool analyzes code but does not clarify if it is read-only, destructive, requires permissions, or what the response contains (beyond 'adherence' analysis).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words, effectively communicating the tool's action and scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple single-parameter input and no output schema, the description is minimally adequate. However, it lacks details on what the analysis outputs (e.g., structured report vs. plain text) and what 'adherence' means, leaving some ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter 'componentCode', and its schema description states 'Component code to analyze'. The tool description adds no additional meaning, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the verb 'analyze', the resource 'component code', and the specific context 'Fluent UI v9 patterns', distinguishing it from sibling tools like 'get_component_info' which retrieve info rather than analyze adherence.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'search_components' or 'get_component_info'. It does not specify prerequisites, exclusions, or preferred use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_accessibilityC

Check component code for accessibility compliance

ParametersJSON Schema

Name	Required	Description	Default
`componentCode`	Yes	Component code to check for accessibility issues

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description must fully disclose behavior, but it only says 'check' without explaining what the check involves (e.g., automated scan, return format, side effects). This leaves the agent guessing about the tool's operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words. It is front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema or behavioral details. For a compliance check, the agent needs to know what the output looks like (e.g., a list of issues, a pass/fail status) and any prerequisites. The description is insufficient for reliable invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds no extra meaning beyond the schema's parameter description. The schema already states 'Component code to check for accessibility issues', while the tool description simply says 'Check component code for accessibility compliance', which is less informative.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'check' and the resource 'component code' for accessibility compliance, distinguishing it from sibling tools like search_components or generate_component. However, it could be more specific about what 'accessibility compliance' entails (e.g., WCAG standards).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like analyze_component_patterns or validate_component_design. The description lacks any context for appropriate invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_componentB

Generate a complete Fluent UI v9 component implementation

ParametersJSON Schema

Name	Required	Description
`props`	No	Component props specification
`slots`	No	Component slots specification
`componentName`	Yes	Name of the component to generate
`componentType`	No	Type of component to generate

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but only states 'generate' without disclosing side effects, file overwriting, required templates, or output format. Behavioral traits are opaque.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, concise and direct. While it lacks structural elements like bullet points, it packs essential purpose without verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given this is a generation tool with 4 parameters (including slots/props) and no output schema, the description fails to explain what 'complete implementation' entails, what the agent receives, or how parameters influence generation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 parameters. The description adds no extra meaning or interaction context beyond the schema baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Generate' and identifies the resource as 'complete Fluent UI v9 component implementation', clearly distinguishing it from sibling tools like get_component_info (read-only) and generate_component_hook (partial).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_component_hookB

Generate a component hook following Fluent UI v9 patterns

ParametersJSON Schema

Name	Required	Description	Default
`componentName`	Yes	Name of the component

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden for behavioral disclosure. It only states it follows patterns but does not mention side effects (e.g., file creation), required permissions, or any constraints. This is insufficient for a generation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It efficiently states the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter and no output schema, the description is minimally adequate but lacks details on the generated hook's structure or behavior. More context (e.g., output format or effect) would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema's 'Name of the component'. The single parameter is adequately documented by the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates a 'component hook' following Fluent UI v9 patterns, differentiating it from siblings like 'generate_component' and 'generate_component_styles'. However, it does not elaborate on what a hook is, leaving some ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool over alternatives such as 'generate_component' (which may generate the entire component) or 'get_component_info'. The agent receives no context for decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_component_stylesB

Generate component styles using makeStyles following Fluent UI patterns

ParametersJSON Schema

Name	Required	Description	Default
`slots`	No	Component slots to style
`componentName`	Yes	Name of the component

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It fails to disclose any side effects, output format, or constraints beyond the vague 'following Fluent UI patterns'. Does not describe what happens to existing files.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no filler. However, it could include more structured information without losing conciseness, such as listing prerequisites or output format.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a generative tool with no output schema, the description is too sparse. It does not explain the output, slot usage, or what 'makeStyles' entails. More context is needed for an AI agent to correctly invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 both parameters. The description adds no additional meaning beyond the schema; it merely restates the purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'generate' and resource 'component styles' with a method 'makeStyles following Fluent UI patterns'. It clearly distinguishes from sibling tools like 'generate_component' which would generate the whole component, and 'get_component_info' for retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as 'generate_component' or 'get_design_tokens'. No prerequisites or exclusions mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_component_examplesA

Get code examples and usage patterns for a Fluent UI component

ParametersJSON Schema

Name	Required	Description	Default
`exampleType`	No	Type of examples to retrieve
`componentName`	Yes	Name of the Fluent UI component

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries behavioral burden. It describes a read operation ('Get') with no side effects, which is fine, but it lacks details like output format or data source, leaving some ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no filler, front-loaded action. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description could clarify the response structure. It says 'code examples and usage patterns' but no detail on format or content, though the tool's simplicity and sibling context mitigate some gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with both parameters documented. The description adds no additional meaning beyond the schema or enum values, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves 'code examples and usage patterns' for a Fluent UI component, using a specific verb and resource. This distinguishes it from siblings like get_component_info (general info) and search_components (search).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when code examples are needed but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_component_infoA

Get comprehensive information about a Fluent UI component including props, slots, and examples

ParametersJSON Schema

Name	Required	Description	Default
`componentName`	Yes	Name of the Fluent UI component (e.g., Button, Avatar, Dialog)

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full weight. It mentions the types of information returned (props, slots, examples) but lacks details on format, limitations, or whether any actions are performed. For a read-only informational tool, this is acceptable but minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, well-structured sentence that conveys the tool's purpose and key outputs without unnecessary words. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (one parameter, no output schema), the description adequately covers what the tool does and what it returns. Sibling tools provide context for differentiation. Minor gap: no mention of return structure or depth of examples.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is only one parameter (componentName) and the schema already provides a clear description of its purpose. The tool description adds no further parameter context, but schema coverage is 100%, so a score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets comprehensive information about a Fluent UI component, listing specific aspects (props, slots, examples). This distinguishes it from siblings like get_component_props and get_component_examples which serve narrower purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives. While the description implies it's for broad info gathering, it doesn't specify when not to use it (e.g., when only props are needed). Siblings exist but no comparison is drawn.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_component_propsB

Get detailed prop information for a specific Fluent UI component

ParametersJSON Schema

Name	Required	Description	Default
`componentName`	Yes	Name of the Fluent UI component

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must convey behavioral traits. It only states 'get detailed prop information' without disclosing key details like read-only nature, response format, or any constraints. This leaves significant ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that directly conveys the purpose. While it lacks depth, it does not waste words. It is appropriately concise for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter and no output schema, the description is minimally sufficient. However, it fails to explain what 'detailed prop information' includes or any limitations, which could hinder correct use. It is adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a description for componentName. The description adds little extra meaning beyond 'Fluent UI component', which is already implied. Baseline 3 is appropriate as the schema handles the parameter semantics adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get'), the resource ('detailed prop information'), and the target ('Fluent UI component'), effectively distinguishing it from siblings like get_component_info or search_components.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. With 11 siblings, explicit context on when to use get_component_props vs get_component_info or get_component_examples is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_design_tokensB

Get Fluent UI design tokens for colors, typography, spacing, etc.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No	Optional: Filter tokens by category

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description only states 'Get Fluent UI design tokens' without disclosing behavioral traits such as authentication needs, rate limits, or what occurs upon missing parameters. The description offers minimal transparency beyond the basic operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence of 12 words, front-loaded with the core action. Every word is functional with no redundancy. It is as concise as possible given the simplicity of the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-optional-parameter tool with no output schema, the description minimally conveys purpose but lacks detail on return format or structure. It is adequate but could mention what the tokens represent or how they are returned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of parameters with enum and descriptions. The description adds no new meaning beyond the schema; it merely lists examples that match the enum values. Baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves Fluent UI design tokens for categories like colors, typography, spacing, etc. The verb 'get' and resource 'design tokens' are specific and distinguish it from sibling tools focused on components or validation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. Sibling tools exist (e.g., search_components, validate_design_tokens) but no explicit conditions or exclusions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_componentsB

Search for Fluent UI components by functionality, category, or keywords

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query for finding relevant components
`category`	No	Optional: Filter by component category

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It only states that the tool accepts search criteria, but fails to disclose important behavioral aspects such as what is returned (e.g., a list of component names), pagination behavior, or any limits. This is insufficient for a search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that communicates the core functionality without unnecessary words. It front-loads the action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, so the description should explain what the tool returns (e.g., component names, IDs, or details). It lacks this critical information, leaving the agent uncertain about how to use the results. Additionally, it does not mention any default behavior when the optional category parameter is omitted.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, meaning the schema already explains both parameters. The description adds marginal value by paraphrasing the search criteria ('by functionality, category, or keywords'), but does not provide additional meaning or constraints beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the tool's verb ('Search') and resource ('Fluent UI components'), and further defines search criteria ('functionality, category, or keywords'). This distinguishes it from sibling tools like get_component_info which retrieves details of a known component.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The implied usage is for locating components, as opposed to sibling tools that retrieve specific information. However, there is no explicit guidance on when to use this tool versus alternatives, nor any mention of when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_component_designB

Validate component implementation against Fluent UI design specifications

ParametersJSON Schema

Name	Required	Description	Default
`componentCode`	Yes	Component code to validate
`componentName`	No	Name of the component being validated

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It only says 'validate', suggesting a read operation, but does not explain what happens on validation failure, whether any changes occur, or if there are side effects. This is insufficient for full transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the purpose. It could be more informative, but it is efficient and without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 2 parameters and no output schema. The description does not explain the return value or validation process, which is crucial for a validation tool. It lacks completeness for an agent to fully understand what to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters having standard descriptions. The tool's description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Validate component implementation against Fluent UI design specifications'. It uses a specific verb (validate) and resource (component implementation), distinguishing it from sibling tools like 'validate_design_tokens' or 'check_accessibility'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for validation against specs but does not explicitly state when to use it over alternatives or provide usage prerequisites. No guidance on when not to use it is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_design_tokensC

Validate the usage of design tokens in component code

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Component code to validate token usage

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose whether the tool is read-only, what outputs are produced, or any other behavioral traits. Validation implies checking but no side effects are stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, concise and to the point. However, it is slightly minimal for a validation tool that might benefit from output details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description lacks completeness. It does not explain return values, error behavior, or prerequisites for using this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema fully describes the 'code' parameter with 100% coverage. The description adds no additional meaning beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it validates design token usage in component code. However, it does not differentiate from the sibling 'validate_component_design', which seems similar.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like 'validate_component_design' or 'analyze_component_patterns'. The description only states function, not context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

12 tool updatesv1.0.0Jul 30, 2026
- First observedanalyze_component_patterns
- First observedcheck_accessibility
- First observedgenerate_component
- First observedgenerate_component_hook
- First observedgenerate_component_styles
- First observedget_component_examples
- First observedget_component_info
- First observedget_component_props
- First observedget_design_tokens
- First observedsearch_components
- First observedvalidate_component_design
- First observedvalidate_design_tokens

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-07-30 09:15 across 12 tools

Disambiguation5/5

Each tool has a distinct purpose: information retrieval, search, token validation, code generation, accessibility checks, and pattern analysis. No overlapping responsibilities.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_component_info, generate_component). No mixing of conventions.

Tool Count5/5

12 tools cover the domain of Fluent UI development well without being excessive. Each tool earns its place.

Completeness5/5

The tool surface covers searching, retrieving details, validating tokens, generating components/hooks/styles, checking accessibility, and analyzing patterns. No obvious gaps for the stated purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Svelte MCP A
dev.svelte
The official Svelte MCP server providing docs and autofixing tools for Svelte development
Developer Tools Documentation Access Code Analysis
42324
RevoGrid DataGrid MCP A
io.github.revolist
Token-free MCP server for structured RevoGrid Core, Pro, and Enterprise knowledge retrieval.
Documentation Access Developer Tools
823,392
secureflows-mcp A
io.github.michal-lefler
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Code Analysis Developer Tools Security
181
proverOAuth
com.axiomatic-ai
Lean 4 MCP server: compile, prove theorems, and formalize math with Mathlib.
Developer Tools Code Analysis Research & Data
2

Related MCP Servers

bunge-ds-mcp
Design Tools Developer Tools
tabaldi98
A
license
A
quality
C
maintenance
MCP server that exposes the @bunge/ds-components design system catalog, allowing AI assistants to list, search, and retrieve component details including inputs, outputs, usage examples, and import instructions.
Updated 4 months ago (2026-05-05 11:42 UTC)
4
MIT
UI Toolkit MCP Server
Design Tools Developer Tools Testing & QA Tools
elsahafy
A
license
A
quality
F
maintenance
Comprehensive MCP server for end-to-end UI development, offering tools to generate components, manage design tokens, audit accessibility, autofix issues, inspect live pages, compare screenshots, and more across multiple frameworks.
Updated 3 months ago (2026-06-24 07:23 UTC)
13
7 npm
MIT
forgekit-storybook-mcp
Developer Tools Testing & QA Tools Code Analysis
the-single-gentlemans-club
A
license
Not graded
quality
D
maintenance
MCP server for automatic Storybook story generation, component analysis, and validation. Auto-detects React frameworks and syncs component documentation.
Updated 4 months ago (2026-05-09 22:48 UTC)
49 npm
1
MIT
@lando-labs/lando-ds-mcpofficial
Design Tools Developer Tools
lando-labs
A
license
A
quality
A
maintenance
MCP server for the Lando Labs Design System, enabling AI agents to introspect and generate code for React components, hooks, icons, design tokens, and theme presets via 15 tools.
Updated a month ago (2026-08-17 12:55 UTC)
15
6 npm
1
Apache 2.0

🚀 Fluent UI MCP Server

✨ Key Features

🧠 Intelligent Component Knowledge

🎨 Design System Mastery

🛠️ Advanced Code Generation

✅ Smart Validation & Analysis

🚀 Quick Start

Prerequisites

Installation & Setup

Running the Server

🔧 Available Tools

📚 Component Knowledge Tools

get_component_info

search_components

get_component_props

get_component_examples

🎨 Design System Tools

get_design_tokens

validate_design_tokens

🛠️ Code Generation Tools

generate_component

generate_component_hook

generate_component_styles

✅ Validation & Analysis Tools

validate_component_design

check_accessibility

analyze_component_patterns

📦 Component Database

🎨 Design Token System

🌈 Colors (8 tokens)

📝 Typography (9 tokens)

📏 Spacing (11 tokens)

🌫️ Shadows (4 tokens)

🔲 Borders (7 tokens)

🎬 Motion (6 tokens)

💡 Usage Examples

Example 1: Getting Component Information

Example 2: Generating a Custom Component

Example 3: Validating Component Design

🏗️ Architecture

Server Structure

Key Technologies

🔧 Development

Development Workflow

Project Scripts

Testing the Server

🤝 Integration

MCP Client Integration

Claude Desktop

Custom MCP Client

📋 Validation Rules

Design Validation

Accessibility Validation

Code Quality Validation

🚀 Contributing

1. Fork & Clone

2. Create Feature Branch

3. Make Changes

4. Test Changes

5. Submit Pull Request

Areas for Contribution

📄 License

🔗 Related Resources

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

@lando-labs/lando-ds-mcpofficial

`get_component_info`

`search_components`

`get_component_props`

`get_component_examples`

`get_design_tokens`

`validate_design_tokens`

`generate_component`

`generate_component_hook`

`generate_component_styles`

`validate_component_design`

`check_accessibility`

`analyze_component_patterns`