Linear AI 工作流实操：MCP 配置、权限与团队协作

Linear MCP 服务器地址与身份验证怎么配置？

通过 Streamable HTTP 连接 https://mcp.linear.app/mcp，即可访问托管服务器。交互式配置采用支持动态客户端注册的 OAuth 2.1，负责客户端注册和用户授权。也可以在 Authorization: Bearer <yourtoken> 中传入 OAuth 令牌或 Linear API 密钥。Linear MCP 配置说明

可以把 MCP 理解为一个统一的服务窗口。助手按名称请求某项操作，比如查找任务或保存修改，Linear 服务器再根据连接权限执行。提示词表达的是你的意图，并不会额外赋予权限。

这些都是限制连接能力的不同办法。在提示词里说“不要修改”，只是对助手提出要求；只读端点或凭据则会限制它实际能做什么。Linear 访问权限选项

团队常用客户端如何连接 Linear MCP？

Claude 与 Claude Code

在 Claude 网页版或桌面应用中，打开 Settings → Connectors（设置 → 连接器），连接 Linear。这是 Linear 的 Claude 集成页面给出的操作路径。

Claude Code 的配置步骤如下：

1. 在终端运行 claude mcp add --transport http linear-server https://mcp.linear.app/mcp。
2. 打开一个 Claude Code 会话。
3. 运行 /mcp，完成身份验证流程。

命令及后续操作均来自 Linear 的 Claude 配置说明。

Cursor

Linear 的主指南提供了安装链接，并提示到 Cursor 的 MCP 工具页面查找 Linear。可使用 Linear 文档中 Cursor 部分的安装入口。

专门的 Cursor 集成页面还提供了手动配置方法：

1. 按 Ctrl/Cmd + Shift + J 打开 Cursor 设置。
2. 选择 MCP。
3. 选择 Add new global MCP server（添加全局 MCP 服务器）。
4. 添加以下配置：

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

这里使用的 mcp-remote 负责桥接客户端与托管服务器。以上配置出自 Linear 的 Cursor 集成页面。

Codex CLI 与 IDE 扩展

Linear 说明，CLI 与 IDE 扩展共用 MCP 配置。

1. 运行 codex mcp add linear --url https://mcp.linear.app/mcp。
2. 按配置指南所述，完成 Linear 登录提示中的操作。
3. 如果选择手动配置，Linear 要求先编辑 ~/.codex/config.toml，再运行 codex mcp login linear 完成身份验证。

复制配置前，需要留意文档中的一处不一致：

专门集成页面给出的手动服务器配置项为 [mcp_servers.linear]，其中包含 url = "https://mcp.linear.app/mcp"。这里按原文保留了这些设置，但两处功能开关相互冲突，不应把它们视为当前所有配置都必须满足的前提。Linear 的 Codex 集成说明、MCP 主指南

建议采用上面的添加服务器、登录授权流程。OpenAI 当前的 MCP 指南介绍了 HTTP 服务器配置和 codex mcp login <server-name>，并未要求启用上述任一功能开关。OpenAI 官方 MCP 文档

ChatGPT

按 Linear 文档实际给出的方式连接：

1. 使用 Linear 的 ChatGPT 集成页面中的链接，打开 ChatGPT 连接器设置。
2. 连接 Linear。
3. 在深度研究中将 Linear 添加为信息来源。

Linear 将这种连接描述为引用任务、项目和讨论的方式，同时保留用户现有的权限。该配置没有记录创建或更新任务的能力。可以用它做研究和总结；下文的编辑示例则应使用文档明确支持写入的 MCP 客户端。这里区分的是这一种连接方式，并非对所有 ChatGPT 集成一概而论。

Linear 公开列出了哪些 MCP 工具？

理解这些工具，关键是分清“获取上下文”和“保存修改”。下表保留了 Linear 已发布的常用工具清单中的准确标识符，并列出用途。这份清单位于 Slack 集成页面，介绍的是如何将同一个 Linear MCP 服务器连接到 Slackbot。Linear 工具清单

