/ 目录 / 演练场 / Linear
● 官方 linear 🔑 需要你的密钥

Linear

作者 linear · linear/linear

让你的 agent 分类整理 Linear 待办事项、发布周期更新、以及从 Sentry 提交 bug —— 无需打开应用。

Linear 官方远程 MCP (SSE) 暴露了问题、项目、周期、团队、评论和用户。OAuth 由 Linear 处理,所以无需管理 PAT。最适合与 Sentry(自动提交 bug)、GitHub(链接 PR)和 Notion(周度报告)结合使用。

为什么要用

核心特性

实时演示

实际使用效果

linear.replay ▶ 就绪
0/0

安装

选择你的客户端

~/Library/Application Support/Claude/claude_desktop_config.json  · Windows: %APPDATA%\Claude\claude_desktop_config.json
{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.linear.app/sse"
      ]
    }
  }
}

打开 Claude Desktop → Settings → Developer → Edit Config。保存后重启应用。

~/.cursor/mcp.json · .cursor/mcp.json
{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.linear.app/sse"
      ]
    }
  }
}

Cursor 使用与 Claude Desktop 相同的 mcpServers 格式。项目级配置优先于全局。

VS Code → Cline → MCP Servers → Edit
{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.linear.app/sse"
      ]
    }
  }
}

点击 Cline 侧栏中的 MCP Servers 图标,然后选 "Edit Configuration"。

~/.codeium/windsurf/mcp_config.json
{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.linear.app/sse"
      ]
    }
  }
}

格式与 Claude Desktop 相同。重启 Windsurf 生效。

~/.continue/config.json
{
  "mcpServers": [
    {
      "name": "linear",
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.linear.app/sse"
      ]
    }
  ]
}

Continue 使用服务器对象数组,而非映射。

~/.config/zed/settings.json
{
  "context_servers": {
    "linear": {
      "command": {
        "path": "npx",
        "args": [
          "-y",
          "mcp-remote",
          "https://mcp.linear.app/sse"
        ]
      }
    }
  }
}

加入 context_servers。Zed 保存后热重载。

claude mcp add linear -- npx -y mcp-remote https://mcp.linear.app/sse

一行命令搞定。用 claude mcp list 验证,claude mcp remove 卸载。

使用场景

实战用法: Linear

如何在 10 分钟内整理混乱的 Linear 待办事项

👤 工程经理、技术主管 ⏱ ~15 min intermediate

何时使用: 周一上午。待办事项有 200+ 个未分类的问题,规划在一小时后进行。

