The Challenge of Migrating to Fluent UI Blazor V5

Microsoft Fluent UI Blazor version 5 brings a wealth of new features, breaking changes, and refactoring. With over 142 components available, browsing the documentation to find the right parameter, understand an enum, or adapt your existing code can quickly become time-consuming.

What if your AI assistant — GitHub Copilot, Claude, Cursor — could directly access the complete documentation for every component, including migration guides?

That’s exactly what the Fluent UI Blazor MCP Server offers.

What Is an MCP Server?

The Model Context Protocol (MCP) is an open standard that enables AI agents to access external data sources — tools, APIs, documentation — through a unified protocol. In practice, an MCP server exposes tools (automatically invoked by the AI) and resources (manually attached to a conversation) that your IDE can leverage.

Instead of copy-pasting documentation into your prompt, the MCP server makes it natively accessible to the AI.

The Fluent UI Blazor MCP Server

I contributed to the creation of this MCP server, now available as an official NuGet package. It provides your AI assistant with full access to the Fluent UI Blazor V5 documentation:

Available Tools (automatically invoked by the AI)

Available Resources (attached by the user)

Installation

Option 1: .NET Global Tool (recommended)

Install the MCP server as a global tool:

dotnet tool install -g Microsoft.FluentUI.AspNetCore.McpServer

Then configure your .vscode/mcp.json file:

{
    "servers": {
        "fluent-ui-blazor": {
            "command": "fluentui-mcp"
        }
    }
}

Option 2: Using dnx (no installation required)

If you’re using .NET 10+, you can use the dnx script to run the server on the fly:

{
    "servers": {
        "fluent-ui-blazor": {
            "type": "stdio",
            "command": "dnx",
            "args": [
                "Microsoft.FluentUI.AspNetCore.McpServer",
                "--yes"
            ]
        }
    }
}

This method automatically downloads the latest version from NuGet.org. You can also pin a specific version:

dnx Microsoft.FluentUI.AspNetCore.McpServer@5.0.1

Option 3: Build from Source

To contribute or customize the server:

cd src/Tools/McpServer
dotnet build

{
    "servers": {
        "fluent-ui-blazor": {
            "type": "stdio",
            "command": "dotnet",
            "args": [
                "run",
                "--project",
                "src/Tools/McpServer/Microsoft.FluentUI.AspNetCore.McpServer.csproj"
            ],
            "env": {
                "DOTNET_ENVIRONMENT": "Development"
            }
        }
    }
}

Real-World Usage Examples

Once the MCP server is configured, your AI assistant can answer questions like:

“What Button-type components are available?” → The AI automatically invokes ListComponents(category: "Button") and returns the complete list.

“How do I use FluentDataGrid with sorting and pagination?” → The AI calls GetComponentDetails(componentName: "FluentDataGrid") and retrieves all documented parameters, events, and methods.

“Which enum should I use for button appearance?” → GetEnumValues(enumName: "Appearance") returns all possible values.

“How do I migrate my code from V4 to V5?” → GetMigrationGuide() provides the complete migration guide directly in the AI’s context.

Architecture: Security and Performance

The MCP server was designed with strict security principles:

The architecture relies on a documentation JSON pre-generated at build time from the project’s XML docs, then embedded as a resource in the package. This ensures fast startup and documentation that is always consistent with the package version.

┌─────────────────────────────────────────────────┐
│ FluentUI.Demo.DocApiGen (Build Time)            │
│ ├── Uses LoxSmoke.DocXml                        │
│ └── Generates FluentUIComponentsDocumentation.json
└─────────────────────────────────────────────────┘
                    │
                    ▼ (PreBuild / EmbeddedResource)
┌─────────────────────────────────────────────────┐
│ McpServer (Runtime)                             │
│ └── Reads JSON from embedded resource           │
└─────────────────────────────────────────────────┘

Compatible with Visual Studio Code AND Visual Studio 2026

The MCP server works with:

• Visual Studio Code via .vscode/mcp.json
• Visual Studio 2026 via .mcp.json at the solution root
• Any compatible MCP client (MCP Inspector, Claude Desktop, etc.)

Why This Is a Game-Changer for V5

Migrating to a new major version of a component library is always a delicate moment. With the Fluent UI Blazor MCP Server:

1. No more searching through docs — The AI has native access to all documentation
2. Built-in migration guide — GetMigrationGuide() provides breaking changes and migration steps
3. Component discovery — Don’t know all 142+ components yet? The AI can present them by category
4. Accelerated prototyping — Ask the AI to generate a FluentDataGrid with pagination — it knows all the parameters

Useful Links

• NuGet Package — Microsoft.FluentUI.AspNetCore.McpServer
• GitHub Repository — microsoft/fluentui-blazor
• Fluent UI Blazor Demo Site
• What’s New — Fluent UI Blazor
• Model Context Protocol — Specification
• dnx Documentation (.NET 10)

