DEV Community

Leo
Leo

Posted on • Originally published at cicd.deployment.to

Azure DevOps ships a hosted MCP endpoint you don't have to run

#azuredevops #mcp #aiagents #microsoft

There is a specific flavor of browser tab I keep open too long: the one where an AI assistant has half-written a plan for a change, and I have to leave it to go check what a work item in Azure DevOps actually says. The context switch is small. The tax adds up over a week. On August 5th Microsoft pushed the Azure DevOps MCP Server to general availability as a hosted, remote endpoint, and if your team already lives in Azure DevOps that little tab-switch tax is what changes.

What actually shipped

The remote server is hosted by Azure DevOps itself. There is no container to run, no local process to babysit, no laptop-only MCP adapter for the whole team to keep in sync. AI assistants talk to it over streamable HTTP at https://mcp.dev.azure.com/{organization}, and Microsoft says the endpoint gives assistants contextual access to work items, pull requests, repositories and pipelines so they can plan, build and ship against a real project rather than a guess.

Authentication rides on Microsoft Entra, and that is a real constraint: the organization has to be backed by an Entra tenant, and standalone Microsoft accounts are not supported.

Wiring it up

The client-side setup is one block in mcp.json:

{
  "servers": {
    "ado-remote-mcp": {
      "url": "https://mcp.dev.azure.com/{organization}",
      "type": "http"
    }
  },
  "inputs": []
}
Enter fullscreen mode Exit fullscreen mode

Swap the placeholder for your org slug and the assistant starts reaching into your Azure DevOps project directly. The clients Microsoft lists as working on day one are Visual Studio Code with GitHub Copilot, Microsoft Copilot Studio, Microsoft Foundry AI, Visual Studio, and the GitHub Copilot CLI and app.

The rough edge

This is where the release stops feeling like a free lunch. The transport needs dynamic OAuth client registration, and until that lands, Microsoft is up front that Claude Desktop, Claude Code, ChatGPT and Cursor are on the wrong side of the fence. If those are your daily drivers, the guidance is to keep running the local Azure DevOps MCP Server for now, and add the remote endpoint the day your assistant starts speaking that OAuth dialect.

Two footnotes matter for CI/CD teams. First, the blast radius of an assistant with pipeline access is not small. It can act on real work items and pull requests, not a sandbox, and you will want that in the same activity trail you already read for humans. Second, consolidating auth on Entra is convenient right up until the day your Entra hiccup becomes a CI hiccup too. The upside is that the team stops running an MCP adapter that would be a lovely target on its own; the downside is that a chunk of your ship-day agency now sits behind one identity provider.

What I'm watching next

Two things. First, when dynamic OAuth client registration flips on and the supported-client list widens past the Microsoft plus GitHub Copilot lane. That is the moment this stops feeling like a Copilot feature and starts feeling like an Azure DevOps feature. Second, the audit surface: an AI assistant that can move a work item to "done" or approve a pull request is a new kind of actor in your history, and I want to see it show up in the same trails a human user does. Ask an assistant to close out a batch of stale work items next week. If you cannot cleanly answer "who did that" from the audit log, you have the same question I have.

Top comments (0)