前置条件
  • Linear 工作区访问权限 — 通过 mcp-remote 进行 OAuth —— 首个工具调用会打开浏览器授予权限
  • 团队 slug(例如 ENG — 查看任何 issue 标识符 —— 前缀就是你的团队 slug
步骤
  1. 拉取团队的所有未分类 issue
    列出 ENG 团队所有处于 'Triage' 状态或未设置优先级的 issue,创建于最近 30 天。返回 id、title、reporter 和描述长度。✓ 已复制
    → 包含足够上下文以分类的候选表格
  2. 按主题分类
    将这些分组为 4-6 个主题(bug / 基础设施 / 入职 / 性能 / 等)。对于每个集群,建议一个优先级和建议的项目。✓ 已复制
    → 带有理由的主题集群
  3. 应用决策
    对于每个集群,更新 issue:设置优先级、添加匹配的标签,移至 'Backlog' 状态。不要分配给任何人。✓ 已复制
    → N 个 issue 已更新,确认日志已记录

结果: 一个规划就绪的待办事项,分组和优先级明确,每个 agent 做的改动都有审计跟踪。

注意事项
  • Agent 根据「谁写过类似代码」将 issue 大量分配给错误的人 — 显式告诉它不要分配 —— 分配是人的决定,应该由人做
  • 免费层 Linear 在约 1500 请求/小时后限速 — 使用 issueBatchUpdate 批量更新(如果可用);否则保持分类运行在 500 个 issue 以下
搭配使用: sentry · github

从 Linear 生成周度周期状态报告

👤 工程经理、产品经理 ⏱ ~10 min beginner

何时使用: 周五下午,你需要为领导层写周度更新。

前置条件
  • Linear 中的活跃周期 — Linear > 你的团队 > Cycles —— 记下当前周期号
步骤
  1. 拉取周期统计
    对于 ENG 周期 47,列出所有 issue 并按状态分组。包括本周完成的、进行中的、阻塞的和有风险的(3+ 天未更新)。✓ 已复制
    → 按计数和 issue 标题分类的明细
  2. 与上周对比
    与上周的快照对比 [粘贴之前的 JSON]。什么发布了,什么退回到早期状态,什么新阻塞了?✓ 已复制
    → 带有叙述的增量
  3. 起草报告
    写一份一页的 Markdown 报告:成就、进行中、阻塞、需要帮助。保持诚实 —— 领导层会读懂言外之意。✓ 已复制
    → 报告已准备好粘贴到 Slack 或 Notion

结果: 一份精美的周期更新,10 分钟而不是 45 分钟。

注意事项
  • 完成的 issue 没有合并的 PR 看起来有进展但实际上没有 — 与 GitHub MCP 结合 —— 验证每个「完成」issue 都有引用的合并 PR
搭配使用: github · notion

从新 Sentry issue 自动提交 Linear bug

👤 轮值工程师 ⏱ ~15 min intermediate

何时使用: 你希望 Sentry 中的实时错误尖峰成为跟踪的 bug,无需手动复制粘贴。

前置条件
  • Sentry MCP 与 Linear 一起安装 — 参见 Sentry 指南获取设置
  • 一个专用 Linear 标签,如 from-sentry — Linear > Settings > Labels —— 创建一次
步骤
  1. 查找超过阈值的新 Sentry issue
    查找过去 24 小时首次出现且在 web-prod 项目中有 >50 个事件的 Sentry issue。✓ 已复制
    → 列出 issue ID 和事件计数
  2. 检查 Linear 中的重复
    对于每个 Sentry issue 标题,在 Linear 中搜索现有的 issue,标题相似或包含 Sentry URL。跳过已提交的。✓ 已复制
    → 去重列表 —— 仅真正新的项目
  3. 创建 Linear bug
    为每个新 Sentry issue 在 ENG 团队中创建一个 Linear issue:title = Sentry title,description = 堆栈跟踪 + 链接,priority = 如果 >1000 个事件则 Urgent 否则 High,label = from-sentry。✓ 已复制
    → N 个 issue 创建,返回链接

结果: 一个干净的 Linear bug 接收,永远不会漏掉生产错误。

注意事项
  • 同一个 Sentry issue 因标题漂移略有不同而被提交两次 — 在 Linear 标题中使用 Sentry issue 短 ID(例如 WEB-3a91)并在该子字符串上去重
搭配使用: sentry

轻推当前周期中的陈旧 issue

👤 技术主管、scrum master ⏱ ~5 min beginner

何时使用: 周期中期检查。分配了 5+ 天且没有状态变化的 issue 通常是卡住了。

步骤
  1. 找到陈旧的 issue
    列出当前 ENG 周期中在「进行中」5+ 天且无状态变化或评论的 issue。✓ 已复制
    → 列出负责人和陈旧天数
  2. 发布温和的轻推评论
    在每个上添加评论:「快速检查 —— 这周期仍在轨道上,还是你需要分解这个 / 获得帮助?」标记负责人。✓ 已复制
    → 评论已发布,返回链接
  3. 如果被忽视就升级
    48 小时后重新运行。如果仍无更新,给我发一份列表进行 1:1 跟进。✓ 已复制
    → 人工跟进的升级列表

结果: 解除阻塞的工作,无需每天都是唠叨的经理。

注意事项
  • 如果你每小时运行一次,评论会变成垃圾 — 在发布前检查 agent 是否已在过去 3 天评论过

从 Notion 规格单中构建 Linear 项目

👤 产品经理、启动新举措的技术主管 ⏱ ~20 min intermediate

何时使用: 你有书面的 PRD,需要将其分解为可跟踪的 issue。

前置条件
  • 安装了 Notion MCP — 参见 Notion 指南
  • PRD 页面 URL — 从 Notion 复制
步骤
  1. 读取并总结规格
    读取位于 <URL> 的 Notion PRD,将每个离散的交付物列为单行描述。✓ 已复制
    → 15-40 个候选 issue
  2. 审查并细化
    将这些分组为 3-5 个里程碑。标记任何需要设计、API 或 DB 工作的 issue 为单独的 issue。✓ 已复制
    → 结构化的 issue 树
  3. 创建 Linear 项目和 issue
    在 ENG 团队中创建名为「<规格标题>」的 Linear 项目。将每个里程碑创建为父 issue,子项为子 issue。在每个描述中链接回 Notion 页面。✓ 已复制
    → 项目 URL + issue 计数

结果: 一个完全支架化的 Linear 项目,20 分钟而不是 2 小时的手动写票工作。

注意事项
  • Agent 创建 80 个 issue,而你想要 20 个 —— 太细粒度 — 在第 2 步中明确上限:「不超过 20 个 issue 总数,合并任何小于一天工作的东西」
搭配使用: notion

组合

与其他 MCP 搭配,撬动十倍杠杆

linear + sentry

将生产错误尖峰自动转换为跟踪的 Linear bug

查找过去 24 小时内首次出现且在 web-prod 项目中有 >50 个事件的新 Sentry issue。对于每个,在 ENG 团队中创建一个 Linear bug,标签为 from-sentry,优先级为 High,描述包含堆栈跟踪。✓ 已复制
linear + github

自动链接 PR 到 Linear issue,PR 合并时关闭 issue

对于我的仓库中的每个开放 PR,在标题或分支名称中查找 Linear issue ID,并在 Linear issue 上添加带有 PR URL 的参考评论。✓ 已复制
linear + notion

将周度周期摘要发布到 Notion 数据库

生成本周 ENG 周期状态,并在 Notion「工程周报」数据库中创建包含完整报告的页面。✓ 已复制

工具

此 MCP 暴露的能力

工具输入参数何时调用成本
list_issues team?, assignee?, state?, label?, cycle?, query?, limit? 主要搜索 —— 过滤流 1 API call
get_issue id 获取单个 issue 的完整上下文 1 API call
create_issue teamId, title, description?, priority?, labelIds?, assigneeId?, projectId? 提交新 issue 1 API call
update_issue id, stateId?, priority?, assigneeId?, labelIds?, title?, description? 改变状态、优先级或分配 1 API call
create_comment issueId, body 在 issue 上发布轻推或状态备注 1 API call
list_projects teamId? 发现团队中的活跃项目 1 API call
list_cycles teamId 为团队查找活跃或最近的周期 1 API call
list_teams 发现工作区中的团队 1 API call

成本与限制

运行它的成本

API 配额
OAuth 应用 1500 请求/小时,120 请求/分钟突发 —— 对任何实际工作流都足够慷慨
每次调用 Token 数
根据描述/评论长度,每个 issue 300–1500 个 token
费用
免费 —— Linear MCP 包含在任何 Linear 计划中
提示
使用具有特定过滤器的 list_issues 而不是拉取所有内容再过滤 —— 在大型待办事项上减少 10 倍的 token 成本

安全

权限、密钥、影响范围

最小权限: read write issues:create
凭据存储: 通过 mcp-remote 的 OAuth —— token 存储在 ~/.mcp-auth/,无需重新登录即可刷新
数据出站: 所有调用到 api.linear.app 和 mcp.linear.app
切勿授予: admin

故障排查

常见错误与修复

OAuth 浏览器弹窗不打开

手动运行一次 npx -y mcp-remote https://mcp.linear.app/sse —— 它会打印一个 URL,你可以粘贴到浏览器中

验证: 认证后,重新运行你的 agent;token 缓存在 ~/.mcp-auth/
update_issue 返回 403

你的 Linear 角色缺乏对该团队的写入权限。要求工作区管理员升级你或将 agent 范围限制为你拥有的团队。

返回了 issue 但评论缺失

评论是单独查询 —— 使用 get_issue 并 include-comments,或使用 issue ID 单独列出评论。

找不到你知道存在的 issue

检查团队过滤器 —— 其他团队中的 issue 除非你传递 team=null 或指定该团队,否则不会返回。

替代方案

Linear 对比其他方案

替代方案何时用它替代权衡
Jira MCP你的组织使用 Jira,不是 Linear更重的 API,更多状态/字段需要推理 —— agent 在 Jira 上开箱即用表现更差
GitHub Issues(通过 GitHub MCP)你想要紧密耦合代码的 issue,无需单独的工具失去周期、项目和工作流状态 —— GitHub Issues 更简单但结构性更差

更多

资源

📖 阅读 GitHub 上的官方 README

🐙 查看未解决的 issue

🔍 浏览全部 400+ MCP 服务器和 Skills