Here are two extremely simple C# snippets from one of my slides. If you think you can make software without needing to understand the produced code, please try to focus on these few lines only, at least. Both are generated by AI - VibeCoding. Together, they are about nine lines of code in two functions. Both compile, both look clean, and both are typical AI output.

Here is the question. How many bugs do you see?

Sample A – "Returns the average grade"

public static double AverageGrade(List<Student> students)
    => students.Select(s => s.Grade).Average();

Sample B – "Returns the top N scores"

public static int[] TopScores(int[] scores, int n)
{
    Array.Sort(scores);
    Array.Reverse(scores);
    return scores.Take(n).ToArray();
}

Take 60 seconds for each before you read on.

Six bugs in nine lines of code

A – AverageGrade (3 lines)

• If students is null, the application will crash.
• If the list is empty, the application crashes again. Average() throws on an empty sequence.
• If one student in the list is null, it crashes again.

B – TopScores (6 lines)

• It silently sorts and reverses the caller's original array, so other parts of the system now see changed data.
• If scores is null, it crashes.
• If n is negative, it returns an empty result without any error.

That's six bugs in nine lines, and nobody notices them in a 60-second look. Ok, try with 6 minutes :).

Now scale it up

Imagine 100,000 lines of vibe-coded software, or a million. Even if real code were a hundred times better than this example, you would still have hundreds of hidden bugs that nobody wrote consciously, nobody reviewed, and nobody understands.

Now let's picture the same thing with a car

Imagine a technology called VibeCarCreating. You describe your dream car, and an hour later it's standing in front of your house. It's shiny and quiet, the doors close perfectly, and the dashboard glows.

But nobody designed the brakes. Nobody calculated the steering. Nobody crash-tested it. It was generated, and it looks right. Your family is waiting to get in.

Would you drive it? Maybe slowly, around an empty parking lot. Would you drive it on the Autobahn at 200 km/h with your children in the back seat?

And now make it fly

Your Prompt: "Take this car and make it fly." Wow. Next Monday you go to your colleagues and will probably say: "See what I did with Cloude at the weekend."

Imagine it's a flying car. A car that fails stops at the side of the road. A plane that fails doesn't get a second chance.

We would never accept this for a car, yet we're starting to accept it for software that runs hospitals, banks, factories and energy grids.

My question: Are these two car models an 80:20 solution, which can be completed by some freelancer or a student from your neighbourhood?

Where would you drive this code?

I'm not against vibe coding. Many of us did that in the past, just manually. The result was inventing the Application Lifecycle Framework to stop engineers from being in the vibe flow. The difference now is democratisation and scale. You do not have to be a professional to jump into the Vibe flow. I also use a lot of AI to generate code every day (and night). But generated code is a prototype, not a product, until someone who understands it has tested it, reviewed it and taken responsibility for it. Usually, more than a single persona.

Here is my advice. Before you ship generated code, ask yourself the honest questions:

• Where will it run? A prototype, or the core of a business?
• How fast? A handful of users, or millions of transactions?
• Can it fly? If it fails, does it stop safely or crash hard?
• How secure is it?

Where would you drive or fly such code, and how fast?

VibeCoding #AI #SoftwareEngineering #CodeQuality #GenAI #dotnet #AgenticAI

Originally published on LinkedIn.

What a day in Cologne! The Microsoft Frontier Tour brought together developers, architects and decision-makers who want to move AI out of the pilot phase and into real business processes. The energy in the room was great.

One thing was clear all day: the conversation has moved on. Nobody asks anymore whether agents work. Teams now ask how to build agents that are reliable, secure, maintainable and good at specific tasks.

My session: Building Skilled Agents with Microsoft Agent Framework in C#/.NET

• What "skills" are, and why packaging know-how into reusable skills makes an agent better than a bigger prompt does
• How to combine skills and tools
• Lessons from projects we've built at daenet for German Mittelstand customers: what works in production and what doesn't

Thank you to Microsoft for the great organization, and thanks to everyone who joined the session and stopped by the labs. If you'd like to continue the conversation about your agent scenarios, send me a message.

MicrosoftAI #AgentFramework #dotnet #CSharp #AgenticAI #MCP #FrontierTour #daenet

