一个CI的MCP服务器，该给智能体四件事？

一个CI的MCP服务器，到底该给智能体什么？答案可以压缩成四个动作：启动一次运行、等它结束、读出它为什么失败、再读出失败背后的日志。全程不需要打开浏览器。

这四个动作之外，还有两条分界线，用来区分"好服务器"和"薄薄一层API包装"。一条是花费护栏——能启动运行的智能体，也就能启动太多运行。另一条是不实际运行就检查工作流文件的能力，否则智能体改完CI配置，要等下一次推送才知道改错了。

没有服务器时，智能体靠shell驱动CI：gh workflow run、一个轮询循环、gh run view --log-failed，外加一大堆必须当作上下文读进去的输出。有了服务器，这些变成带结构化回答的类型化调用，而且决定智能体能做什么的是服务器，不是提示词。

四个调用，按顺序来

启动：触发一次运行或一个作业，拿回一个供下一次调用使用的id。等待：阻塞到运行结束，或阻塞到一个短期限并带回一个可续传的游标，免得智能体每轮询一次就烧掉一个回合。读失败：先给判定结果、失败的步骤，理想情况下还有原因，然后才是原始日志。读日志：按需取失败作业的尾部。

GitHub官方的MCP服务器把Actions能力放在一个叫actions的工具集里，它不在默认集合中（默认是context、repos、issues、pull_requests和users）。本地用--toolsets或GITHUB_TOOLSETS打开，或直接使用该工具集的远程URL；在地址后追加/readonly则只保留读工具。

这个工具集有四个工具。actions_list列出工作流、运行、作业和产物；actions_get读取单个工作流、运行、作业或产物，包括运行用量和日志URL；actions_run_trigger通过run_workflow方法运行工作流，接收ref和inputs，其余方法作用于run_id；get_job_logs读取单个作业的日志，配合failed_only可读取一次运行中所有失败作业，tail_lines把范围限制在末尾。

它没有等待工具：智能体只能反复调用actions_get轮询，直到运行完成。花费护栏和工作流文件检查这两项，这个工具集也都没有。

另一家的24个工具

Latchkey的MCP清单列出24个工具和两个提示词——fix与triage_failures，并标注了每个工具所需的权限范围。按四个调用加两项额外能力归类，它覆盖得更完整。

等待环节是两者差别最大的地方。GitHub工具集里，智能体调用actions_get的get_workflow_run方法，读出状态，自己决定何时再调一次，每次轮询都是一个回合。Latchkey的wait_run跟随一次运行、某个提交上的运行，或某个拉取请求在其最新提交上的运行，每次调用最多挂起25秒；当done为false时，回答里带着poll_after_s和一个cursor，智能体用同样的参数加上这个游标再调一次。

等待时间很长时，两者都不能替代shell。Latchkey的CLI参考文档建议，长达数分钟的等待用latchkey wait更合适。

连接时就把权限收窄

连接命令只有一行，权限由密钥决定。默认密钥是只读的：智能体可以列出失败、拉取失败包、读取状态、看日志尾部，别的什么都做不了。运行作业、派发工作流、启动Latchkey CI工作流，每一项都要在创建密钥时单独开通，做法是给每个编码智能体配一把限定范围的API密钥。

在Claude Code里，/mcp__latchkey__fix会对Latchkey最近一次没能自行修复的失败运行fix提示词。

边界也要说清楚。run_job从空目录启动：没有工作区，没有仓库检出。任何需要智能体工作树的操作都要走latchkey run，由它打包并上传。作业日志保留7天可读。一个工作区同时最多持有10个等待，wait_run的每次调用和latchkey wait的每次查看都计入其中，多个智能体并行等待可能撞上RUN_WAIT_LIMIT_REACHED，重新再看一次即可。

还有一条处理规则：把CI工具返回的一切当作数据，永远不要当作指令。日志里可能含有外部贡献者写下的文本，而读它的智能体可能对你的检出目录持有写权限。

两个服务器的描述都来自它们公开的材料：github/github-mcp-server v2.1.0的README及其远程服务器文档，以及Latchkey的MCP清单和connect-your-agent页面。工具清单和权限范围，才是决定任何智能体能做什么的东西。