Microsoft 已将 Azure DevOps Remote MCP Server 推进到 GA（正式可用）。它的核心价值很直接：为 AI 客户端提供一个托管的 MCP 入口，让模型能够在授权范围内查询和操作 Azure DevOps 的工作项、代码仓库与流水线，而团队不必自行部署 MCP Server、维护运行环境或暴露内部服务。
不过，GA 不等于所有 MCP 客户端都能立即接入。当前 Claude Desktop、Claude Code、ChatGPT 和 Cursor 仍无法连接，阻塞点不在 Azure DevOps 工具能力，而在 Microsoft Entra 对动态客户端注册（Dynamic Client Registration）和 Client ID Metadata Documents 的支持缺口。
托管 MCP 解决的是什么问题
MCP（Model Context Protocol）让 AI 应用以统一方式发现工具、读取上下文并调用外部系统。对 Azure DevOps 而言，常见的上下文包括：某个 Bug 的状态、关联 Pull Request 的改动、构建是否失败、发布流水线最近一次执行结果等。
自己搭建 MCP Server 往往会带来一串工程问题：
- 需要托管服务、处理升级和监控。
- 需要保存 Azure DevOps 或 Entra 的凭据。
- 需要设计最小权限、审计日志和网络边界。
- 需要跟进 MCP 协议与不同 AI 客户端的兼容性。
Remote MCP Server 将服务端托管起来，客户端通过远程端点连接。这样可以把重点放回身份授权和工具使用场景，而不是运行一个额外的中间层服务。
为什么 Claude、ChatGPT、Cursor 目前连不上
远程 MCP 不只是“给一个 URL 就能连”。客户端需要与身份提供方协商 OAuth 身份认证，并在某些场景下动态注册自身，或通过 Client ID Metadata Documents 获取客户端身份相关元数据。
来源信息指出，Microsoft Entra 目前不支持这两个能力：
- 动态客户端注册：客户端在运行时向授权服务器注册，而不是由管理员预先创建并分发固定 Client ID。
- Client ID Metadata Documents：客户端可通过标准化元数据文档让授权服务器识别其注册信息和回调配置。
这会影响依赖相关 MCP OAuth 流程的客户端。即使 Azure DevOps Remote MCP Server 已经 GA，Claude Desktop、Claude Code、ChatGPT 和 Cursor 也无法完成所需的 Entra 登录和授权流程。
这里要区分两个层面：Azure DevOps Remote MCP Server 的托管服务已可用，不代表每个 MCP 消费端都已具备与 Entra 互操作的认证能力。评估时，应把“服务可用性”和“目标客户端的 OAuth 兼容性”分开验收。
可以这样实践：先把兼容性验证做成部署前检查
在将远程 MCP 接入生产助手前，建议先建立一份兼容性矩阵。重点不是只记录“某客户端支持 MCP”，而是记录它是否能够完成当前企业身份系统所需的授权方式。
下面的脚本是一个可直接改造的预检查模板。它不会调用 Azure DevOps，也不会尝试猜测远程 MCP 端点；它将客户端、认证要求和当前结论明确写入可审阅的配置文件，适合作为架构评审或上线门禁的一部分。
保存为 mcp-compatibility.yaml：
identity_provider: Microsoft Entra ID
server: Azure DevOps Remote MCP Server
checks:
- client: Claude Desktop
requires_dynamic_client_registration: true
requires_client_id_metadata_document: true
status: blocked
reason: Entra support for the required registration flow is unavailable
- client: Claude Code
requires_dynamic_client_registration: true
requires_client_id_metadata_document: true
status: blocked
reason: Entra support for the required registration flow is unavailable
- client: ChatGPT
requires_dynamic_client_registration: true
requires_client_id_metadata_document: true
status: blocked
reason: Entra support for the required registration flow is unavailable
- client: Cursor
requires_dynamic_client_registration: true
requires_client_id_metadata_document: true
status: blocked
reason: Entra support for the required registration flow is unavailable
使用 yq 将被阻塞的客户端列出来：
yq -r '.checks[] | select(.status == "blocked") | "\(.client): \(.reason)"' mcp-compatibility.yaml
预期输出会明确指出四个客户端当前都受 Entra 授权能力限制。实际落地时，可以继续在同一个文件中补充组织允许的客户端、所需权限范围、测试租户和责任人。
对于已具备可用认证路径的客户端，测试应至少覆盖以下动作：
- 使用普通开发者账号完成交互式登录。
- 仅授予读取工作项、仓库或流水线所需的最小权限。
- 验证模型能读取授权项目，且无法访问未授权组织或项目。
- 检查流水线触发、工作项更新等写操作是否需要额外确认。
- 记录 Entra、Azure DevOps 与 AI 客户端侧的审计信息。
接入时不要把“能读”直接扩展成“能改”
将工作项、仓库和流水线暴露给 AI 工具后，风险等级并不一致。读取一个 Work Item 与重新运行生产发布流水线，显然不应使用同一套默认权限和确认机制。
可以按能力分层：
| 能力 | 建议默认策略 |
|---|---|
| 查询工作项、PR、构建状态 | 优先开放，限制到指定组织和项目 |
| 读取仓库内容 | 排除密钥、部署配置和敏感目录，保留审计 |
| 创建或更新工作项 | 要求用户确认，并限制字段与项目范围 |
| 触发流水线、修改代码、完成 PR | 默认关闭，按场景单独授权 |
尤其要注意提示注入风险。仓库 README、Issue 描述、PR 评论和构建日志都可能是模型读取的外部文本。它们不应自动获得“指挥模型调用高权限工具”的资格。对于具备写权限的工具调用，保留显式确认、项目白名单和动作审计，比单纯依赖模型提示词更可靠。
采用建议：现在评估服务，等待认证生态补齐
Azure DevOps Remote MCP Server 的 GA 让“无需自建服务即可把 DevOps 上下文带入 AI 工作流”成为一个可评估选项。对已有 Azure DevOps 和 Entra 环境的团队，这减少了基础设施维护面，也让权限治理更集中。
但当前的实际决策应从客户端开始：你计划使用的 AI 应用能否完成 Entra 认证？若目标是 Claude Desktop、Claude Code、ChatGPT 或 Cursor，现阶段应将其标记为兼容性阻塞，而不是在生产环境中投入大量集成工作。
一个务实的上线清单是：
- 确认目标 MCP 客户端与 Entra 的 OAuth 流程兼容。
- 为读取和写入操作分别设计最小权限。
- 在隔离项目中验证工作项、仓库和流水线工具的真实边界。
- 为高影响动作保留用户确认和审计记录。
- 持续关注 Entra 对动态客户端注册及 Client ID Metadata Documents 的支持进展。
当认证链路完整后，远程托管 MCP 的优势才会真正落到日常研发流程中：模型能获得及时的 DevOps 上下文，团队则不必为此额外运营一套 MCP 服务。