Originally published on LinkedIn.

Every developer in Germany thinks in German and codes in English. We say "solange der Kunde aktiv ist…" in the meeting, then type while (customer.IsActive) in the IDE. We've done it so long we don't even notice the translation anymore.

So in my Software Engineering course at Frankfurt University of Applied Sciences, I gave my students a slightly crazy challenge: what would it take to write code in German and have it run natively on .NET? Not transpiled to C#, and not interpreted. Real Intermediate Language, running on the same runtime as every enterprise app we ship.

The answer: about 400 lines of C#, a lot of whiteboard discussions, and a room full of students who suddenly realised that compilers aren't magic and the AI is a friend.

Meet Deutsch.NET#

zahl fakultät = 1;
zahl i = 1;

solange i <= 10 {
    fakultät = fakultät * i;
    i = i + 1;
}

wenn fakultät > 1000000 {
    schreibe "Das ist groß!";
}

That's a real program. zahl, solange, wenn, sonst and schreibe are keywords, umlauts are valid in variable names (yes, größe works), and the output is a genuine .NET assembly. You can run it with dotnet programm.dll or open it in ILSpy and read the IL.

How it works (it's less magic than you think - alle kochen mit Wasser)

Every compiler, from Roslyn to GCC, follows the same basic pipeline. Together we implemented each stage in its simplest honest form.

1. Lexer. It turns raw text into tokens. It recognizes solange as a keyword, fakultät as a name and <= as an operator.

2. Parser. A recursive-descent parser turns tokens into an abstract syntax tree. Operator precedence (oder < und < comparison < + < *) is simply the order in which the functions call each other.

3. Code generation. The tree is walked and each node is emitted as IL through System.Reflection.Emit. A solange loop becomes a label, the condition, a brfalse to the end, the body, and a br back to the start. Even <= has no direct IL instruction; it becomes cgt followed by "compare with zero". That's the kind of detail you only learn by building it yourself.

4. Assembly. The new PersistedAssemblyBuilder in .NET 9 writes the result to disk as a real executable. For years this was only possible on .NET Framework; now it's back, and it's a game changer for anyone building languages or DSLs on .NET.

Why build a compiler in a Software Engineering course?

Because it's the perfect software engineering project in miniature.

Architecture becomes tangible. Lexer, parser and code generator are clean, separate layers with clear contracts between them. Students experience firsthand why separation of concerns isn't just a slide in a lecture.

Testing gets real. Every keyword, every operator and every edge case (what happens with zahl x = x;?) needs a test. Good error messages in German ("Zeile 7: ';' erwartet") turned out to be just as much work as the happy path, exactly like in real products.

The fundamentals stick. When you've emitted ldloc and brfalse yourself, you understand async state machines, LINQ and performance profiles on a completely different level. Abstractions stop being mysterious once you've built one.

And it's fun. Seeing your own German program print "Das ist groß!" from an assembly you generated byte by byte is a moment students don't forget.

Why this matters beyond the classroom

Domain-specific languages are underrated. Imagine business rules, pricing logic or configuration written in the language the domain experts speak. A DSL compiled to IL runs at full .NET speed and remains strictly deterministic.

And this is where it gets interesting for AI. Everyone is talking about natural language as the new programming interface. LLMs are brilliant at turning intent into code, but they're probabilistic. Compilers are deterministic. The real power lies in combining both: an agent translates human intent into a precise, constrained DSL, and a compiler guarantees what actually runs. Natural language for expression, formal languages for trust.

The next generation of engineers needs to understand both worlds. That's exactly what we try to teach.

What's next

Deutsch# is intentionally tiny: integers, strings, branches and loops. The roadmap is already on the whiteboard. That means nested scopes, a real type checker, functions (funktion … gib zurück …), and calling into the .NET base class library. Plenty of material for the next student projects.

We also used Claude and ChatGPT as an AI pair programmer along the way, which is a story in itself. It sped things up a lot, but the real understanding came from the students reading and questioning every line it suggested.

Would you write production code in your native language, or is English simply the lingua franca of code forever? And should we put Deutsch.NET# on GitHub? Let us know in the comments. ?

Huge thanks to my students for their curiosity and energy. You made this one a blast. ?

dotnet #csharp #compilers #softwareengineering #teaching #FrankfurtUAS #AI #DSL #MicrosoftMVP

Originally published on LinkedIn.

Everything is changing, and Scrum is changing too. I don't want to give the impression that this post is a prediction. I don't know what the future will look like, and nobody does, including the CEOs of the hyperscalers.

But this is how my teams have been working over the last few years. Our workflow hasn't changed, but our roles are changing.

Spec → Plan → Task → Test → Review → Commit

More precisely, we are learning a new kind of rhetoric. Why? Between every step there's an agent doing some of the work.

What surprised me is that the agent didn't make the process less important. I think the engineering approach stays fully in place, even when we use AI. When you give an agent a vague story, you get a vague result. When you give it a small task with clear acceptance criteria, it does a very good job. So we are discovering a new rhetoric for working with AI.

A good task for an AI agent is:

• ✔ small (minutes to hours, not days)
• ✔ testable (Given / When / Then)
• ✔ traceable (task ID in the commit)
• ✔ and last but not least, reviewed by a person

This is the new reality with LLMs, at least for now, at least at daenet/ACP.

The value isn't in the model. It's in us: in how well we specify, split and verify the work. The engineering discipline we have always taught is suddenly worth more, not less.

I'd be happy to hear your suggestions and thoughts.

AI #AgenticAI #Scrum #SoftwareEngineering #daenet

Originally published on LinkedIn.

You've built a great .NET application. It works perfectly on your machine. You send it to a customer, and the first reply you get is: "It doesn't start. It says something about installing .NET."

The way you publish your app decides whether your customer double-clicks and gets going, or opens a ticket with their IT department and waits two weeks. Here's a practical look at the options.

Framework-dependent: small, but with strings attached

A framework-dependent app expects the .NET runtime to already be on the machine. The standard runtime installer puts it in C:\Program Files\dotnet, a machine-wide location, so installing it requires admin rights.

On a developer box that's no problem. On a locked-down corporate laptop, it often is. The user can't install the runtime themselves, and their IT department may not have rolled out the version you need (say, .NET 10). Your app is ready; the machine isn't.

Self-contained: bring your own runtime

Self-contained publishing ships the .NET runtime inside your app's folder. Nothing is installed system-wide. The user can unzip or copy the app into any folder they have write access to, such as the Desktop, Downloads or %LOCALAPPDATA%, and simply run it.

No installer. No elevation prompt. No "please install .NET 10 first" step.

There's a quiet but valuable side benefit: your app always runs on exactly the runtime version you tested with, regardless of what else is (or isn't) installed on the machine. Fewer "works on my machine" surprises.

