Harness MCP Server 的意义，是把 Harness 平台能力接入支持 MCP 的外部 AI 工具。用户搜索这个词时，通常不是在问“MCP 是什么”，而是在问：能不能让 Cursor、Claude Code、Claude Desktop、Windsurf、VS Code 或类似工具安全地访问 Harness pipeline、execution、service、connector、secret metadata 和审计数据。
这篇不把 MCP 写成万能自动化入口。它的核心任务，是帮你在接入前判断：该用 Hosted MCP 还是自托管 MCP，哪些资源可以暴露，哪些动作必须留在人工审批之后。
先抓住这 3 个关键点
| 关键点 | 应用层含义 |
|---|---|
| MCP 是连接层 | 它让外部 AI 工具访问 Harness，不等于自动具备正确 DevOps 判断 |
| Harness 官方提供 Hosted MCP 和开源 MCP Server | SaaS 用户可以看 Hosted MCP，自托管或本地调试再看 harness-mcp-v2 |
| 权限仍以 Harness 身份和配置为核心 | RBAC、API key、toolsets、read-only、确认提示和日志要一起设计 |
官方资料显示，Harness MCP Server 采用少量通用工具映射多类 Harness 资源，避免一个 API endpoint 对应一个工具导致模型选错工具。Harness AI Overview 也把 MCP Server 放在 Harness AI 功能列表里，定位是连接 Cursor、Windsurf、Claude Desktop、VS Code 等外部 AI 工具。
它解决什么问题
如果团队已经在用 AI 编辑器或终端助手，你可能希望这些工具不只是读代码，还能回答更贴近交付流程的问题：
- 这个 pipeline 最近为什么失败？
- 某个 service、environment、connector 是否存在？
- 这次执行的日志和审批卡在哪里？
- 能不能生成 pipeline 草稿或修复建议？
- 能不能让 Worker Agent 或 Harness Skills 在真实平台资源上工作？
Harness MCP Server 就是这类连接层。它让 AI 工具通过统一协议访问 Harness 平台能力，但接入后真正有价值的不是“能调工具”，而是“能在受控范围内调正确工具”。
Hosted MCP 还是自托管 MCP
| 路线 | 更适合谁 | 关键判断 |
|---|---|---|
| Hosted MCP | Harness SaaS 用户，想尽快接入 Cursor、Claude Code、VS Code 或 Windsurf | 走 Harness OAuth，使用当前用户身份和平台 RBAC；需要确认账号已启用 OAuth |
harness-mcp-v2 本地 stdio | 想在本机 AI 工具里试点，或需要更直接控制环境变量 | 需要 PAT，GUI 工具可能找不到 npx 或 node，要用绝对路径或显式 PATH |
| HTTP / Docker / Kubernetes | 想把 MCP 作为共享服务或远程服务 | 要处理网络、健康检查、CORS、会话、密钥、日志和部署安全 |
第一轮试点不要一上来就做共享服务。除非你已经有明确的团队接入需求，否则先用 Hosted MCP 或本地 stdio 跑通只读查询，更容易发现权限和工具范围问题。
接入前先确认
| 检查项 | 为什么重要 |
|---|---|
| 客户端 | Cursor、Claude Code、Claude Desktop、Windsurf、VS Code 的 MCP 配置位置和认证方式不同 |
| 身份 | Hosted MCP 使用 OAuth 身份，自托管通常需要 PAT，不要把个人全权限 token 塞进共享配置 |
| 资源范围 | 先限制 account、org、project、pipeline 或 toolsets，避免让模型看到不相关资源 |
| 操作类型 | 区分读取、生成草稿、执行 pipeline、修改 connector、删除资源 |
| 确认机制 | 写操作、删除操作和执行操作要保留确认或审批，不能把 headless 自动化当默认模式 |
| 日志与回滚 | 关键调用要能追踪，真实变更要知道由谁触发、改了什么、如何恢复 |
推荐的第一轮接入清单
- 选一个低风险客户端，比如 Cursor 或 VS Code 的个人工作区。
- 确认 Harness 账号、org、project 和目标 pipeline，不要先接全平台。
- 如果使用 Hosted MCP，先确认 OAuth 已启用，并使用官方 Hosted MCP URL。
- 如果使用自托管 MCP，使用专门 PAT，不复用管理员长期 token。
- 开启只读试点，或在自托管时使用
HARNESS_READ_ONLY=true。 - 使用
HARNESS_TOOLSETS只暴露第一轮需要的资源类型，例如 pipeline、execution、service、connector。 - 让 AI 工具先做查询、总结、生成草稿，不直接执行生产变更。
- 记录一次完整调用链：谁发起、调用了什么资源、输出是否被人工采纳。
低风险试点场景
建议第一阶段只做这些：
- 查询 pipeline、execution、service 和 environment 信息。
- 总结失败原因，并要求附上它基于哪些日志或执行数据。
- 生成修改建议。
- 生成 pipeline 或 policy 草稿，而不是直接发布。
- 让 Harness Skills 辅助创建清单，但只进入人工 review。
暂缓：
- 自动修改生产 pipeline。
- 自动触发部署。
- 自动删除 connector、secret、delegate token 或环境资源。
- 在没有审批记录时自动改策略。
和 Harness Skills、Worker Agents 的关系
Harness Skills 更像一组结构化提示和工作流，它们会借助 Harness MCP Server 发现资源 schema、列出资源、创建或更新平台对象。MCP Server 是工具通道，Skills 是“如何使用这些工具”的上下文。
Worker Agents 则更贴近 pipeline 内的 AI 工位。它们可以使用 MCP-connected data sources，并把结果作为 pipeline 产物、输出变量或审批依据。也就是说，MCP 可以服务于外部 AI 工具，也可以成为 Worker Agents 获取平台数据的连接方式。
和 Harness AI DevOps Agent 的关系
Harness AI DevOps Agent 是平台内 AI 能力，MCP Server 更像把平台能力接给外部 AI 工具的桥。两者都属于 Harness AI 生态，但用户任务不同。
如果你只是想知道 Harness AI 能做什么，先看 DevOps Agent；如果你已经在使用外部 AI 编程工具，再看 MCP Server。
常见坑
| 问题 | 处理方式 |
|---|---|
GUI 客户端找不到 npx 或 node | 在 MCP 配置里使用绝对路径，并显式设置 PATH |
| Hosted MCP 登录失败 | 先确认 Harness 账号是否启用了 OAuth，不要反复重置密码 |
| 模型总是选错资源类型 | 缩小 toolsets，让它只看到本轮试点需要的资源 |
| 写操作过早自动化 | 保留 elicitation、审批或只读模式，先用草稿输出建立信任 |
| 本地 HTTP 服务暴露过宽 | 只在开发网络内验证，不把本地调试端口直接当生产入口 |
完成检查
- 你知道哪些外部工具需要接入 Harness。
- 你能解释 Hosted MCP、自托管 MCP 和本地 stdio 的差异。
- 你已经划定只读或低风险资源范围，并知道该限制哪些 toolsets。
- 你知道哪些动作必须审批。
- 你能区分 DevOps Agent、Worker Agents、Harness Skills 和 MCP Server 的不同使用场景。
下一步内链
- 如果你要把 MCP 接到具体客户端，继续看 Harness MCP Server 接入 Cursor、Claude Desktop 与 VS Code。
- 如果你要判断 pipeline 内 AI 工位和代码助手的边界，继续看 Harness Worker Agents vs Code Agent。
- 如果你还在分不清 agent harness 和 MCP，继续看 Agent Harness vs MCP。