Does the Linear MCP server need a human-approval guard?

Mostly no. The official Linear MCP server is a read-and-triage surface — search, read, create and update issues, projects and comments — with no delete or archive tool found, and its mutations are largely reversible. A guard's strongest pitch, a hard stop before an irreversible action, has little target here. Its real value is on bulk operations and on notification-emitting actions like comments, whose downstream effects can't be recalled.

Can the Linear MCP server delete an issue?

No delete or archive tool was found in Linear's official docs or in third-party introspection of the server. Even in Linear itself, archiving is fully reversible and deletion is a soft, 30-day recoverable trash before permanent removal — so the irreversibility that would justify a guard is largely absent.

MCP field guide / Linear

// mcp field guide · project management

Linear MCP server

Another honest one. Linear's official server is a read-and-triage tool — find, create, and update issues, projects and comments — with no delete or archive tool exposed, and mutations that are largely reversible. Our strongest pitch, "a hard stop before something irreversible," has little to stop here. So we'll tell you where a guard actually helps.

Maintainer: Linear (official) Endpoint: mcp.linear.app/mcp · OAuth 2.1 Read-only: /mcp/readonly endpoint

GUARD FIT · READ + MUTATE

LOW

Search/read is inert; create/update issues, projects and comments are reversible (re-assign, re-label, reopen). No deletes to catch.

GUARD FIT · BULK + NOTIFICATIONS

SELECTIVE

Mass create/update/close is hard to unwind by hand; a posted comment or status change fires notifications that can't be recalled.

Overall fit: WEAK → MODERATE — no destructive surface; value is blast-radius and external visibility, not "undoing deletes."

What it is

Linear's official MCP server (by Linear, an independent company — not Anthropic) is a hosted remote at mcp.linear.app/mcp (OAuth 2.1). It launched May 2025 and expanded in Feb 2026 (initiatives, milestones, project updates/labels). It's task-completion-oriented — curated tools rather than raw GraphQL — so writes usually require reading context first. A read-only endpoint (/mcp/readonly, or requesting only the read scope) is documented.¹²

Tools by risk surface

Linear describes capability categories in its docs but does not publish a canonical named tool list; the specific identifiers below come from third-party introspection and should be read as reported, not officially published (and the set has grown since).⁴

Risk	Tools (reported)
read-only	`list_issues`, `get_issue`, `list_projects`, `list_teams`, `list_users`, `list_comments`, `list_cycles`, `list_documents`, `search_documentation`
mutating	`create_issue`, `update_issue` (status/assignee/priority), `create_comment`, `create_project`, `update_project`, `create_issue_label` (+ Feb-2026 initiative/milestone tools, exact names unverified)
destructive	none found — no `delete_` or `archive_` tool in the official server's docs or introspection

Recoverability, even if a delete existed: in Linear itself, archiving is fully reversible (restore anytime, no expiration) and deleting is soft — items sit in "Recently deleted" and are recoverable for 30 days before permanent removal. So the irreversibility that justifies a guard is doubly absent on this server today.

Real use cases

IDE-native dev flow. From Cursor/VS Code/Claude, search assigned issues, read context, update status/assignee, post progress comments.

Issue capture. Turn a chat or spec into a well-formed Linear issue with the right team, labels, and project.

Standup rollups. List issues, cycles and projects to summarize sprint status.

Where a human-approval guard fits

Plainly: the guard's value here is limited, and worth saying so.

Reads → nothing to gate. Search/list/get/summarize don't mutate.
Mutations → mostly reversible. Create/update issue, project, comment can be re-assigned, re-labeled, or reopened. The textbook "MODERATE, reversible" case — per-action approval is usually overkill.
No deletes → the strongest pitch has no target. On the official mcp.linear.app server there's no irreversible action to hard-stop, and even native Linear delete is a 30-day recoverable trash. (Separate community Linear MCP servers may add delete_issue/archive_issue — if you run one of those, gate the deletes.)

Where a guard does earn its place:

Bulk mutations. An agent looping create/update across many issues (mass re-label, mass close) is hard to unwind by hand even if each step is individually reversible — batching-with-approval is the real value.
Notification-emitting actions. create_comment and status changes can fan out to Slack, customer-request threads, or external automations. Those emitted notifications are effectively irreversible even though the Linear object isn't — the honest place to require approval.

The honest framing: a guard on Linear should be scoped to writes — especially comments and bulk operations — left out of the read path, and pitched on blast radius and external visibility, not on "undoing deletes," because there are none to undo. Right-sizing the control is the whole point of this guide.

Right-sized, again

ChronoMCP passes reads and one-off edits through, and gates bulk operations and notification-emitting actions — no theater on a low-risk server.

Read the quickstart → More MCP profiles

Sources

Linear — official MCP docs (endpoint, auth, capabilities): linear.app/docs/mcp
Linear — MCP launch changelog: linear.app/changelog/2025-05-01-mcp
Linear — delete vs. archive / recoverability: linear.app/docs/delete-archive-issues
Independent introspection of the server's tool set (reported names): blog.fiberplane.com/blog/mcp-server-analysis-linear

Profiles describe third-party software from its public sources; ChronoMCP is not affiliated with Linear. Exact tool names are third-party-introspected, not officially published, and the set has grown since; risk groupings are our classification. Capabilities reflect sources current as of Aug 2026 — check the source links.