Single file: one .exe, done

Single-file publishing goes one step further. Instead of a folder full of DLLs, the customer gets one .exe to double-click. For distribution to non-technical users, that's about as simple as it gets.

dotnet publish -c Release -r win-x64 --self-contained true -p:PublishSingleFile=true

Caveats you'll be asked about

Missing admin rights don't strictly block framework-dependent apps. A determined user can install the runtime per-user with the dotnet-install script and point DOTNET_ROOT at it. It works, but it's not something you'd reasonably expect a customer to do.

Self-contained doesn't defeat every lock-down. If IT uses AppLocker or similar policies to block executables in user folders, your app won't run either way. Publishing mode can't solve a policy decision; that conversation has to happen with IT.

Size is the trade-off. Bundling the runtime makes the app noticeably bigger, roughly 60–80 MB. Trimming (-p:PublishTrimmed=true) can bring that down considerably, but test carefully: trimming can break code that relies on reflection, and WinForms and WPF apps don't officially support it.

The bottom line

If you control the target machines, framework-dependent keeps things lean. If you're shipping to customers whose environments you don't control, self-contained (ideally as a single file) removes the most common reason your app fails to start, and that first impression matters.

How do you publish your .NET apps for customers? I'd be curious to hear what has worked in your environments.

dotnet #csharp #softwaredevelopment #deployment #microsoft

Originally published on LinkedIn.

I recently did an interview with the German Handelsblatt on where AI actually stands in the German Mittelstand, and I didn't hold back on the uncomfortable parts.

