Stop Your AI From Hallucinating FluentUI Props

#ai #webdev #react #typescript

You ask your AI assistant to build a button. It confidently writes:

<Button variant="huge" rounded glow>Click me</Button>

Looks great. Ships nothing. None of those props exist in FluentUI v9. Your AI just made them up — politely, fluently, and completely wrong.

If you've paired with an LLM on a real component library, you know this dance. The model sounds authoritative while quietly inventing an API that was never there. So you stop, open the docs in another tab, fix the props by hand, and wonder why you bothered asking in the first place.

I got tired of that loop. So we built fluentui-mcp — a Model Context Protocol server that hands your AI the real FluentUI v9 documentation, on demand.

What is it, in one breath?

It's an MCP server that plugs into Claude, Cline, Cursor, and any other MCP-aware assistant, and gives them 12 specialized tools to query actual FluentUI documentation — props, slots, examples, patterns, accessibility notes — instead of guessing from whatever they half-remember from training data.

No more hallucinated props. No more accidental v8 patterns in a v9 project. No more dumping an entire docs site into your context window.

The problem → the solution

Without it, AI assistants tend to:

❌ Invent component props that don't exist
❌ Mix outdated v8 patterns into v9 code
❌ Swallow your whole context window loading docs "just in case"
❌ Skip accessibility requirements and established patterns

With it, they get:

✅ Accurate, up-to-date component documentation
✅ Smart search across 100+ documentation pages
✅ Props references, code examples, and patterns on demand
✅ Component suggestions from a plain-English UI description
✅ ~90% context-window reduction vs. loading all the docs

That last point matters more than it sounds. Context is your most expensive, most finite resource in an AI session. Fetching only the DataGrid props table when you need it — instead of the entire component library — is the difference between a focused assistant and one that's already forgotten what you asked.

How it actually works

The trick is that nothing is parsed at runtime. A single pre-built JSON schema bundles all the documentation, and it's generated offline by a two-stage pipeline:

┌─────────────┐   ┌──────────────┐   ┌─────────────────────────┐
│   Scraper   │ → │   Enhancer   │ → │  fluentui-schema-       │
│ (ts-morph)  │   │  (LLM-based) │   │  enhanced.json (bundled)│
└─────────────┘   └──────────────┘   └─────────────────────────┘
   Extracts          Adds AI            Single source of truth
   props/slots/      descriptions,      shipped with the package
   stories from      best practices,
   FluentUI source   a11y, patterns

A scraper uses ts-morph to extract real props, slots, and stories straight from the FluentUI source — so the data is grounded in actual TypeScript, not vibes.
An LLM enhancer layers on human-readable descriptions, best practices, accessibility notes, and pattern guidance.
The result is one bundled schema the server loads into memory at startup (under a second) and serves instantly via a TF-IDF search index.

The whole thing ships with the npm package. No network calls, no API keys at runtime, no surprises.

The 12 tools (the fun part)

The full toolbox covers documentation, intelligence, and utilities — but a few stand out for day-to-day work:

suggest_components — Describe a UI in plain English ("a user profile card with avatar and actions") and get back which FluentUI components to reach for, and why.
get_implementation_guide — Give it a goal ("build a settings page with form validation") and it stitches together the relevant docs, patterns, and code examples into one step-by-step guide.
query_component — Full documentation for a single component, with fuzzy name matching so "button" finds Button.
get_props_reference — Just the props table. Nothing else. Perfect for a quick "wait, what's that prop called again?" lookup.
search_docs — Ranked full-text search across components, patterns, and enterprise guides.

There are seven more — category listings, foundation/theming docs, enterprise dashboard patterns, code-example extraction, and index utilities — but you get the idea: the AI pulls exactly what it needs, exactly when it needs it.

Show, don't tell

Here's the part that actually convinced me. These are real UIs built by an AI assistant with the MCP server connected — accurate props, proper patterns, accessible markup, first try.

An admin panel — DataGrid, navigation, and layout, all using correct FluentUI v9 APIs.

A todo app — forms, inputs, and feedback components composed the way the docs actually recommend.

Cline in VS Code, calling the fluentui-mcp tools live as it writes code.

No prop-fixing afterward. No "actually that component doesn't exist." Just working FluentUI.

Two-minute setup

Install it globally:

npm install -g fluentui-mcp

Then point your assistant at it. For Cline (VS Code), add to your MCP settings:

{
    "mcpServers": {
        "fluentui-docs": {
            "command": "fluentui-mcp"
        }
    }
}

Same config works for Claude Desktop (claude_desktop_config.json). Restart your assistant and the tools light up automatically.

Want to pin a specific version, or run several side by side? Pass the version as an argument:

{
    "mcpServers": {
        "fluentui-v9": {
            "command": "fluentui-mcp",
            "args": ["v9"]
        }
    }
}

That's it. 🎉

Wrap-up

LLMs are fantastic at structure and terrible at recall for fast-moving libraries. The fix isn't a bigger model — it's giving the model a reliable source of truth to look things up in. That's exactly what MCP is for, and fluentui-mcp is that source of truth for FluentUI v9.

If you build React UIs with FluentUI and an AI pair, give it a spin: