微软已正式发布 Azure DevOps Remote MCP Server，为 AI 助手提供了一个托管端点，可直接访问工作项、拉取请求、代码库和流水线，无需安装或运行任何本地服务。不过目前 Claude Desktop、Claude Code、ChatGPT 和 Cursor 尚无法连接该服务，问题出在微软内部，而非这些客户端。
该服务器的端点为 https://mcp.dev.azure.com/{organization}，采用可流式传输的 HTTP 协议。连接受支持的客户端只需在 mcp.json 中添加一个条目：
{ "servers": { "ado-remote-mcp": { "url": "https://mcp.dev.azure.com/{organization}", "type": "http" } }, "inputs": []}该端点由 Azure DevOps 托管，身份认证通过微软 Entra ID 完成，而这正是限制的来源所在。官方文档提供了更多配置选项。
负责 Azure Boards、Repos 和 Wiki 的产品经理 Dan Hellem 明确指出了这一依赖关系。能否支持取决于客户端是否具备通过 Entra 完成身份认证的能力，而 Claude Desktop、Claude Code、ChatGPT 和 Cursor 等客户端需要 Entra 支持动态 OAuth 客户端注册或客户端 ID 元数据文档后才能连接。微软正在与 Entra 团队合作启用该功能，在此之前，这些用户只能继续使用本地服务器。
微软 AI 与云解决方案工程师 Farhan Shahnewaz 在其文章中指出，这项限制恰恰体现了其设计初衷。在介绍自己的使用体验时，他提到配置文件中不会存放任何可能泄露的个人访问令牌；通过 Entra，AI 助手继承的权限与开发者完全一致、不多不少——而这正是每个安全团队首要关注的问题。
（来源：Farhan Shahnewaz，微软）
而另一个因素让时间点显得颇为尴尬，就在正式发布前一周发布的 MCP 2026-07-28 规范恰好重新调整了上述两种认证机制的优先级。该规范现在优先采用预注册客户端，其次是客户端 ID 元数据文档，而动态客户端注册已被弃用，并计划在 2027 年夏季后移除。Entra 目前对这份规范所依赖的这两套机制均不支持，并且其中一种机制已经要从协议中被移除。
第二项限制则是永久性的：组织必须以 Entra 租户作为支撑，因此使用微软个人账户的独立组织不在支持范围内。
目前可正常使用的是一系列微软自家的客户端。Hellem 特别指出，Visual Studio Code 配合 GitHub Copilot、通过工具目录接入的 Microsoft Foundry，以及新加入的 Copilot Studio 均可无需额外配置直接连接；Visual Studio、GitHub Copilot CLI 和 GitHub Copilot 应用也同样支持。
对于使用其他 AI 智能体的团队，本地 MCP 服务器仍是可行路径。微软表示，近期已整合本地工具集，使其与远程服务器保持对齐；同时承诺，在 Entra 相关适配工作推进期间会维持两者功能对等。
抛开主观揣测，实际现状是：微软自家的第一方客户端可直接通过无需安装的托管端点访问 Azure DevOps；而第三方 AI 智能体则仍需要自行运行服务器。这篇博文所呈现出来的更像是真实存在的平台依赖问题，而非刻意的商业策略，微软对本地服务器的维护承诺也佐证了这一判断。但无论背后原因为何，对于选择 Claude Code 或 Cursor 作为团队标准工具的团队来说，实际影响并无二致。
这种影响不可小觑。Shahnewaz 从运维角度描述了应用场景：在一个小型 ASP.NET Core 应用背后运行的两阶段流水线中，他可以直接问 AI 助手“哪个阶段失败了、原因是什么”，而无需打开五个浏览器标签页、翻阅四千行日志——AI 助手通过团队现有系统读取流水线上下文与日志。托管服务器免除了每位开发者或每个团队单独部署服务的负担，也一并省去随之而来的凭证管理工作。无法使用该托管服务的团队就要承担这部分负担，而使用 Copilot 的同事则无需面对这些麻烦。
此次发布也揭示了一个 MCP 规范自身无法解决的问题。无状态化和标准标头确实让 MCP 服务器更易于托管和管理，但其底层的身份层仍由各家供应商自行掌控。一个协议可以标准化客户端如何发现工具并调用工具，却无法标准化某个身份提供商是否允许该客户端完成身份验证。
微软尚未公布 Entra 相关工作的具体时间表。
查看英文原文：https://www.infoq.com/news/2026/08/azure-devops-remote-mcp-ga/