The honest answer: most companies are still in "trying things out" mode. Everyone has tested a chatbot or let a few people play with ChatGPT. But there's a massive gap between an impressive demo and something that runs in production and actually moves the numbers.

Why? Driven by the ME-TOO algorithm: "We also do AI." No clear use cases, messy or unusable data, no safe way to wire it into existing systems, and often simply not enough internal competence to make good calls.

My #1 advice to decision-makers

Build real technological understanding before you build anything else. Every new technology demands a certain level of understanding; without it, you make bad decisions. Cookie banners are the textbook example: regulation written without understanding the underlying tech, solving nothing while making life harder for millions of people. If we get AI wrong the same way, we'll get the same kind of well-meaning mess.

Agent vs. chatbot

I also talked about what an "AI agent" really is, compared to just another chatbot. A chatbot is request-response, done. An agent works in a continuous loop: it reasons, breaks a task into subtasks and takes actions through interfaces that we as developers build. And that's the key point I keep repeating: the model itself doesn't act or decide. The responsibility for what actually happens sits with the software and the developers who build those interfaces.

That distinction gets lost far too often in political and regulatory discussions.

One more thing worth saying clearly

Language models don't "understand" in the human sense. They calculate probable next words. That means they can sound convincing and still be wrong. For real logical reasoning, guaranteed-correct numbers or reliable facts, a language model alone is not enough.

Read the full article (in German): KI im Mittelstand – Handelsblatt

Digitalisierung #AI #KI #ArtificialIntelligence #SoftwareEngineering #Innovation #Mittelstand #daenet

Originally published on LinkedIn.

What a session! The two-hour deep-dive workshop "Mastering Agents, MCP and other hypes" on July 8 at WeAreDevelopers World Congress in Berlin was completely full, with people staying for the entire discussion and a steady stream of great questions right until the end of the next break.

We went through building AI agents based on Microsoft Agent Framework, with extended capabilities using Function Calling, MCP and RAG. From the core concepts behind agents and plugins to building custom agents, and working across Microsoft Foundry and different AI models, we covered a lot of ground, all demo-driven and built for developers, architects and technical decision-makers.

Huge thanks to everyone who packed the room, asked amazing questions and stayed engaged for the full two hours. Conversations like these are exactly why events like WeAreDevelopers matter.

WeAreDevelopers #AI #AIAgents #MCP #SemanticKernel #MicrosoftFoundry #LLM #MicrosoftAgentFramework #AzureAI #DeveloperCommunity #Berlin2026

Originally published on LinkedIn.

This is not a distant future. It is happening right now. And it is just one example of how AI is fundamentally rewriting the rules of software development.

I recently had the opportunity to talk with the DWX team about where I think the AI journey could be heading. Here is a summary of a few things I said, some of which may be a little surprising.

IT Pro in natural language

Instead of battling with PowerShell, Bicep or Terraform, developers today can simply describe what they want: "Please provision a VM in Germany West with 10 GB RAM." Just type it, or say it into the microphone. The AI translates intent into executable code, using a technique we now call CLAW (Command Line Automated Workflow). The next LLM wave is arriving step by step through voice input, and hyperscalers like Microsoft are pushing hard in this direction.

How cool is vibe coding really?

I'm a bit skeptical. Yes, you make fast progress at the beginning. Almost too fast. Then comes the awakening: code duplicated three times, endless refactoring, and a system that nobody really understands anymore. There is no developer, no author, you can call. Professional software shipping is and remains a software engineering skill. One example: if you don't know what CSS attributes or HTML structure mean, you won't be able to ship production-ready code and maintain it over time, even with the best AI tool. Vibe-coded tools like these will only find their place internally, where you are responsible for yourself.

Will developers have to fear for their jobs?

No. Code monkeys will. The language changes, the profession doesn't. We have gone through Assembler, BASIC, C++ and C#, and now perhaps spoken German comes next. That's evolution, not extinction. Old jobs disappear and new ones emerge. It has always been that way.

On data sovereignty