Conclusion

The Fluent UI Blazor MCP Server turns your AI assistant into a Fluent UI Blazor expert. No more juggling between your IDE and the documentation — everything is directly accessible within your AI conversation.

If you’re starting your migration to V5 or kicking off a new Blazor project with Fluent UI, install the MCP server — your productivity will thank you.

dotnet tool install -g Microsoft.FluentUI.AspNetCore.McpServer

Happy coding!

Read more

The Model Context Protocol: A Revolution… and an Attack Surface

The Model Context Protocol (MCP) is rapidly establishing itself as the open standard enabling AI agents — GitHub Copilot, Claude, Cursor, and many others — to access external tools, databases, and APIs. In practice, an mcp.json file declared in your project allows your IDE to interact with remote or local servers that expose additional capabilities to the AI.

It’s powerful. It’s also dangerous if these servers aren’t audited.

Security Risks Associated with MCP Servers

The security community has already identified several attack vectors specific to MCP servers:

Prompt Injection

A malicious MCP server can inject content into its tool descriptions to manipulate AI agent behavior. The agent then performs actions not intended by the user, in complete transparency.

• Invariant Labs — MCP Security Notification: Tool Poisoning Attacks
• OWASP — Prompt Injection

Tool Poisoning

A tool exposed by an MCP server can be compromised: instead of executing the expected action, it runs malicious code — reading sensitive files, executing system commands, exfiltrating tokens.

• Snyk — Securing AI Agents: Understanding MCP Tool Poisoning

Toxic Flows (WhatsApp-style Data Exfiltration)

When an AI agent uses multiple MCP tools in a chain, a compromised tool can transmit data collected by a legitimate tool to a malicious server. This is the principle behind toxic tool-call flows.

• Trail of Bits — MCP Security Review

Rug Pull Attacks

An MCP server can silently modify the behavior of its tools after the user has approved them. The visible description remains unchanged, but the executed code is different — a particularly insidious scenario.

• Pillar Security — The Security Risks of Model Context Protocol

The Reality: Nobody Is Auditing MCP Servers

During an engagement with a client, we noticed that development teams were adding MCP servers to their VS Code configurations without any validation process. Each developer could declare their own servers, with zero visibility for the security team.

The questions that arose:

• Which MCP servers are being used across the organization?
• Are they trustworthy? Could a third-party HTTP server be compromised between deployments?
• How can we detect silent changes in the tools exposed by a server?

The Solution: An Automated MCP Scanner in GitHub Actions

We developed a GitHub Actions workflow that:

1. Automatically discovers all mcp.json files in the repository
2. Runs mcp-scan (Snyk’s open-source tool) on each configuration
3. Analyzes every tool, prompt, and resource exposed by the declared MCP servers
4. Generates a JUnit XML test report displayed directly in the Pull Request Checks tab
5. Publishes a Markdown summary in the Job Summary of each run

Pipeline Architecture

mcp.json → mcp-scan (analysis) → JSON → JUnit XML + Markdown → GitHub Actions (Test Report + Summary)

Automatic Triggers

The weekly scan is essential: it detects rug pull attacks, i.e., silent server-side modifications that occur between commits.

GitHub Actions Workflow Example

name: MCP Security Scan

on:
  push:
    branches: [main]
    paths:
      - '**/*mcp*.json'
  pull_request:
    branches: [main]
    paths:
      - '**/*mcp*.json'
  schedule:
    - cron: '0 8 * * 1'
  workflow_dispatch:

permissions:
  contents: read
  checks: write
  pull-requests: write

jobs:
  mcp-scan:
    name: Scan MCP Configurations
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install uv
        uses: astral-sh/setup-uv@v4

      - name: Run mcp-scan
        run: |
          MCP_FILES=$(find . -name "mcp.json" -o -name "mcp*.json" \
            | grep -v node_modules | grep -v .git/)
          uvx mcp-scan@latest --json --server-timeout 30 $MCP_FILES \
            > mcp-scan-results.json 2>mcp-scan-stderr.log || true

      - name: Convert results to JUnit XML
        run: |
          python .github/scripts/mcp-scan-to-junit.py \
            mcp-scan-results.json \
            mcp-scan-results.xml \
            mcp-scan-summary.md
          cat mcp-scan-summary.md >> "$GITHUB_STEP_SUMMARY"

      - name: Publish Test Report
        uses: dorny/test-reporter@v1
        if: always()
        with:
          name: MCP Security Scan Results
          path: mcp-scan-results.xml
          reporter: java-junit
          fail-on-error: false

Reading the Results

Results appear directly in the GitHub interface:

