# Linear MCP Server Permissions & Controls, Explained

How the hosted Linear MCP server's controls actually work — the dedicated read-only endpoint at /mcp/readonly, the read OAuth scope, restricted API keys, Okta enterprise-managed auth — and what still doesn't exist below them.

# 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](/mcp-controls/notion) 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](https://linear.app/docs/mcp) and [changelog](https://linear.app/changelog).

*This page covers the server's own controls. For the cross-server picture, see [the MCP server controls comparison](/mcp-controls); for what a control layer adds on top, [the coverage matrix](/coverage).*

## 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](https://linear.app/docs/mcp) "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](/mcp-controls/github) 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](https://linear.app/docs/mcp) (shipped [July 2026, extended August 2026](https://linear.app/changelog)): 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](/mcp-controls/notion) 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](/blog/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](/what-is-an-agentic-control-plane), because past that URL swap, the server's answer to every call is yes.