I won't sugarcoat this. The idea of running AI and cloud entirely in your own data center in Germany? That train has almost left the station. Missing energy, missing infrastructure, missing core technology. And open source isn't a complete answer to dependencies either; the recent Notepad++ security issue shows that clearly. We need to talk about this openly.

My conclusion

Everyone should try AI. Not because the apocalypse will come if you don't, but because competition is becoming more efficient, and you will feel it.

I will go deeper into all of this as Track Chair for Cloud Strategies and AI Strategies at DWX 2026 in Mannheim (June 29 – July 2).

Watch the full interview (in German): youtu.be/y9JzHfeCA0c

AI #CloudComputing #SoftwareDevelopment #DWX2026 #ArtificialIntelligence #DevOps #Microsoft #Azure

Originally published on LinkedIn.

Running out of tokens is not a nice feeling.

This seems to be a new pain of the agentic population.

When it happens to me, I simply follow my own rule: when I run out of tokens, I go out. :)

AI #AgenticAI #LLM #GitHubCopilot

Originally published on LinkedIn.

Introduction

Integrating a custom Model Context Protocol (MCP) server with Copilot Studio agents opens up new possibilities for organizations leveraging Microsoft 365 Copilot and Teams. This article guides you through the process of creating, deploying, and extending an AI agent with specialized skills, using MCP and Copilot Studio as the foundation. Whether you are a low-code enthusiast or a professional developer, you’ll find practical steps and insights to help you build robust, action-oriented agents tailored to your enterprise needs.

Understanding Agent Types in Copilot Studio

The diagram below illustrates the main types of agents you can build in Copilot Studio. Each type is tailored for specific tasks, ranging from answering questions and providing recommendations to executing automated actions and guiding users through processes. This simplified visual overview helps you quickly identify which agent type best fits your business.

In this post, we focus on the action-oriented agent type, which leverages an existing Azure DevOps MCP server implementation to extend capabilities and automate workflows. You can find the source code and deployment instructions for the MCP server in the following GitHub repository:
https://github.com/heluxenhofer/mcp-server-azure-devops

Hosting Your MCP Server in Azure

To make your MCP server accessible to Copilot Studio agents, you first need to prepare your server code for deployment in Azure. Using the Azure Developer CLI, you can deploy your MCP server to an Azure Container App Environment. The process is straightforward: clone the example repository from GitHub, follow the instructions in the README, and configure your deployment. The resulting architecture includes managed identity, a container registry, Azure Key Vault, and Application Insights for monitoring. This setup ensures your MCP server is secure, scalable, and ready for enterprise use.

Agent with MCP in Copilot Studio