Linear 的更新日志还列出了 list_cycles、list_issue_labels、list_comments、save_project 和 save_document。文档说明的能力包括获取迭代周期详情、分页获取标签和评论、修改项目，以及在计划或迭代周期下创建文档或调整文档归属。这些是公开文档中列出的相关工具，并不意味着每个客户端都会暴露一套完全相同、数量固定的工具。迭代周期和标签工具、评论工具、项目和文档工具

旧示例可能会分别调用 create_issue 和 update_issue。Linear 已将它们合并为 save_issue。复制旧提示词或围绕工具名称开发时，要留意这一变化。Linear 工具变更说明

连接能访问什么，管理员又能控制什么？

应把这个连接视为访问工作区数据的一条授权通道。在 Linear 的 OAuth 术语中，read 指“用户账户的读取权限”，write 指“用户账户的写入权限”。默认的用户身份模式，会以授权该应用的用户身份创建资源。Linear OAuth 权限说明

对于 API 密钥，Linear 的表述是“可完全访问该用户能够访问的数据”，同时允许限制权限和团队范围。因此，受限密钥与授权范围宽泛的个人密钥，在能力上有实质区别。API 密钥权限

具体控制方式取决于连接采用哪种身份验证方式：

Linear 将应用审批的目的描述为控制“哪些应用可以访问工作区及其数据”。成员可在安装过程中申请批准。密钥管理措施适用于 API 密钥身份验证，不能替代对 OAuth 应用连接的管理。应用审批、API 管理

对于受支持的 Anthropic 客户端，使用 Okta SAML 的 Enterprise 工作区可采用企业统一管理的授权。Linear 表示，这种方式会“沿用其现有的 Linear 权限”。管理员通过 Okta 管理访问，无须让用户为每个连接单独授权。企业统一管理的授权

如果流程只需要汇总状态，就选择只读权限。如果要分流任务或创建任务，则授予所需的写入权限，并在执行前展示拟议修改。这里的审核步骤是工作流程建议，并不意味着所有客户端都会强制采用相同的审批机制。

值得先落地的三种 Linear AI 工作流

可以先做迭代周期报告，因为它不需要写入操作。如果新任务处理重复性高，下一步再做任务分流。当负责人花大量时间把已经确定的决策整理成任务时，需求文档转任务也值得尝试。

下文均为虚构的完整示例，用来展示提示词和预期交付内容，并非登录账户后实测所得的结果。

先把新任务整理成可审核的分流建议

工程负责人可以让助手检查新反馈、检索相似的现有任务，再集中提出修改建议。这样能减少重复搜索和字段编辑，同时仍由负责人决定任务归属和优先级。

输入示例： 新反馈“导出按钮卡住”描述了浏览器在按筛选条件导出时失去响应。已有任务“筛选后导出一直无法完成”提到了同一个界面。另一条反馈“邀请邮件一直收不到”没有投递日志，也没有复现步骤。

提示词：

有用的建议结果应当像这样：

审核后，负责人可以只授权通过 save_issue 执行已经认可的标签和负责人变更，暂不修改仍有疑问的反馈。助手应返回受影响任务的链接，以及变更字段的记录。相关读取和保存操作均列在 Linear 工具清单中。

在自建分流系统前，先与 Triage Intelligence 做比较。Linear 已经提供属性建议，以及重复任务和关联关系检测。只有当决策需要原生流程之外的上下文或规则时，自定义 MCP 编排才更有意义。Triage Intelligence

把需求文档拆成任务，但不擅自补需求

创始人可以先将已批准的功能说明转成任务草稿，审核后再在 Linear 中创建任务。这样做的价值在于一致性：每个任务都能追溯到对应需求，尚未确定的决策也不会被掩盖。

需求示例：“工作区管理员可以通过电子邮件邀请成员。受邀者通过邮件中的链接接受邀请。管理员可以撤销尚未接受的邀请。本次不涉及计费变更和批量邀请。”

提示词：

建议的任务拆分：

待决问题： 如果该邮箱已经属于现有成员，该如何处理？邀请会过期吗？邀请撤销后，受邀者应看到什么？在产品负责人作出决定前，这些都应保留为问题。

方案获批后，助手可以创建父任务和子任务，返回对应 URL，并指出未能创建的条目。创建子任务是文档明确记录的 MCP 能力。Linear MCP 更新说明

助手负责把需求整理录入，产品决策仍由产品负责人作出。

