InfoQ highlighted the split in its August 21 report, and Microsoft’s August 5 Azure DevOps Blog announcement confirms the cause: the remote service authenticates through Microsoft Entra, while those clients need Entra support for Dynamic Client Registration or Client ID Metadata Documents before they can complete the OAuth flow. Microsoft says it is working with the Entra team; it has not published a delivery date.
For Windows developers and IT administrators, this is less a question of whether Azure DevOps now has MCP support—it does—than which AI client your organization standardizes on. Teams centered on GitHub Copilot can move to a managed endpoint now. Teams using Claude Code, Cursor, or ChatGPT must keep a local service and its deployment, update, and credential-management responsibilities in place.
GA for the service, not universal client compatibility
The endpoint is straightforward: an MCP-capable client connects to [url]https://mcp.dev.azure.com/[/url]{organization} using streamable HTTP. Azure DevOps hosts the MCP server, and authentication is handled through the user’s Microsoft Entra identity rather than through a personal access token embedded in a configuration file.
Microsoft lists Visual Studio Code with GitHub Copilot, Visual Studio, GitHub Copilot CLI, the GitHub Copilot app, Microsoft Foundry, and Copilot Studio among the environments supported at launch. For those clients, the remote server removes the ordinary local prerequisites: no Node.js runtime, no npx invocation, no server process running on a workstation, and no developer-managed endpoint to patch.
The unsupported-client list is equally consequential. Claude Desktop, Claude Code, ChatGPT, Cursor, and CodeX are not blocked because Azure DevOps has no MCP tools for them. They are blocked at registration and sign-in, before the tool layer is available. Microsoft’s official documentation says those environments require an OAuth client-registration capability that Entra does not currently provide for this scenario.
That makes the apparent asymmetry real in practice. A GitHub Copilot user can point a supported client at the Azure DevOps-hosted URL and authorize through Entra. A colleague using Cursor or Claude Code can access the same Azure DevOps organization only by continuing to run Microsoft’s local MCP Server.
Microsoft’s own documentation still shows the transition
There is a revealing documentation inconsistency behind the launch. Microsoft’s Azure DevOps Blog calls the Remote MCP Server generally available, and the Azure DevOps released-features timeline records the remote server’s public-preview period before the GA announcement. Yet a Learn page for setting up the remote server still labels it preview and carries a July 14, 2026 update date—three weeks before Microsoft announced general availability on August 5.
The setup instructions themselves remain useful, but administrators should not interpret the stale preview banner as evidence that the service is still in preview. The more important warning is operational: Microsoft’s documentation says remote availability depends on both the user account and the Azure DevOps organization being connected to Microsoft Entra ID.
Standalone Azure DevOps organizations backed by Microsoft accounts are not eligible for the remote service. That restriction is not a temporary compatibility issue like the Claude or Cursor gap; Microsoft presents it as a requirement for the Entra-authenticated architecture.
For organizations with older standalone Azure DevOps tenants, the result is simple: migrating developer tooling to MCP will not, by itself, unlock the hosted service. They need an Entra-backed organization—or must remain on the local server model.
The local server remains the fallback, with a different security profile
Microsoft has not retired its local Azure DevOps MCP Server. It says it recently consolidated the local toolset so it aligns with the remote offering and has committed to maintaining feature parity while Entra work continues.
That is a meaningful assurance, particularly for organizations that have already built agent workflows around Claude Code or Cursor. It means the remote GA does not create a functional dead end for those users, at least according to Microsoft’s product commitment. It does, however, leave them with a different operating model.
The local server can authenticate with a personal access token or with Microsoft Entra, according to Microsoft’s Azure DevOps documentation. A managed remote deployment removes the need to distribute and supervise a local service, while Entra-based access lets the hosted service apply the user’s existing Azure DevOps permissions. A local installation using a PAT requires more care: token issuance, storage, expiration, revocation, and the possibility that an overly broad token outlives the workstation configuration that uses it.
Administrators should treat the remote service as an opportunity to reduce credential sprawl, not as permission to grant an assistant broad access. Azure DevOps supports headers that restrict the remote server to selected toolsets and, critically, a read-only mode. A client configured with the X-MCP-Readonly header can query projects, work items, pull requests, repositories, and pipelines without being allowed to modify Azure DevOps resources through MCP.
That distinction should be part of rollout design. A troubleshooting assistant that needs to inspect failed pipeline runs does not automatically need permission to create work items, edit wiki pages, or change repository state. The hosted endpoint may simplify authentication, but it does not replace least-privilege configuration.
MCP’s authorization standard has moved faster than Entra support
InfoQ’s account places the client-registration limitation against the July 28, 2026 MCP specification revision. The primary MCP specification supports that broader point: Client ID Metadata Documents are now the preferred registration model, while Dynamic Client Registration is retained as a deprecated compatibility option.
The ordering matters. The specification says clients obtain a client ID through Client ID Metadata Documents, pre-registration, or Dynamic Client Registration. It recommends support for Client ID Metadata Documents and describes Dynamic Client Registration as deprecated, rather than treating DCR as the durable path for new deployments.
One detail in the submitted reporting needs a correction: the current MCP specification says DCR will be removed in a future version, but it does not set a published “after summer 2027” removal date. Administrators should plan on DCR becoming less central, but should not treat an unconfirmed calendar deadline as a protocol commitment.
Microsoft’s immediate problem is broader than DCR alone. Its Azure DevOps announcement says the affected clients require either DCR or Client ID Metadata Documents in Entra before they can connect. In other words, the protocol has a preferred forward path, but Microsoft’s identity platform has not yet enabled either route needed by these clients for the Azure DevOps remote service.
This is an identity-platform dependency, not proof that Claude, ChatGPT, Cursor, or their vendors have declined to support Azure DevOps. Microsoft explicitly attributes the gap to Entra capabilities and says work is under way with the Entra team. No independently reported timeline has emerged beyond that statement.
What Windows development teams should do now
Organizations already using GitHub Copilot in Visual Studio Code or Visual Studio can begin evaluating the remote server as a managed replacement for local Azure DevOps MCP deployments. Start with a narrow project scope, read-only access, and only the needed toolsets—such as pipelines, repos, or wit for work items—before exposing the full collection of Azure DevOps tools to an assistant.
Teams committed to Claude Code, Cursor, ChatGPT, or Claude Desktop should not delay their plans on the assumption that the GA announcement enables those clients. Microsoft’s supported-client list says otherwise. Keep the local server in the design, prefer Entra authentication over long-lived PATs where the client supports it, and define how local server versions and workstation configurations will be maintained.
The practical gap is operational rather than theoretical. Microsoft now offers a hosted Azure DevOps MCP endpoint, but its zero-install experience currently belongs mostly to Microsoft’s own developer and agent clients. Until Entra gains the required registration support, third-party-agent users will continue carrying the local-server burden that the GA release was meant to remove.