8 月初，微软正式发布 Azure DevOps Remote MCP Server——一个托管端点，让 AI 助手无需本地安装即可直接访问工作项、拉取请求、代码库与流水线。但首批用户发现：Claude Desktop、Claude Code、ChatGPT 和 Cursor 均无法连接。原因不在这些客户端，而在微软自己。
过去，想让 AI 助手操作 Azure DevOps，团队得自己搭一个本地 MCP 服务器——安装、配置、维护凭证，每个开发者或每个团队都要重复这套流程。
现在微软把这个过程整个折叠进一个 URL：
{
"servers": {
"ado-remote-mcp": {
"url": "https://mcp.dev.azure.com/{organization}",
"type": "http"
}
},
"inputs": []
}
在 mcp.json 中添加上述配置即可。采用可流式传输的 HTTP 协议，由 Azure DevOps 托管，身份认证走微软 Entra ID。
Azure Boards、Repos 和 Wiki 产品经理 Dan Hellem 确认了核心能力边界：能否支持完全取决于客户端是否具备通过 Entra ID 完成身份认证的能力。
Claude Desktop、Claude Code、ChatGPT、Cursor——这些客户端要连上远程 MCP 服务器，需要 Entra 支持动态 OAuth 客户端注册或客户端 ID 元数据文档。Entra 目前两者都不支持。
微软正在与 Entra 团队合作启用该功能，但没有公布时间表。
时间点让这件事更加微妙。
就在正式发布前一周，MCP 2026-07-28 规范刚刚重新调整了认证机制优先级：
规范推荐的首选方案，但 Entra 目前不支持。
同样被 Entra 搁置。
这是 Claude、ChatGPT 等客户端当前依赖的机制，却正在被协议本身淘汰。
换句话说：协议在改方向，身份提供商还没跟上，第三方客户端被卡在中间。
另外还有一个永久性限制：组织必须以 Entra 租户为支撑，使用微软个人账户的独立组织不在支持范围内。
目前能直接连上的是清一色的微软阵营：
Claude Desktop · Claude Code · ChatGPT · Cursor
VS Code + GitHub Copilot · Microsoft Foundry · Copilot Studio · Visual Studio · GitHub Copilot CLI
其他 AI 智能体团队仍可走本地 MCP 服务器路径。微软承诺在 Entra 适配完成前，本地工具集与远程服务器保持功能对等。
微软 AI 与云解决方案工程师 Farhan Shahnewaz 在实测中强调了安全收益：配置文件中不会存放任何可能泄露的个人访问令牌；通过 Entra，AI 助手继承的权限与开发者完全一致——不多不少。
Shahnewaz 在一个小型 ASP.NET Core 应用背后跑了两阶段流水线，然后直接问 AI 助手：
但这是一枚硬币的两面。
使用 Copilot 的团队享受全部红利，而选择了 Claude Code 或 Cursor 的团队——即使技术能力更强——却要独自承担本地部署的全部负担。Shahnewaz 没有回避这一点，他称之为“平台依赖问题，而非刻意的商业策略”。
这次发布暴露了一个 MCP 协议自身无法解决的问题。
无状态化和标准标头确实让 MCP 服务器更易于托管和管理。但底层的身份层仍由各家供应商自行掌控——一个协议可以标准化客户端如何发现工具、如何调用工具，却无法标准化某个身份提供商是否允许该客户端完成身份验证。
微软对本地服务器的维护承诺，佐证了这更像真实存在的技术依赖，而非刻意锁客。但无论原因如何，对于以 Claude Code 或 Cursor 为团队标准的开发者来说，实际影响没有区别。
而且目前没有时间表。微软尚未公布 Entra 适配工作的具体完成日期。
MCP 标准化了 AI 智能体与工具之间的“握手”，却把“门禁”留给了各家身份提供商——协议解决通信，不解决信任。
使用 VS Code + GitHub Copilot 或 Microsoft Foundry 的团队，可直接在 mcp.json 中添加配置接入。
官方文档 → 配置 Remote MCP mcp.dev.azure.com/{organization}