Microsoft shipped two related announcements in the same week. On March 17, the Azure DevOps Remote MCP Server entered public preview. Two days later, it became available inside Microsoft Foundry. Together, they give AI agents a hosted, authenticated connection to Azure DevOps — work items, pull requests, pipelines, repos, wikis, test plans — without requiring any local installation.
The practical result: An AI agent built in Foundry or running in VS Code can query your sprint status, summarize open pull requests, create work items, or inspect pipeline results by connecting to a single URL. No local server to install. No infrastructure to manage. Just add the endpoint to your MCP configuration and authenticate through Microsoft Entra.
What the Remote MCP Server Does
The Remote MCP Server is a hosted version of the local Azure DevOps MCP Server that Microsoft released in public preview last year. It provides the same capabilities — access to work items, pull requests, pipelines, repos, wikis, test plans, builds, and releases — but uses streamable HTTP transport instead of running on your machine.
Configuration is minimal. Add the server URL (https://mcp.dev.azure.com/{organization}) to your mcp.json file and you’re connected. Authentication flows through Microsoft Entra, which means it inherits your organization’s existing identity rules, conditional access policies, and permission boundaries. Your Azure DevOps organization must be backed by Entra — standalone MSA-backed organizations aren’t supported.
Two access control features stand out for enterprise teams. The X-MCP-Readonly header restricts the server to read-only operations, preventing any modifications to Azure DevOps resources. This is the same read-only-by-default pattern we’ve seen in Gemini CLI’s plan mode — let agents explore without risk. The X-MCP-Toolsets header lets you specify which tool categories are available (repos, wiki, work item tracking, etc.), so you can scope agent access to exactly what’s needed.
Microsoft has indicated plans to eventually archive the local MCP Server repository and focus investment on the remote version. The timeline will align with the Remote MCP Server reaching general availability. Teams using the local server should start evaluating the migration.
The Foundry Integration
Microsoft Foundry — the company’s unified platform for building and managing AI-powered applications and agents at scale — now includes the Azure DevOps MCP Server in its tool catalog. Adding it to an agent is straightforward: go to Add Tools, search for “Azure DevOps” in the catalog, and connect.
Once connected, you can limit which tools your agent can access, controlling exactly what operations it can perform against your Azure DevOps organization. This granularity matters for production deployments where an agent that can read work items shouldn’t necessarily be able to modify pipelines.
The Foundry integration is significant because it connects Azure DevOps data to Foundry’s full agent development lifecycle — model access, orchestration, evaluation, and deployment. An agent built in Foundry can now query Azure DevOps for project context, act on that context using whatever models and tools are available, and deploy to production with Foundry’s governance and security controls.
For teams building internal workflow agents — the kind we covered with LangChain’s Open SWE framework — this provides a managed alternative to building custom Azure DevOps integrations. The MCP server handles authentication, access control, and API complexity. The agent builder focuses on the workflow logic.
“Microsoft is turning Azure DevOps into agent-accessible infrastructure, connecting sprint data, pipelines, and repos directly to Foundry’s agent development lifecycle through a hosted endpoint. Microsoft is betting that organizations will extend the same Entra policies governing human access to govern agent access, collapsing a separate integration problem into existing identity architecture,” says Mitch Ashley, VP and practice lead for software lifecycle engineering at The Futurum Group.
“Enterprise security teams evaluate agent access differently than developer tools. Scoped toolsets and read-only controls address that directly, which means the governance conversation shifts from ‘should agents touch this data’ to ‘under what conditions.’ That changes the procurement calculus for teams building internal workflow agents.”
Current Limitations
The preview has some constraints worth noting. Only Visual Studio and Visual Studio Code are supported as clients, with no additional onboarding required. Claude Desktop, Claude Code, GitHub Copilot CLI, ChatGPT, and Codex all require dynamic OAuth client registration in Entra before they can connect — Microsoft says they’re working with the Entra team to enable this. Support for Microsoft 365 Copilot and Copilot Studio is not yet available.
The server supports Azure DevOps Services only. On-premises Azure DevOps Server deployments aren’t supported because several required API endpoints aren’t yet available. For organizations running on-prem, the local MCP Server remains the option for now.
Why This Matters for DevOps
The Remote MCP Server is part of a pattern we’ve observed throughout this series of articles: DevOps toolchain data is becoming directly accessible to AI agents via standardized protocols.
Google’s ADK added integrations for GitHub, GitLab, Jira, and seven observability providers. GitHub Copilot’s coding agent now works inside Jira. The Azure Skills Plugin bundles 200+ MCP tools across 40+ Azure services. VS Code agent plugins distribute tool configurations through Git repositories. And now Azure DevOps itself hosts an MCP server that any compatible agent can connect to.
The shift from local to remote MCP servers matters for enterprise adoption. A local server requires installation, maintenance, and runs within a developer’s environment. A remote server is managed infrastructure — hosted by Microsoft, authenticated through Entra, governed by your organization’s existing access policies. For enterprise security teams, that’s a fundamentally different conversation. Data access follows the same rules as for every other Azure DevOps API call. No new trust boundaries to evaluate.
The read-only header is especially relevant for the use cases that generate the most organizational interest. Project managers are querying the sprint status. Product owners reviewing backlog health. Engineering leads checking pipeline reliability trends. These are read-only queries against live project data — exactly the scenario where agent access is most valuable and write permissions are least necessary.
Microsoft is making a clear bet: Azure DevOps data should be available to AI agents through the same authentication and authorization infrastructure the organization already uses for everything else. Not a separate integration. Not a custom bridge. A hosted MCP server at mcp.dev.azure.com that works with your existing Entra policies.
The Remote MCP Server is available now in public preview. The Foundry integration is live in the tool catalog.