用 MCP 服务器把自定义 Agent 接进 Jira 与文档系统

定义：AI 目录中的 MCP 服务器，是指在极狐GitLab AI 目录里登记的一个远程 MCP（Model Context Protocol，模型上下文协议）服务端点，自定义 Agent 通过它在运行期间调用外部系统提供的工具，从而读写 Jira、Confluence、Linear 等第三方系统的数据。该功能于极狐GitLab 18.10 引入，受 ai_catalog_mcp_servers 功能标志控制，当前状态为实验。

团队把内部流程交给 Agent 时，最先撞上的往往不是模型能力，而是数据不在同一个地方。需求写在 Jira，设计文档躺在 Confluence，缺陷在 Linear，代码在极狐GitLab。Agent 只能在代码仓库这一亩三分地里打转，跨系统那一步永远要人手工搬运。

MCP 服务器就是为这一步准备的。本文讲清楚它是什么、怎么配、能做什么，以及——更重要的——什么情况下你不该用它。

为什么 Agent 需要一层标准协议

在没有 MCP 之前，让 Agent 访问外部系统只有两条路：写死一个插件，或者把数据提前同步进仓库。前者每接一个系统就要开发一次，后者数据永远是陈旧的。

MCP 把这件事收敛成一个约定：外部系统暴露一组带名称和参数的工具，Agent 通过标准协议发现并调用。对平台侧而言，接入成本从「开发一个集成」降到「登记一个 URL」。

在极狐GitLab 里，这条链路长这样：

1. 管理员在 AI 目录的 MCP 选项卡登记一个服务器（名称、URL、传输类型、认证方式）。

2. 在 代理 选项卡把该服务器关联到某个自定义 Agent。

3. Agent 运行期间即可使用该服务器提供的全部工具。

关联的粒度是服务器级。也就是说，一旦挂上，Agent 能用这台服务器上的所有工具，目前无法只开放其中某几个。这是设计上的取舍，后面会展开。

怎么配：从登记到关联

前置条件

动手之前先确认这几条，否则会在最后一步卡住：

• 满足极狐GitLab Duo Agent Platform 的先决条件；

• 你所在的是顶级群组，且已开启 Duo 的实验和测试功能；

• 要添加或编辑 MCP 服务器，你必须是实例管理员；

• 目标服务器必须是远程 MCP 服务器，且属于已审核或合作伙伴的服务器——任意 URL 不予接受。

传输方式目前只支持 HTTP。SSE 和 stdio 两种传输不可用，这点在选型自建服务时要提前考虑。

登记一个 MCP 服务器

路径：群组 → 构建 → AI 目录 → MCP → 新建 MCP 服务器。需要填写：

已知可用的三个服务器（均来自官方目录）：

Linear     https://mcp.linear.app/mcp        传输 HTTP  认证 OAuth
Atlassian  https://mcp.atlassian.com/v1/mcp  传输 HTTP  认证 OAuth
Context7   https://mcp.context7.com/mcp      传输 HTTP  认证 无

接 Atlassian 时有一个容易漏掉的动作：需要先在 Atlassian 管理后台把极狐GitLab 配成受信任域。路径是 应用 → AI 设置 → Rovo MCP 服务器，把 https://gitlab.com/** 加入受信任域列表。不配这一步，OAuth 授权会被拒。

关联到自定义 Agent

路径：群组 → 构建 → AI 目录 → 代理 → 选择 Agent → 编辑 → 在「MCP 服务器」部分勾选 → 保存。

保存后，Agent 详情页面会列出所有已连接的服务器，随时可查。

如果服务器启用了 OAuth，还需要在群组或项目级做一次授权：AI → MCP 服务器 → 找到服务器 → 连接 → 在授权页面批准。若服务器支持 OAuth 2.0 动态客户端注册，极狐GitLab 会在首次连接时自动注册为 OAuth 客户端，无需手填凭证；令牌由平台安全存储，供后续请求复用。