• Checks tab on the PR: each MCP server is a test suite, each tool is a test case
  • ✅ Passed — no issues detected
  • ❌ Failed — vulnerability detected (prompt injection, tool poisoning, etc.)
  • ⚠️ Error — server unreachable or timeout
• Job Summary: summary table per server with the number of tools analyzed and alerts

Result Conversion: The Python Script

The core of the system relies on a Python script that converts the JSON output from mcp-scan into a JUnit XML report consumable by dorny/test-reporter. Each tool exposed by an MCP server is evaluated against a risk score:

• Tools with a score above the threshold (0.5) are marked as failed
• Unreachable servers are marked as error
• Healthy tools are marked as passed

This JUnit format leverages the existing ecosystem: native integration with GitHub, Azure DevOps, Jenkins, etc.

Value Proposition

Going Further

MCP Security Resources

• Model Context Protocol — Official Specification
• Snyk agent-scan (mcp-scan) — GitHub
• Invariant Labs — MCP Security Notifications
• OWASP Top 10 for LLM Applications
• Trail of Bits — The Model Context Protocol and its Security Implications
• Pillar Security — The Security Risks of MCP
• Snyk — Securing AI Agents: Understanding MCP Tool Poisoning

GitHub Actions Used

• dorny/test-reporter — Display test reports in GitHub
• astral-sh/setup-uv — Install uv to run mcp-scan
• actions/upload-artifact — Archive results

Conclusion

The massive adoption of MCP in AI-assisted development tools creates a new attack surface that most organizations have not yet addressed. A compromised MCP server can exfiltrate source code, secrets, or silently manipulate an AI agent’s behavior.

Setting up an automated scanner, integrated into your CI/CD pipeline, is an essential first step to regain control over this emerging supply chain. All at zero cost, with no additional infrastructure, and native GitHub Actions integration.

Don’t wait for an incident to audit your MCP servers.

Read more

Introduction to DevBox and its Benefits

DevBox is a powerful development environment that allows developers to create, test, and deploy applications in a cloud-based environment. By using DevBox with Microsoft Azure, developers can take advantage of Azure’s robust infrastructure, scalability, and security features. This combination provides a seamless and efficient development experience, enabling developers to focus on writing code and delivering high-quality applications.

Step-by-Step Instructions on How to Use DevBox with Microsoft Azure

Step 1: Set Up Your Azure Account

1. If you don’t already have an Azure account, sign up for a free account at Azure Free Account.
2. Once you have an account, log in to the Azure Portal.

Step 2: Create a DevBox Environment

1. In the Azure Portal, navigate to the “DevBox” service.
2. Click on “Create DevBox” to start the setup process.
3. Fill in the required details, such as the name of your DevBox, the region, and the resource group.
4. Choose the desired configuration for your DevBox, including the operating system, virtual machine size, and storage options.
5. Click “Review + Create” to review your settings and then click “Create” to deploy your DevBox environment.

Step 3: Connect to Your DevBox

1. Once your DevBox environment is deployed, navigate to the “DevBox” service in the Azure Portal.
2. Click on your newly created DevBox to view its details.
3. Click on the “Connect” button to download the RDP file for remote access.
4. Open the RDP file and enter your credentials to connect to your DevBox environment.

Step 4: Set Up Your Development Environment

1. After connecting to your DevBox, install the necessary development tools and software, such as Visual Studio, Visual Studio Code, or any other IDE of your choice.
2. Configure your development environment according to your project requirements.

Step 5: Develop and Test Your Application

1. Start writing code and developing your application in the DevBox environment.
2. Use Azure services, such as Azure App Service, Azure Functions, and Azure SQL Database, to enhance your application and take advantage of cloud capabilities.
3. Test your application thoroughly to ensure it works as expected.

Step 6: Deploy Your Application

1. Once your application is ready, deploy it to Azure using the appropriate deployment method, such as Azure DevOps, GitHub Actions, or manual deployment through the Azure Portal.
2. Monitor your application’s performance and make any necessary adjustments to ensure it runs smoothly in the cloud.

Viewing Available VDI or Creating a New One via the Devportal

You can see in the Devportal all available VDI or create a new one via this link: Devportal.

Using the Windows App Application to Connect to the DevBox

You should use the Windows App application to connect to the DevBox. The installation is available at Windows App Installation.

Conclusion

Using DevBox with Microsoft Azure provides a powerful and efficient development environment that leverages the capabilities of the cloud. By following these step-by-step instructions, you can set up, develop, test, and deploy your applications seamlessly, taking advantage of Azure’s robust infrastructure and services.

For more information and resources, visit the Azure DevBox Documentation.

Read more

How to delete a project Wiki in Azure DevOps?

In order to run this blogpost you should have Azure CLI and the Azure DevOps extension installed on your Powershell.

In order to be able to delete a wiki project, you have to delete its (hidden) repo Git.

Read more