NC vs Linear MCP

Linear ships its own MCP server. Nexus-Catalyst also talks to Linear. This page is about which one to connect, and when it’s worth having both.

The short version: if you work in one Linear organization and want the fullest coverage of Linear’s API, use Linear’s MCP. If you work across two or more Linear organizations in the same conversation, or you want issues tied to the memory of how they were solved, use Nexus-Catalyst.

We are not trying to match Linear’s MCP feature for feature

Linear’s server is first-party. It tracks their API as it changes, it covers more of it than we do, and it will keep doing both. Nexus-Catalyst implements the slice of Linear that an assistant needs while it is working — reading and writing issues, projects, labels, comments and statuses — and does not attempt parity. Documents, cycles, initiatives, triage, attachments and the rest of Linear’s surface are theirs.

If Linear’s MCP does what you need, use it.

What Nexus-Catalyst does differently

One connection, several organizations

Linear’s documentation is explicit that an authenticated session is scoped to a single workspace: reconnecting alone does not switch it, and each workspace needs its own authentication context. That’s a reasonable design — it’s how OAuth to a single org works — and for one organization it’s invisible.

It stops being invisible when you have more than one. Setting up per-workspace auth contexts is a per-client exercise, and how gracefully a client switches between them varies. In our own use through a connector-managed OAuth session in August 2026, authorizing the second organization ended the session for the first, in every MCP client at once and without warning — including one where a ticket in the first organization then couldn’t be updated at all.

Nexus-Catalyst stores one Linear API key per organization, each with a short label you choose. The label is a parameter on the call, not a property of the session:

{ "action": "search_linear_issues", "workspace": "AV",  "team_id": "…" }
{ "action": "save_linear_issue",   "workspace": "JL", "issue_id": "JUN-42", "state_id": "…" }

Both of those can run in the same conversation, in either order, with no re-authentication in between — reads and writes in two separate Linear organizations. Nothing is switched, so nothing has to be switched back. And because it’s one connection, it behaves the same in every client you’ve connected Nexus-Catalyst to.

If you forget the label when more than one organization is configured, the tool answers with the labels it accepts rather than guessing at one.

Issues carry the context behind them

The reason Nexus-Catalyst touches Linear at all is that it already stores your working memory. A tracker records what was decided; the session where you worked it out is what you actually want six weeks later.

1. You debug a problem with the AI
2. recall_context surfaces the two earlier times you hit something similar
3. "File this" → create_linear_issue
4. store_context saves the session; link_memory_to_linear_issue ties it to the issue
5. Whoever picks the issue up gets the whole background, not just the summary

get_project_context runs that in reverse: give it a team or project and it returns the issues and the memories linked to them.

Linear’s MCP has no view of your Nexus-Catalyst memories, and Nexus-Catalyst has no view of your conversations with Linear’s server. The link only exists on the side that stores the memory.

Choosing

	Linear’s MCP	Nexus-Catalyst
Coverage of Linear’s API	Broader, and first-party	The working subset: issues, projects, labels, comments, statuses, users
Tracks new Linear features	Immediately	When we add them
Authentication	OAuth 2.1, or a bearer token / API key	An API key per organization, stored once
More than one organization	A separate auth context per workspace, managed per client	A `workspace` label per call, one connection
Deleting things in Linear	Supported by Linear’s API	Not offered, deliberately
Linked to your AI memory	No	Yes

Use Linear’s MCP when you work in one organization, or you need parts of Linear that Nexus-Catalyst doesn’t reach.

Use Nexus-Catalyst when you move between Linear organizations in the same conversation, or you want the issue and the reasoning behind it to stay connected.

Use both when they earn their place: Linear’s server for depth in your main organization, Nexus-Catalyst for the cross-organization work and the memory trail. They don’t conflict — they’re separate MCP connections, and the model picks whichever tool fits the request.

What Nexus-Catalyst will not do

There is no delete action for a Linear issue, label, project or comment, and none is planned. Nexus-Catalyst doesn’t expose destructive operations against a third-party system it doesn’t own — an assistant that can quietly remove a ticket is a worse trade than one you have to switch tabs for. Delete in Linear.

This is a rule about other people’s systems. Erasing your own Nexus-Catalyst memories is fully supported, and destructive by design.

Next steps

Linear Integration → — connecting a key, and a second organization
MCP Tools Reference → — every integration_query / integration_mutate action and parameter
Linear’s MCP documentation → — for their side of it

Need Help?