Once your MCP server is running in Azure, the next step is to integrate it with Copilot Studio. Begin by manually configuring your agent in Copilot Studio, enabling generative AI orchestration mode to allow dynamic tool selection. For best results, disable general knowledge and web search features so your agent remains focused on its core tasks.
When defining your agent’s instructions, clarity is key. For example, you might specify that your agent is an Azure DevOps assistant, designed to help developers perform specific tasks using Azure DevOps tools. The agent should be able to retrieve available MCP tools, summarize them for users, and guide them through actions such as creating new branches. It’s important to ensure the agent politely declines unrelated requests and maintains a friendly, engaging tone throughout interactions.
Example instructions can be found in GitHub Repo here.
Tip: Take care to name referenced tools in your instructions like in configuration.
If you aren`t familiar with creating agents in Copilot Studio, just follow instructions on Microsoft documentation Quickstart: Create and deploy an agent - Microsoft Copilot Studio | Microsoft Learn.

Monitoring and Insights

Monitoring is essential for maintaining high-quality, production-ready agents. Azure Application Insights provides comprehensive visibility into both your MCP server and Copilot Studio agents. By integrating Application Insights, you can track performance metrics, user interactions, and potential issues, enabling continuous improvement and reliable operation. Application Insights can be set up under Settings-Advanced

Integrating the MCP Tool in Copilot Studio

Initiating the MCP Tool Integration

Begin by opening your agent configuration in Copilot Studio and selecting the option to add a new tool. Choose “Model Context Protocol (MCP)” as the integration type. The onboarding wizard will guide you through the required steps. For a comprehensive walkthrough, refer to the official documentation:
https://learn.microsoft.com/en-us/microsoft-copilot-studio/mcp-add-existing-server-to-agent

Configuring the MCP Server Endpoint

During setup, you will be prompted to provide the endpoint of your MCP server. For this post, the integration leverages an existing Azure DevOps MCP server implementation, available at:
https://github.com/heluxenhofer/mcp-server-azure-devops
Ensure your MCP server is deployed and accessible from the Copilot Studio environment, see section Hosting.

Setting Up Secure Authentication

Security is essential when integrating enterprise tools. Select Microsoft Entra ID (OAuth 2.0) as the authentication method. You will need to enter the Client ID, Client Secret, Authorization URL, Token / Refresh URL and the required scopes from your Azure Entra ID App Registration. You can use existing App Registration which was created for MCP-Server, described in GitHub Repository.
Tip: You can find these endpoints in the Azure portal under Azure Active Directory → App registrations → [Your App] → Overview → Endpoints.

• Set the “Authorization URL” to the value labeled OAuth 2.0 authorization endpoint (v2).
• Set the “Token URL” and “Refresh URL” to the value labeled OAuth 2.0 token endpoint (v2).
• Scopes are defined under Expose an API in your App Registration.

After completing these fields, Copilot Studio will generate a Redirect URL. Add this URL to your registered app’s Redirect URIs in Azure Entra ID to enable the authorization flow.

Finalizing and Validating the Integration

Once configuration is complete, Copilot Studio will prompt you to authenticate using your Entra ID credentials. Open the Connections Manager if necessary, verify your credentials, and reauthenticate as needed. After successful authentication, your agent will be able to invoke MCP tools for Azure DevOps automation.
It is recommended to validate the integration using Copilot Studio’s Test pane. Enter prompts that trigger MCP tool actions and confirm that your agent can successfully connect and perform the intended operations.

Publishing and Sharing Your Agent

With your agent configured and authenticated, you’re ready to publish it in Copilot Studio. Add channels such as Microsoft Teams to make your agent accessible across your organization. Before rolling out the agent company-wide, test it in your chosen channels to ensure everything works as expected. Copilot Studio’s publishing workflow makes it easy to manage availability and distribution, supporting both targeted testing and broad deployment.

Read more about publishing and deploying your agent on Microsoft documentation.
Key concepts - Publish and deploy your agent - Microsoft Copilot Studio | Microsoft Learn

After publishing the agent and adding channels, you can try out your agent in Microsoft Teams by clicking on “Availability options” and copy / paste the link into your browser and try your agent inside Microsoft Teams.

Note: At the time of writing this post, there might be a bug when clicking on “See agent in Teams” and agent wasn`t working in Teams chat like expected. Click on “Availability options” and copy link to test agent instead.

Summary

Integrating a custom MCP server with Copilot Studio enables organizations to build powerful, action-oriented AI agents that streamline workflows and enhance productivity. By leveraging Azure Container Apps for hosting and Copilot Studio’s orchestration and authentication features, teams can deploy scalable, secure, and flexible solutions tailored to their business needs.

Best Practices & Recommendations

• Use separate environments for development, testing, and production in Copilot Studio to ensure stability and manage changes effectively.
• Design agents with clear objectives and leverage built-in topics for extensibility.
• Implement additional security measures for your MCP server in production, such as restricting access and monitoring usage.
• Set up CI/CD pipelines for automated deployments and updates.
• Regularly monitor agent performance and collect user feedback to continuously refine capabilities and address potential issues.

References

GitHub Repository custom MCP Server: https://github.com/heluxenhofer/mcp-server-azure-devops
Copilot Studio Documentation: https://learn.microsoft.com/en-us/microsoft-copilot-studio/
Model Context Protocol Integration: https://learn.microsoft.com/en-us/microsoft-copilot-studio/agent-extend-action-mcp
Azure Container App Deployment: https://learn.microsoft.com/en-us/azure/developer/ai/build-mcp-server-ts
Authentication with Entra ID: https://learn.microsoft.com/en-us/microsoft-copilot-studio/configuration-authentication-azure-ad

This article presents a hands-on showcase of the Model Context Protocol (MCP) implemented with .NET and C#. See how MCP can be used to expose, discover, and orchestrate server-side tools in a standardized way—making integration smarter, more flexible, and ready for modern automation scenarios.

