Linear MCP for Product Management Workflows

For a product manager, Linear’s MCP server is most useful for four recurring jobs: triaging what lands in a team’s Triage inbox, turning requests from calls and threads into well-formed issues, summarising what a cycle actually delivered, and drafting project and initiative updates. Three of them can run on the read-only connection; only writing requests up has to create things. Each has one point where a person must look before anything changes: the triage decision, the issue before it is created, the figures before a summary is shared, and the health status on an update. Set the access per job, not once for everything.

This piece is about the workflows. Installing the server is covered in Linear MCP with Claude Code and Linear MCP in Cursor, and the full list of what the server can reach is in what the Linear MCP server does. Everything below works in any client that can connect to it.

First, pick the connection for the job

Linear offers two ways to keep an assistant read-only, according to Linear’s MCP documentation↗ (opens in a new tab): the https://mcp.linear.app/mcp/readonly endpoint, which exposes only read tools, or the standard endpoint with only the read OAuth scope granted. Clients such as Claude Code and Cursor let you add the server twice under different names, so a sensible product setup is two connections side by side:

• linear-readonly for everything that summarises, compares or proposes. Leave it on.
• linear on the read-write endpoint for the moments you want the assistant to create or change something. Switch it on for that, and keep its write tools on approval in your client.

Either way the assistant signs in as you, so it sees what your Linear account sees and its edits carry your name. That shapes the review points below: nobody reading the issue later can tell your change from the assistant’s unless you make it visible.

Workflow 1: triage of new issues

Triage in Linear↗ (opens in a new tab) is a team’s inbox: issues created by integrations such as Slack or Sentry, or by people outside the team, land there before they join the workflow. The person on triage accepts, declines, marks as a duplicate or snoozes each one. That decision is the part to keep. What an assistant can take off your plate is the reading.

List the issues in the Payments team's Triage.
For each one, give me:
- a one-line summary in plain words
- likely duplicates among open issues, with their IDs and why
- your suggestion: accept, decline, duplicate or snooze, and the reason
- missing information the reporter should be asked for
Do not change anything.

You then go down the list in Linear and act on it yourself, which is fast: Linear’s own shortcuts are 1 to accept, 2 to mark as a duplicate and 3 to decline. The assistant did the searching and comparing, and the call stays with the person who owns the team’s intake.

• Access: read-only is enough for the suggestion list.
• Where review sits: every accept, decline and duplicate. A wrong decline closes a real bug quietly; a wrong duplicate merges two different problems.
• If you do let it write: limit it to adding a comment asking the reporter for the missing detail, and approve each one.

Linear also has its own Triage Intelligence on some plans, which suggests properties and duplicates inside Linear. An assistant over MCP is different in one useful way: it can compare the issue against things Linear cannot see, such as the code in your repository or the notes open in your editor.

Workflow 2: writing requests up as issues

Requests arrive as a call transcript, a long Slack thread or a support ticket. Turning them into issues engineers can act on is slow, careful writing, and it is where an assistant saves the most time. It is also a write, so the pattern is draft first, create second.

Here are my notes from today's call with the finance team (pasted below).
1. Search Linear for open issues that already cover any of these requests.
2. For each request that is new, draft an issue: title, the problem in the
   customer's words, who asked, and what "done" would look like. No solution.
3. Show me the drafts and the matches. Create nothing until I say which.

The search step matters as much as the drafting. A product backlog fills with near-duplicates when every request becomes a new issue. Where a request is already covered, the better move is to attach the new evidence to the existing issue. Linear models this as customer requests↗ (opens in a new tab), which link feedback to issues and projects with a link back to its source, and its changelog records a save_customer_need tool on the MCP server that can store that source address.

• Access: read-write, switched on for the step where you approve the drafts.
• Where review sits: the list of drafts, before creation. Check the problem statement is the customer’s, not a solution the assistant invented.
• A habit worth keeping: have it end each description with a line such as “Drafted with an assistant from call notes, 27 Sep”, so the issue says where it came from.

Workflow 3: cycle summaries

Summarising what a team completed during a cycle is one of the example workflows Linear itself publishes for its server. It is a pure read, so it belongs on the read-only connection, and it is the easiest of the four to trust quickly.

Summarise the Platform team's last completed cycle for the leadership update.
- What shipped, grouped by project, in plain language.
- What rolled over, and for each one whether it was blocked, re-scoped or just late.
- Anything added mid-cycle.
Give me issue IDs for every claim so I can check them.

One detail catches people out. Linear’s cycles documentation↗ (opens in a new tab) says completed cycle graphs are kept as snapshots from when the cycle closed, while the issue list on the cycle page can still change afterwards as issues are reopened or moved. Open issues also roll over into the next cycle automatically. So a summary built from today’s issue list can disagree with the cycle graph, and both can be right. Ask for issue IDs, as above, and the disagreement becomes something you can check rather than something you have to explain in a meeting.

• Access: read-only.
• Where review sits: the numbers and the “why it rolled over” judgements, before the summary leaves your hands.

Workflow 4: project and initiative updates

Tools to create and edit project updates, initiative updates, milestones and initiatives were added in Linear’s February 2026 release for product management↗ (opens in a new tab), so product managers could keep plans current from tools such as Cursor and Claude. This is the workflow with the most visible output: updates are read by people who never open the issues.

Each update in Linear carries a health, On track, At risk or Off track, and Linear’s updates documentation↗ (opens in a new tab) describes reminders that nudge project leads to post weekly or every two weeks. The health is the part an assistant should never set on its own. It can count issues and read comments; it cannot know that the one open issue is the one the launch depends on.

Draft this week's update for the Onboarding revamp project.
- Progress since the last update, from issues completed and comments.
- Risks: open issues past their target, blocked issues, scope added.
- Milestones: which are on course and which are not, with dates.
Leave the health blank and tell me what you would pick and why.
Do not post it. I will set the health and post it myself.

• Access: read-only for the draft; read-write only if you want it to post the text after you have edited it and chosen the health.
• Where review sits: the health status and any sentence about a date. Both are commitments made in your name.
• For initiatives, the same shape one level up: draft from the projects under the initiative, and let the owner choose the health.

The same approach extends to roadmap work. Linear’s examples include turning a planning document into a project with issues, milestones and relationships. Ask for the proposed structure as a list first, correct it, and only then let it create anything. Undoing forty issues created in the wrong shape is slower than reading one list.

The four at a glance

• Triage: read-only. A person accepts, declines or merges every item.
• Writing up requests: read-write, on approval. A person approves each draft before it becomes an issue.
• Cycle summaries: read-only. A person checks the figures before sharing.
• Project and initiative updates: read-only to draft. A person sets the health and posts.

The pattern underneath is the same each time: the assistant reads widely and proposes; a person makes the call that someone else will rely on. For a wider view of where people should step in, see human in the loop for AI agents.

When the team is smaller than the tooling

Linear suits product teams that run cycles, projects and initiatives. If yours is one list of work, fenbs is a simpler board where an AI assistant is a member in its own right: it connects over MCP with a browser sign-in, holds your role narrowed by the scopes you tick, and every change it makes is recorded as, for example, “Claude via Sam”. Tasks keep the problem and the plan apart, and choices that outlast a task go on the board’s Decisions page, where an assistant can write a decision down but only a person can make one.