Building the Azure MCP Server: From Prototype to Platform

"Azure MCP Server"

I started hacking together a prototypeto help GitHub Copilot for Azure connect better to Azure services. What began as a quick project became the Azure MCP Server, and ultimately became the foundation for Microsoft’s Model Context Protocol (MCP) platform. I had no idea it’d evolve into something this big.

The Genesis: A Collaboration Born from Need

The GitHub Copilot for Azure team needed a better API - one that returned JSON so they could properly parse and work with Azure data. The existing tooling wasn’t cutting it for AI agents that needed structured, machine-readable responses. That was the problem.

In February 2025, this kicked off a collaboration between me and the GitHub Copilot for Azure team. We started prototyping together, building a CLI that not only worked for developers but also provided the structured data that AI agents needed. The early days were all about experimentation and iteration.

It was rough, scrappy code, but it worked. More importantly, it proved the concept had legs.

The MCP Explosion

Then MCP exploded onto the scene.

Suddenly, what we were building wasn’t just useful. It was perfectly positioned. We pivoted from a CLI to a full-fledged MCP server. This wasn’t just a rewrite - it was a complete rebuild of how the tool could serve developers.

Choosing .NET: The Right Tool for the Job

I probably would have chosen Go. We used it for the Azure Developer CLI, and it’s great for building cross-platform tools. But this project had a different set of constraints.

We went with .NET because the Azure SDKs covered all the services we needed. We were integrating with a lot of Azure services, and the SDK consistency and maturity were critical for making that work.

Plus, we wanted to ship a single binary with no platform or framework install required. No “install .NET first” instructions. Just download and run.

We initially delivered it via npx (ironic, I know-shipping .NET via npm), but now we support dnx, the new one-line dotnet installer from NuGet. One command, and you’re running.

Working with the .NET MCP SDK Team

I worked directly with Stephen Toub and the .NET team as one of the first customers of their C# MCP SDK. Stephen and I go way back - we worked together at MSDN in the early 2000s, probably 20+ years ago now. Being an early customer meant we weren’t just using the SDK - we were helping shape it.

We also dove deep into the System.CommandLine early beta with Jeff Handley, who runs the System.CommandLine dev team. Jeff’s a friend from the music world (I actually rented an upright bass from him for a while), so it was great collaborating with him on this. The library was still being refined, and our feedback helped make it better. There’s something special about being in the trenches with people you’ve known for years, solving real problems together.

The AOT Challenge: Making Everything Native

We wanted to ship a single binary - no runtime dependencies, just download and run. That meant going all-in on Native AOT compilation.

Here’s the thing about AOT: every dependency in your app has to be AOT-compatible. No reflection tricks, no dynamic code generation, no runtime surprises. This wasn’t just our code - it was every Azure SDK we used.

So as a bonus (or challenge, depending on how you look at it), we ended up making all the Azure SDKs we depended on AOT-compatible. We worked with the Azure SDK team to identify issues, fix patterns that broke under AOT constraints, and validate that everything compiled and ran correctly as native code.

The payoff? A single executable that starts instantly and uses a fraction of the memory. No .NET runtime to install. Just ship it and go.

From Prototype to Team

This pattern is one I’ve experienced before: I prototype, validate the idea, get support from the business, and then a team forms around it to ship it.

Once the foundation was solid and the vision was clear, the business brought in:

A dev lead to guide technical direction
A PM to drive product strategy
A dev team to build features
An ops team to ensure reliability

What started as my nights-and-weekends project became a proper product with proper resources.

Scaling to the Microsoft MCP Platform

A few months ago, we turned a corner. Internal teams were flooding us with requests to create their own MCP servers. But they didn’t want to build all the infrastructure - deployment pipelines, documentation sites, operational tooling - that comes with shipping production software.

That’s when the idea hit me: Why not make this a platform?

We evolved from github.com/azure/azure-mcp to github.com/microsoft/mcp - a centralized landing spot for teams across Microsoft to build and ship MCP servers. The Azure MCP Server was the flagship, but we quickly onboarded other teams:

Microsoft structure is already live with their MCP server
Several more teams are in the pipeline
The infrastructure, patterns, and operational patterns we built for Azure MCP became reusable for everyone

The investment we made in doing things right for Azure MCP is now paying dividends across the company.

The Human Side: Countless Hours, Singular Focus

I won’t sugarcoat it. The team and I worked countless hours to ship this. Late nights, weekends, constant iteration. But when you believe in what you’re building and you see developers benefiting from your work, those hours don’t feel like sacrifice. They feel like investment.

Every bug we squashed, every feature we shipped, every piece of feedback we incorporated - it all pointed toward one goal: helping developers work with Azure right from their coding agent.

What We Shipped

The Azure MCP Server today:

Production-ready - Battle-tested infrastructure and operations
Developer-friendly - Built by developers, for developers
Extensible - A platform, not just a product
Open - Open source and open to contributions
Broad Azure coverage - From resource deployment to service queries

More than the features, it’s a blueprint. Proof that you can take an idea, validate it quickly, and scale it into something that serves an entire platform.

Lessons from the process

1. Start Small, Think Big

The prototype was tiny. The vision was massive. Don’t let the gap between the two stop you from starting.

2. Be the First Customer

Working as an early customer of the .NET MCP SDK and System.CommandLine made our product better and improved those libraries for everyone. Win-win.

3. Build the Foundation Right

The foundation work we did early on - CI/CD, documentation, operational patterns - became the platform that enabled other teams to move fast.

4. Evolve with the platform

When MCP took off, we pivoted fast. Staying rigid on the original CLI vision would have been a mistake.

5. Team > Solo

I’m proud of the prototype I built, but the product we shipped required a team. Know when to hand off, when to scale, and when to let others improve your work.

Try It Out

If you’re building on Azure and using AI coding assistants, give the Azure MCP Server a try. Whether you’re deploying resources, querying services, or exploring what’s possible when your AI has Azure context, it’s built for you.

The GitHub Copilot for Azure extension is now fully integrated with the Azure MCP Server - no more CLI hacks, just clean integration that works.

If you’re at Microsoft and thinking about building an MCP server, come talk to us. The platform is ready, the patterns are proven, and we’d love to help you ship.

Resources:

Acknowledgments:

Huge thanks to the .NET MCP SDK team, the System.CommandLine team, and the countless beta testers who helped shape this project. Special shout-out to everyone on the Azure MCP team who poured their energy into making this real.

Want to contribute? The Azure MCP Server repo is open for collaboration.

Jon