Introduction

Ever wondered how to make your tools and services more discoverable, interoperable, and easy to automate? MCP (Model Context Protocol) is designed for exactly that. In this showcase project, we use .NET and C# to demonstrate how MCP can turn ordinary APIs into intelligent, composable tools—ready for integration with clients, AI assistants, and automation platforms.

What is MCP?

MCP (Model Context Protocol) is an open protocol for exposing server-side operations as standardized, discoverable tools. According to the official MCP specification, MCP enables clients—such as developer tools, automation platforms, or AI assistants—to dynamically discover available operations, understand their input/output schemas, and invoke them in a consistent way.
The diagrams below illustrate the difference between integrating APIs with and without MCP. This illustration alone demonstrates the advantages of using MCP.
Integration of existing APIs without MCP
Integration of existing APIs with MCP

Benefits of Using MCP

• Discoverability: Clients can query the server to list all available tools and their capabilities, reducing the need for hardcoded API knowledge.
• Interoperability: MCP provides a common language for tools and clients, making integration across platforms and technologies straightforward.
• Extensibility: New tools and operations can be added to the server without breaking existing clients.
• Schema Transparency: Each tool exposes its input and output schema, enabling robust validation and easier client development.
• Security: MCP supports modern authentication and authorization mechanisms, such as OAuth 2.0 and Microsoft Entra ID.
• Automation & AI Readiness: MCP is designed for orchestration by automation scripts and AI agents, supporting conversational and intelligent workflows.

Elicitation with MCP: Interactive User Workflows

A unique feature of MCP is its support for elicitation—interactive user input collection. In this project, elicitation is used to prompt users for required information (e.g., selecting a parent branch when creating a new branch). The MCP server sends a schema describing the expected input, and the client (or LLM) collects the user’s response, ensuring a guided and error-resistant workflow.
Example json request/response with using an enum schema:

{
    "type": "object",
    "properties": {
        "ParentBranch": {
            "type": "string",
            "enum": [
                "main"
            ]
        }
    },
    "required": [
        "ParentBranch"
    ]
}

Request schema

{
    "action": "accept",
    "content": {
        "ParentBranch": "main"
    },
    "_meta": null
}

Response schema

This approach makes user interaction smarter and more flexible, allowing for dynamic, context-aware prompts and responses.

Architecture Overview

This showcase project on GitHub is built with .NET 9 and C#, using MCP to abstract a set of Azure DevOps operations as MCP tools. The diagram below illustrates the key components and their interactions:

• MCP Server: Hosts the MCP tools and exposes a standardized discovery endpoint. Implements authentication via Microsoft Entra ID.
• MCP Tools: Each tool represents a server-side operation (e.g., create branch, list repositories). Tools expose input/output schemas for validation and interoperability. Requests operations to Azure DevOps REST API.
• Client/LLM: Discovers available tools dynamically and invokes them using the MCP protocol. Supports elicitation for interactive workflows.
• Authentication Layer: Uses OAuth 2.0 and Entra ID for secure access control. Uses on-behalf-flow for accessing Azure DevOps REST API.

Components of current architecture

Technical Implementation

This project is a practical demonstration of MCP’s power when combined with .NET and C#:

• Modern .NET: Built with .NET 9 for reliability and performance.
• C# Best Practices: Clean, maintainable code that’s easy to extend.
• MCP Tooling: Azure DevOps operations are exposed as MCP tools, with clear schemas and discoverable endpoints.
• Secure by Design: Authentication via Entra ID and secure configuration management. Using on-behalf authentication flow for accessing Azure DevOps REST API in a secure way.

More technical details, instructions and examples can be found in readme file of GitHub project

Why Try MCP with .NET and C#?

If you’re a developer, architect, or automation enthusiast, this showcase is for you. MCP makes it easy to build smarter, more flexible integrations—whether you’re connecting tools, enabling AI, or future-proofing your APIs. With .NET and C#, you get a robust, enterprise-ready foundation for your MCP server.

References

Project GitHub Repository
MCP C# SDK
MCP GitHub (Official)
MCP Specification