一个可落地的用法

把 Atlassian MCP 服务器挂到一个「需求同步」自定义 Agent 上，Agent 就能在执行期间直接检索 Jira 议题、读取 Confluence 页面，并把结论写回极狐GitLab 的议题或合并请求里。

对应的自动化入口仍然是你熟悉的 CI：

# .gitlab-ci.yml —— 在流水线中触发一次 Agent 执行
trigger-sync-agent:
  stage: ai
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
  script:
    - echo "由定时任务触发需求同步 Agent"
    - curl --fail --silent --show-error \
        --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
        --request POST \
        "$CI_API_V4_URL/projects/$CI_PROJECT_ID/agent_sessions"

真正的数据读写发生在 Agent 会话内部，通过 MCP 工具完成，不需要你在流水线里硬编码任何 Jira 凭据——这正是把它交给平台托管的意义。

踩坑提醒

坑 1：以为是 GA 功能就上生产。 该功能的 Offering 标注为 JihuLab.com，状态是实验，且 18.10 中默认由功能标志 ai_catalog_mcp_servers 关闭。私有化部署实例目前不在支持范围内，别在设计方案里默认它有。

坑 2：以为能细粒度授权。 当前只能做到「Agent 关联整台服务器」，无法限制 Agent 只用其中某几个工具。如果外部服务器同时提供读和写工具，挂上去就等于把写权限也交出去了。

坑 3：断开后的残留引用。 从 18.11 起支持从所有关联 Agent 断开某台服务器，但不能只断开某一个 Agent。断开后，已有会话仍可引用此前取回的内容，只是不能再取新内容或执行新操作。审计时要考虑到这段窗口。

坑 4：拿内部自建服务顶上。 目录只接受已审核或合作伙伴的服务器，且必须是远程 HTTP 端点。把公司内网的 MCP 服务直接填进去，大概率在登记这步就被拒。

什么情况下别这么做

• 合规要求可审计到单次工具调用：目前无法按工具粒度授权与审计，金融、医疗等强监管场景建议先观望。

• 私有化部署环境：该功能当前仅面向 JihuLab.com。

• 对外部系统有写操作诉求但无法承担误写成本：Agent 的写入行为依赖模型判断，务必先在只读场景跑通。

• 外部系统本身没有稳定的远程 MCP 端点：只支持 HTTP 远程传输，stdio 类本地服务不在射程内。

FAQ

Q1：MCP 服务器和「外部 Agent」是一回事吗？

不是。外部 Agent 是把第三方 AI Agent 接入平台一起编排；MCP 服务器是让平台内的自定义 Agent 去调用外部系统提供的工具。前者接入的是「智能」，后者接入的是「能力」。

Q2：能不能让不同 Agent 用同一台服务器的不同工具子集？

不能。关联粒度是服务器级，挂上即全部可用。如果确实需要隔离，现实做法是准备多台服务器条目，分别关联给不同 Agent。

Q3：凭据安全怎么处理？

启用 OAuth 的服务器由平台完成授权并安全存储访问令牌；支持动态客户端注册时无需手工提供凭证。你不需要把第三方系统的令牌写进 CI 变量。

小结与下一步

MCP 服务器解决的是 Agent 的「最后一公里」：让它在不离开平台的前提下，读写真正存放业务数据的那些系统。它不是万能钥匙——实验状态、仅 SaaS、只支持 HTTP 远程端点、授权粒度粗——这些约束决定了它今天更适合做只读检索与信息汇总类场景。

想动手试，建议从 Context7 开始：无需认证，接上即可让 Agent 拿到版本匹配的官方文档片段，风险最低。相关的完整配置说明见 AI 目录中的 MCP 服务器。

想评估 Agent 智能体在你的研发流程里能落地到哪一步？ 可以先从一次需求同步的只读链路试起，再逐步放开写权限。欢迎在评论区留下你最想打通的外部系统，我们按场景补充配置示例。