Azure DevOps Remote MCP 服务器正式发布，暂不支持 Claude、ChatGPT 及 Cursor

事件核心：发生了什么

微软发布了 Azure DevOps Remote MCP Server 的正式版，为 AI 助手提供托管端点 https://mcp.dev.azure.com/{organization}，采用可流式传输的 HTTP 协议接入。这意味着开发者无需在本地安装或运行任何 MCP 服务，就能让 AI 助手直接读取 Azure DevOps 中的工作项、拉取请求、代码仓库和流水线状态。

然而，这个托管端点目前只对微软第一方客户端开放。Visual Studio Code 配合 GitHub Copilot、Microsoft Foundry 和 Copilot Studio 可以直接连接，Visual Studio、GitHub Copilot CLI 也同步支持。但 Claude Desktop、Claude Code、ChatGPT 和 Cursor 均无法连接，原因是身份认证依赖微软 Entra ID，而这些第三方客户端目前不具备通过 Entra 完成动态 OAuth 客户端注册的能力。微软方面确认正在与 Entra 团队合作推进适配，但未给出具体时间表。

值得注意的是，就在该服务正式发布前一周，MCP 规范 2026-07-28 版本刚刚调整了认证机制优先级——预注册客户端和客户端 ID 元数据文档成为主流，动态客户端注册已被弃用并计划在 2027 年夏季后移除。而 Entra 目前对这两套机制均不支持，其中一套还即将从协议中删除。

为什么重要

这次发布揭示了一个 MCP 协议本身无法解决的瓶颈：协议可以标准化工具发现和调用方式，却无法标准化身份提供商是否允许某个客户端完成认证。MCP 服务器的可托管性取决于底层身份层，而这一层仍由各云厂商掌握。

微软选择优先服务自家生态并非单纯商业排他——Azure DevOps 必须依托 Entra 租户运行，使用微软个人账户的独立组织被永久排除在支持范围之外，这属于平台架构层面的现实约束。但从竞争角度看，这个时间窗口客观上拉大了 Copilot 与 Claude、ChatGPT 在 Azure DevOps 场景下的体验差距。对于已将 Claude Code 或 Cursor 设为团队标准的开发者来说，无论微软意图如何，实际影响都是必须继续自行维护本地 MCP 服务器。

微软承诺在 Entra 适配完成前维持本地服务器与远程服务器的功能对等，这一表态缓解了第三方客户端用户被”降级”的担忧，也说明微软意识到生态兼容的重要性。

对用户/开发者/创作者的影响

对于使用 GitHub Copilot 或 Foundry 的 Azure DevOps 团队，托管 MCP 服务器能显著降低入门门槛——无需为每位开发者或每个项目单独部署服务，也不涉及本地凭证管理。微软工程师 Farhan Shahnewaz 举例说，他能直接向 AI 助手询问”流水线哪个阶段失败、原因是什么”，省去翻阅数千行日志的时间，且通过 Entra 继承的权限与开发者本人完全一致，不会在配置文件中泄露个人访问令牌。

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。

对于使用 Claude、ChatGPT 或 Cursor 的开发者，目前的现实是：要么继续运行本地 MCP 服务器，承担凭证存储和维护成本，要么等待微软完成 Entra 侧的适配。企业安全团队在评估时也需注意，第三方的本地服务器方案在权限管控上与微软托管方案存在差异。

值得关注的后续

第一，微软 Entra 团队何时支持客户端 ID 元数据文档或预注册客户端机制，这将直接决定 Claude 和 Cursor 用户能否接入远程 MCP 服务器。第二，MCP 规范中动态客户端注册的弃用时间线（2027 年夏季）会不会倒逼 Entra 加速适配，或者反过来促使其他身份提供商调整策略。第三，本地 MCP 服务器与远程服务器的功能对等承诺能维持多久——如果远程版本持续迭代而本地版本滞后，第三方客户端用户的体验差距会逐步拉大。

来源：InfoQ CN