Linear MCP: What It Does, What It Can't Do, and Where Its Limits Are
You're deep in Claude Code, mid-feature, and the work you just finished needs a ticket. Old way: alt-tab to Linear,...
You're deep in Claude Code, mid-feature, and the work you just finished needs a ticket. Old way: alt-tab to Linear, find the project, type it up, assign it, come back. New way: tell the agent to do it, and it does — same window, no context switch. That's the pitch for Linear MCP, and for coding-agent workflows it's a genuinely good one.
Before you connect it, it's worth knowing exactly what it does, where it stops, and one thing it's quietly bad at that people try to use it for anyway.
What is Linear MCP?
Linear MCP is Linear's official, hosted MCP server that lets AI tools read and write your Linear workspace through natural language. Linear launched it on May 1, 2025, at the endpoint https://mcp.linear.app/mcp — a remote server Linear runs and maintains, so there's nothing to install or self-host.
MCP — the Model Context Protocol — is the open standard that lets AI tools connect to outside systems. Linear's server implements it on top of Linear's own API, which means any MCP-compatible client can call into your workspace once you've authorized it. The context here isn't abstract: Linear is used by 20,000+ companies including OpenAI, Cursor, and Vercel, and the company reported crossing $100M in revenue in 2025. A lot of engineering teams live in Linear all day, which is exactly why connecting it to the AI tools they already use is appealing.
What can you do with Linear MCP?
You can find, create, and update the things you'd normally manage by hand in Linear — without leaving your AI tool. The server exposes tools for searching issues, creating and editing them, changing status and priority, posting comments, and querying projects and teams. Linear has since extended it to initiatives, milestones, and project updates, so the surface now reaches beyond individual tickets into higher-level planning.
Where it earns its place is the coding-agent loop. An agent working in your repo — Claude Code in the terminal, Cursor in the editor, Codex on a task — can hold the ticket and the code at the same time. It reads the issue to understand the ask, writes the change, then updates the ticket's status or files the follow-up bugs it found along the way. The agent that did the work also records the work, in the same flow, with no manual handoff.
That's the difference between Linear MCP and a chat toy. "Create a ticket from ChatGPT" is a party trick. "The agent that just shipped the fix moves the issue to In Review and comments the PR link" is a workflow.
How do you connect it?
You point an MCP-compatible tool at Linear's remote endpoint and authorize it over OAuth. Because the server is hosted, there's no Node process to run or token to paste into a config file for the standard path — you add the remote server, a browser window opens, you grant access to your Linear workspace, and the tool inherits your permissions.
It works with the tools most people are already running: Claude and Claude Code, Cursor, Codex, and other MCP clients. Each has its own way of adding a remote MCP server, but the shape is the same across all of them — add the URL, complete the OAuth handshake, done. If you've never wired up an MCP server before, the mechanics are the same for any of them: here's how connecting an LLM with MCP works.
Where are Linear MCP's limits?
The two limits worth knowing are write access and response size — one is about safety, the other about reliability.
Write access is the one to set up deliberately. Linear MCP doesn't just read your board; it can create and change issues, and an agent acting on your authorization can act badly on it — filing duplicates, editing the wrong ticket, reassigning work — as confidently as it does anything else. This is a general risk with write-capable MCP servers, and it's worth a moment of thought before you turn an autonomous agent loose on a shared workspace. Scope the token to what you need, and keep a human in the loop for destructive actions rather than assuming the model will get it right every time.
The second limit is structural: large responses. Coding agents cap how much a single tool call can return — Claude Code, for instance, rejects MCP tool responses over 25,000 tokens by default. Ask Linear MCP to list every issue in a busy project and the call can exceed that ceiling and simply fail. The fix is to query narrowly — specific issues, specific filters — rather than pulling large slices of your workspace in one shot.
Should you use Linear MCP as your AI's source of context?
No — Linear MCP is built to act on Linear, not to be the context your AI works from, and using it that way is both expensive and unreliable. This is the mistake worth catching before you make it.
Start with the token cost. Every MCP server loads its tool definitions into the context window before you type a single word, and they reload every turn. Linear's server exposes roughly two dozen tools; one analysis measured its definitions at about 17,300 tokens up front (Fiberplane, 2025), and a stack of GitHub, Linear, and Supabase together came in around 24,000 tokens of definitions before any real work (policylayer, 2026). That's the MCP context tax, and you pay it on every message.
Then there's accuracy. Tool-selection quality degrades as the number of available tools grows — research points to noticeable drop-off past roughly 50 tools, which is why teams like Block reportedly slimmed their internal Linear MCP server down to a handful of tools instead of exposing everything. Pile on the response-size ceiling from the last section, and the picture is clear: trying to reconstruct who you are, what your team standardized on, and what you decided last sprint by having the model query Linear live means paying schema cost every turn and risking calls that lose focus or fail outright.
There's a cleaner split. Linear MCP is a connector — it gives your AI a place to look and act. Your context — your role, your team's conventions, the decisions behind the current work — is something your AI should already know, loaded once and served consistently, not fished out of a project tool on every request. That's the difference between a connector, MCP, and a context layer: one gives the agent a data source; the other gives it a stable picture of who it's working with.
Connect Linear MCP for what it's genuinely great at — letting your coding agents file and update the work they're doing. Keep the context that makes those agents actually understand your situation somewhere built for the job.
Unabyss is that layer: one structured profile of who you are and how your team works, served to every AI tool over MCP, so the agent filing your Linear tickets already knows whose tickets they are.