根据迭代周期中的任务起草周报

负责人可以让助手把迭代周期中的工作整理成进展草稿，并为每项陈述附上依据链接。这样，从分散的任务更新到一份可核查的报告，所需步骤会更少。

周报与迭代周期总结可能覆盖不同的时间范围。应明确指定团队、迭代周期和报告时间窗口，避免把“本迭代周期已完成”悄悄写成“本周已完成”。

原始材料示例：“邀请邮件”在报告时间窗口内被标记为已完成。“接受邀请”仍处于进行中。“撤销邀请”的一条评论说明，实现工作正在等待产品方决定邀请撤销后点击链接的体验。

提示词：

草稿示例：

实际草稿中的每句话都应附上对应任务的 URL。这个示例刻意没有给出完成百分比，也没有声称功能已经发布。读取迭代周期、任务和评论，就能为这一流程提供所需材料。迭代周期和任务工具、评论读取

这些流程稳定后，还能做什么？

创建评论是服务器文档明确记录的能力，项目工具则能为交接提供上下文。服务器能力、项目工具

值不值得用？把审核时间也算进去

受影响的是工程协作成本。没有 MCP 时，负责人需要查找、复制、核对和整理信息。接入助手后，负责人仍需界定任务范围、审核结果、纠正错误。

可以代入自己的成本，用下面的公式判断是否划算：

净价值 =（人工准备时间 − 助手辅助下的准备、审核和纠错时间）× 每小时综合人力成本 − 新增客户端与运行成本。

一份排版漂亮、却需要更久才能核实的报告，并没有为团队节省时间。比较两种流程时，应保持报告范围一致，也要计入错误修改后的修复成本。真正值得追求的是：每得到一份可接受的结果，所需的协调工作更少。

订阅方案可参考 Linear 价格。如果还没有确定使用哪款任务管理工具，可阅读 Linear 与 Jira 对比。最佳 MCP 服务器指南则介绍了其他相关连接。

围绕 Linear MCP，哪些方向值得做成产品？

最值得先尝试的是迭代进展报告起草服务。 如果报告格式稳定、遵守团队访问边界、区分已完成和未完成工作，并附有任务依据，工程负责人可能愿意付费。最小可用版本只需保存报告定义、获取相关迭代周期数据，并生成可编辑草稿。定时执行、重试和交付则由你的应用负责。

难点在于做出差异：通用的总结提示词很容易复制。可能形成产品价值的，是公司的报告规则、来源追溯和审核流程。在开发独立订阅产品前，先确认团队是否反复被这些细节困扰。

自定义任务分流审核队列，是一个更聚焦的方向。 平台团队或支持工程团队的负责人，可能愿意为这样的能力付费：将 Linear 任务上下文、自有分派规则，以及另行授权的客户支持上下文结合起来。最小版本应展示建议的字段变更和依据，提供批准或跳过的操作，再执行获批的修改。

难点是它会直接与 Linear 原生的 Triage Intelligence 竞争。只有当额外上下文或规则能够改变某项决策，而原生系统又无法充分满足该团队的需要时，才值得开发。这些是产品假设，并非已经验证的客户成果。

Linear MCP 的能力边界在哪里？

MCP 让助手能够调用操作，但不会替你澄清模糊需求，也不会让不完整的任务数据自动变得可靠。一个被标记为已完成的任务，可以支持对该任务状态的描述，却不能单凭这一点证明客户已经用上了相应功能。

同样，授权访问 Linear，并不等于授权访问任务中提到的所有文档、代码仓库或客户支持系统。如果你的应用还需要这些来源，就要分别设计访问和数据获取路径。

新配置请使用 /mcp。Linear 已将 /sse 标为弃用的备用方式。较早的 jerhadf 社区服务器也明确说明已弃用、不再维护，并引导用户使用 Linear 官方服务器。当前端点使用说明

下周一就可以这样开始：请工程负责人明确团队、迭代周期和报告时间窗口，先用只读权限起草一份进展报告。对照链接中的任务核查每项陈述，并比较新旧流程的准备工作量。等团队建立了清晰的审核惯例，再扩展到写入操作。

如果你希望按团队规则搭建这些工作流，我们可以开发 AI 自动化方案。