Skip to content
Agentic Control Plane

The Linear MCP server control model, explained

The Linear MCP server is first-party and hosted: https://mcp.linear.app/mcp (Streamable HTTP, with a deprecated /sse fallback), OAuth 2.1 with dynamic client registration, centrally managed by Linear. It matters to this series for one specific reason: it’s the server that shipped the control its closest sibling lacks. Notion’s hosted server has no read-only mode in any spelling; Linear ships a dedicated read-only endpoint — a different URL that only ever serves read tools. Same product category, opposite choice. Source for everything below: Linear’s MCP docs and changelog.

This page covers the server’s own controls. For the cross-server picture, see the MCP server controls comparison; for what a control layer adds on top, the coverage matrix.

What’s at stake on this surface

Linear’s docs describe the tool surface generally — “finding, creating, and updating objects in Linear like issues, projects, and comments” — rather than enumerating tools, though the changelog names some of the grain: list_comments, save_customer_need, project status updates, document creation, release management. So the write risk is moderate and mostly recoverable: an agent with write access can mass-change statuses, misassign issues, spam comments, and rewrite project updates — noisy and trust-eroding rather than destructive. The read side is the roadmap: what’s being built, what’s slipping, what customers asked for. That’s competitively sensitive, though less PII-dense than a Notion workspace. And issue descriptions and comments arrive from other people, which makes them a prompt-injection carrier like every shared-content surface in this series.

Auth: OAuth, tokens, and the user’s full permissions

Interactive setup is OAuth 2.1 with dynamic client registration; the server conforms to the authenticated-remote MCP spec. Clients can also pass a Linear API key or OAuth token directly via Authorization: Bearer. Either way, the grant is the authenticated user’s existing Linear permissions — there is no documented way to narrow a connection to a team, a project, or a set of issues. Because the server is hosted, enforcement of everything below happens on Linear’s side of the wire — a structural advantage over local servers, where the controls run on the same machine as the agent they constrain.

The read-only endpoint: posture as a URL

The centerpiece. Linear serves a second route, https://mcp.linear.app/mcp/readonly, which per the docs “only ever exposes read tools.” Two more spellings of the same posture exist: requesting only the read OAuth scope on the standard endpoint — where the docs are explicit that “the underlying token can’t reach write APIs,” blocked at the token, not just hidden from the tool list — and creating an API key with only the Read permission enabled.

Grade it honestly: this is the best read-only UX in the series. GitHub’s read-only is real but takes three spellings of client-side configuration — a flag, an env var, a header — each a thing to remember and each invisible in a quick glance at a running session. Linear’s version is a URL. The posture is legible at a glance in any client config, there is no flag for an agent to quietly drop from its own arguments, and the server decides what the route serves — a write tool never appears on /mcp/readonly no matter what the client asks for. One precision the docs force on us: the explicit token-level “can’t reach write APIs” claim is stated for the read OAuth scope, not separately for the readonly route; what the docs commit to for /mcp/readonly is that it never exposes write tools. And one honest limit: the endpoint choice still lives in client config. An agent that can edit its own MCP config can point at /mcp instead — that swap is at least conspicuous, and a fresh connection has to be authorized, but “which posture” remains a line in a file on the agent’s machine.

The Enterprise plane: Okta-managed access

For Enterprise workspaces with Okta SAML, Linear supports enterprise-managed authorization (shipped July 2026, extended August 2026): admins enable MCP enterprise-managed authentication in Linear’s identity provider settings, supply the Okta issuer URI, and employees connecting through a supported client are verified through Okta — “Admins can manage access centrally, without requiring employees to sign in or authorize Linear individually,” with each user’s existing Linear permissions applied. Same altitude as Notion’s Enterprise controls: it answers who connects, through which identity — a real control, worth turning on — and answers nothing about what any connected agent then calls.

What isn’t there

The rest of the native surface, checked against the docs and changelog:

  • No tool filtering or toolsets. The one selectable surface is read versus read-write. No per-tool selection, no way to allow issue writes but not project writes.
  • No team or project scoping. The connection carries the user’s whole permission set; the finest documented grain below “everything” is “everything, read-only.”
  • No per-call policy or approvals. No mechanism holds a write for a human or distinguishes one create_comment from a hundred.
  • No documented audit. The docs and changelog are silent on MCP-level logging; there is no documented record of which tools fired with what arguments — the general MCP audit gap, again.

Where the native model ends

The Linear model is one clean, server-enforced binary — read or read-write — plus identity administration above it. That binary is genuinely well built: enforced server-side, expressible as a URL, backed by a scope the token can’t exceed. But it’s still a single launch-time decision. The moment an agent legitimately needs to write — triaging issues, posting updates — you’re on /mcp, and every control this page described is behind you: full-permission writes across everything the user touches, no approval path, no call-level policy, no record.

The practical posture: default to https://mcp.linear.app/mcp/readonly (or a Read-only API key) for anything that only needs to look; on Enterprise, put connections behind Okta-managed auth; and treat the switch to the write endpoint as the moment the native model has said everything it has to say — per-call policy on writes, approval on the destructive ones, and a record of what actually ran have to come from a layer the agent can’t edit, because past that URL swap, the server’s answer to every call is yes.