What Does the Linear MCP Server Do?

The Linear MCP server lets an AI assistant find, create and update things in your Linear workspace: issues, projects and comments, and, since Linear widened it, initiatives and initiative updates, project milestones and project updates, project labels, documents, releases and release notes. It can load a Linear resource from its URL and read images. It works with the signed-in person’s Linear permissions, can be limited to read-only, and can also run as an app rather than as you. Linear does not publish a tool-by-tool reference, so the exact list of tools is whatever your client shows once it is connected.

This piece is about what the server can reach. For the install and sign-in in Claude Code, see Linear MCP with Claude Code. Everything below is taken from Linear’s MCP documentation, its developer documentation and its changelog.

What Linear says it does

Linear’s documentation↗ (opens in a new tab) describes the server in one sentence: it has tools for finding, creating and updating objects in Linear like issues, projects and comments, with more on the way. It is hosted and run by Linear, follows the authenticated remote MCP specification, and uses streamable HTTP at https://mcp.linear.app/mcp. The older /sse endpoint is a deprecated fallback that Linear is removing.

The documentation does not list tool names. Linear’s changelog↗ (opens in a new tab) fills in the picture, release by release. Read together, the objects an assistant can work with are:

• Issues: find, create and update them, including relationships between issues, which can now be removed as well as added.
• Comments on issues, including comments on archived issues.
• Projects, with their labels, milestones and project status updates.
• Initiatives and initiative updates, added in February 2026↗ (opens in a new tab) so product managers can keep plans current from tools such as Cursor and Claude.
• Documents, which can be listed and created under a team, and created or moved under an initiative or a cycle.
• Releases, release notes and which issues belong to a release.
• Customer needs, through a tool that saves a request and can record where it came from.
• Teams, including whether a team is private or retired, and read-only access to Linear Agent skills.
• Linear links and images. Paste a Linear URL and the server can load what is behind it.

Tool names, and why you should check your own

Some tool names appear in the changelog in passing, among them save_issue, save_project, save_document, save_customer_need, list_comments, list_projects, get_project, list_teams and get_team. Linear changes tools often, adds fields to their answers and fixes their behaviour in frequent small releases. A list copied from a blog, this one included, goes out of date. The reliable list is the one your client shows after you sign in: /mcp in Claude Code, the tools list in Cursor, or the app details in ChatGPT.

Two workflows in Linear’s own examples show the intended range. One turns a planning document into a project with issues, milestones and relationships. Another reads standup notes and comments on the matching issues. Both ask the assistant to show what it plans to change before it changes anything, which is a good pattern to copy.

What to ask it, object by object

Matching requests to the objects above keeps an assistant on ground the server actually covers. A few that fit:

• Initiatives: “Summarise the health of every project under the Payments initiative and draft an initiative update. Show it to me before posting.”
• Milestones: “From this spec, propose milestones for the Onboarding project and the issues under each. Do not create anything yet.”
• Releases: “List the issues in the next release that are not Done, and draft release notes from the ones that are.”
• Documents: “Create a team document for Platform with this week’s decisions, and link the issues they mention.”
• Comments: “Read every comment on ENG-231 and give me the open questions.”

Each of these reads first and writes only after you agree, which is the same shape as Linear’s own examples. If a request needs a tool your list does not have, the assistant should say so rather than improvise; asking it to list its Linear tools at the start of a session makes that more likely.

Whose permissions it uses

By default, yours. Linear’s developer documentation↗ (opens in a new tab) explains that its API treats the authenticating user as the actor, so what a token does appears to come from that user. The MCP server signs you in with OAuth, so an assistant can see and change what your Linear account can, and its edits carry your name. Linear offers three ways to narrow or change that:

• The read-only endpoint, https://mcp.linear.app/mcp/readonly, which only ever exposes read tools.
• The read scope on the standard endpoint. Linear says clients that request only read get read-only access, and the token cannot reach write APIs.
• Your own token in the Authorization: Bearer header. Linear says this can be a restricted API key (for read-only, one with only the Read permission), or an OAuth token that lets you use the server as an app user.

The third option is the interesting one. Linear’s OAuth actor authorisation, turned on with actor=app, makes the app itself the actor: issues, comments and status changes are performed by the app, not by the person who installed it. Linear says this is particularly useful for agents and service accounts. It takes building a Linear OAuth application, so it is a developer’s route rather than a setting.

What admins control

• Enterprise-managed authorisation. On Enterprise workspaces that use Okta, admins can have supported MCP clients, with Claude named in Linear’s announcement, sign members in through Okta, with their existing Linear permissions and without each person authorising Linear.
• Active connections. Linear’s changelog refers to an Active MCP connections view in the workspace’s security settings.
• The usual Linear permissions. Because the server acts as the user, private teams and anything else a member cannot see stay hidden from their assistant.

Gaps and edges

• No published tool reference. You cannot check, before connecting, whether a given action exists. Connect read-only first and read the tool list.
• Deleting is not documented. Linear describes finding, creating and updating; its changelog mentions removing issue relationships and seeing whether a project is trashed, but not deleting issues. Do not plan around a delete tool without seeing one in your list.
• Settings are not described. Nothing in Linear’s MCP documentation covers workflows, team settings, integrations or members. Treat workspace administration as out of scope unless your tool list says otherwise.
• One workspace per sign-in. Linear says each workspace needs its own authentication, so two workspaces means two connections.
• Your name on its work. Unless you set up an app actor, an assistant’s changes are indistinguishable from yours in Linear.

Linear MCP is not Linear Agent

The names are easy to confuse. The Linear MCP server lets outside assistants such as Claude, Cursor or ChatGPT work inside Linear. Linear Agent is Linear’s own assistant, and since April 2026 it can connect outwards to other MCP servers↗ (opens in a new tab), such as Notion or PostHog, to pull context in. The first is Linear as a server, the second is Linear as a client.

A smaller board with an assistant on it

Linear’s server reaches a lot, because Linear plans a lot: cycles, projects, initiatives and releases. If your team works one list, fenbs keeps the assistant’s reach small on purpose: it connects over MCP with a browser sign-in, works under your role narrowed by the scopes you tick, and every change is signed with its name, such as “Claude via Sam”. See fenbs vs Linear for a fair comparison.