Azure DevOps MCP vs Azure MCP Server: They Are Not the Same Thing (And You Might Not Need Both)

I was setting up MCP tools for my Claude Code workflow and noticed I had two Azure-related servers configured: azure-devops-mcp and azure-mcp-server. My first thought was “these probably overlap, I should remove one.” My second thought was “wait, which one does what?” My third thought was silence, because I genuinely did not know.

If you are reading this, you probably hit the same moment. Let me save you the 20 minutes.

They Talk to Completely Different Things

Here is the thing that was not obvious to me: “Azure DevOps” and “Azure” are not the same product. They share a brand name the way “Amazon” the bookstore and “Amazon Web Services” share a brand name. Related company, completely different thing.

azure-devops-mcp talks to Azure DevOps (dev.azure.com) – the software development lifecycle platform. Repos, pull requests, pipelines, boards, wikis, test plans, advanced security alerts. It is a tool for building software.

azure-mcp-server talks to Azure Cloud (portal.azure.com) – cloud infrastructure. Virtual machines, AKS clusters, Cosmos DB, Key Vault, Storage accounts, Monitor logs. It is a tool for running software.

These are not overlapping. They are not even adjacent. One is “how you build it” and the other is “what it runs on.”

The analogy that made it click for me:

If you had both a GitHub MCP and an AWS MCP installed, you would not think they overlap. One manages your repos and PRs, the other manages your infrastructure. Same thing here, just with Microsoft branding making it confusing.

So Why Was I Confused?

Because Microsoft named two completely different products “Azure [Something]” and then the MCP ecosystem named the servers in a way that sounds like one is a subset of the other. azure-mcp-server sounds like the general-purpose one, and azure-devops-mcp sounds like a specialized extension of it. They are not. They share zero API surface.

Also, Azure DevOps does have some cloud-adjacent features – Azure Artifacts hosts package feeds, Azure Pipelines runs builds on cloud infrastructure. But the MCP server is not talking to the cloud layer underneath. It is talking to the DevOps platform layer on top.

The Harder Question: Do I Actually Need the DevOps One?

This is where it gets interesting. My team – an AI org within Microsoft – uses:

• GitHub Enterprise for source code, pull requests, and Actions
• Linear for sprint tracking and day-to-day engineering work
• Azure Cloud for infrastructure (AKS, Cosmos, the usual)

So where does Azure DevOps fit? If we are already on GitHub for code and Linear for task tracking, azure-devops-mcp sounds like dead weight. We are not using ADO repos. We are not using ADO pipelines. Why would I need an MCP server for a platform we do not use?

The answer, like most things in large organizations, is “it depends on what layer you operate at.”

The Three-Layer Stack

What I have come to understand is that many Microsoft AI orgs run a three-layer stack, and which tools you care about depends on which layer you spend your time in.

Layer 1: Developer Day-to-Day

Tools: GitHub Enterprise + Linear

This is where individual contributors live. You write code, open PRs, review code, merge code, track your sprint tasks. GitHub handles the code workflow. Linear handles the “what am I working on today” workflow. If you are an IC engineer, this is probably your entire world.

Layer 2: Management and Program Tracking

Tools: Azure DevOps (Boards, specifically)

This is where PMs and engineering managers live. Azure DevOps Boards handles the stuff that GitHub Issues and Linear are not great at: hierarchical work items (Epic -> Feature -> Story -> Task), org-wide capacity planning, cross-team dependency tracking, WIQL queries for custom reporting, and the kind of heavyweight dashboards that program managers need to report up the chain.

GitHub Projects is getting better, but it is not enterprise program management tooling. And Linear is explicitly designed for engineering teams, not for the PM layer that needs to aggregate across 15 teams and produce executive-level status reports.

Layer 3: Infrastructure

Tools: Azure Cloud (portal.azure.com)

This is the cloud. VMs, clusters, databases, networking, monitoring. The azure-mcp-server lives here.

The Honest Reason ADO Still Exists

I could give you the architectural justification for why Azure DevOps Boards is the right tool for program management, and that justification is real. But let me also be honest about the other reason: organizational inertia.

Azure DevOps has been the Microsoft-internal project tracking tool for years. There are thousands of work items in there. Dashboards that people rely on. Reporting queries that feed into quarterly reviews. Sprint retrospective data going back years. Cross-org dependency links between teams that have never heard of each other.

Migrating all of that to GitHub or Linear is not a weekend project. It is a multi-quarter initiative that nobody wants to own, because the current system works well enough and the migration risk is real. What if you lose historical context? What if the new tool does not support the exact reporting query that a VP looks at every Monday?

So you end up with the pragmatic three-layer stack: engineers use the tools that make them productive (GitHub + Linear), management uses the tool that has all the historical data and reporting infrastructure (ADO Boards), and everyone pretends this is an intentional architecture decision rather than the natural outcome of a large organization evolving its tooling over time.

There is also a genuinely practical reason ADO persists: Azure Artifacts. If you need private PyPI, npm, or NuGet feeds, Azure Artifacts is the internal solution that integrates with Azure AD authentication and existing Microsoft infrastructure. GitHub Packages exists, but migrating package feeds – especially ones with internal consumers across the company – is the kind of thing that breaks builds for a week if you get it wrong. So Azure Artifacts stays, and with it, a reason for Azure DevOps to remain in the picture.

The Practical Takeaway

If you are looking at your MCP tool list and wondering what to keep:

You probably need azure-mcp-server if you touch Azure cloud infrastructure at all. Querying AKS clusters, checking Key Vault secrets, looking at Monitor logs – this is useful day-to-day stuff.

You probably need azure-devops-mcp if you:

• Touch work items in Azure DevOps Boards (epics, features, stories)
• Manage or query sprint planning data that lives in ADO
• Work with Azure Artifacts feeds (package publishing, feed management)
• Need to query ADO pipelines (even if you primarily use GitHub Actions)
• Interact with ADO wikis or test plans

You probably do NOT need azure-devops-mcp if you:

• Only write code and review PRs (that is GitHub)
• Only track your own tasks (that is Linear)
• Never open dev.azure.com in your browser
• Do not know what WIQL stands for (and have never needed to)

For me, as an IC engineer who spends 95% of the day in GitHub and Linear? The Azure DevOps MCP is not in my daily toolkit. But I know exactly where to find it if a PM asks me to update a work item or I need to debug an Artifacts feed issue.

The Meta-Lesson

The real lesson here is not about Azure. It is about how large organizations accumulate tools.

Nobody sits down and designs a system where you use three different platforms for software development. What happens is: a team adopts Tool A. It works. Then a different need arises and Tool B is better for that need. Then Tool A gets a new feature that overlaps with Tool B, but nobody migrates because both work fine. Then Tool C shows up and is genuinely better for the IC experience, so engineers migrate their daily work there, but the management layer stays on Tool A because the reporting is too entrenched to move.

Five years later, a new hire sets up their development environment and wonders why there are two Azure MCP servers, three project tracking tools, and a wiki that nobody has updated since 2024.

The answer is always: each layer made a locally rational decision, and the global result is a mess that kind of works. Welcome to enterprise software.