# Connect Linear to Claude for our product team

> To connect Linear to Claude for our product team, govern Linear's own MCP server: per-person sign-in, a block rule, review for new tools.

**TL;DR** To connect Linear to Claude for our product team, Elaichi treats Linear as a native MCP connector. Linear builds and runs the MCP server; Elaichi handles sign-in, access and audit. Each product manager connects Claude to one address, then connects Linear with their own sign-in. Three settings stop the obvious failure: a block rule on the role's write and delete tools, no shared Linear connection, and new tools held at review. One audit filter, category Assistant plus a search for linear, shows what ran.

## Connect Linear to Claude for our product team: what you are wiring

A product manager asks for Linear inside Claude. The request sounds like one setup task. It is two. In Elaichi's catalog [Linear](/connectors/linear/) is a native MCP connector. Linear builds and runs the MCP server and its tools. Elaichi handles sign-in, access and audit in front of it. The console's Native MCP badge says exactly that on the connector itself. Claude reaches those tools over MCP. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.

The wiring has two halves. Each product manager connects Claude once to https://api.elaichi.ai/mcp. They sign in to Elaichi and approve their own grant, the standing approval one person gives one named client. Then each of them connects Linear with their own Linear sign-in. Claude holds only an Elaichi token. Elaichi never forwards that token to Linear's server, which sees only a token its own authorization server issued. The stored credential sits in Elaichi's separate credential service. The client-side walkthrough is in [connecting Elaichi to Claude](/blog/connect-elaichi-to-claude/). The rest of this post is the governance half.

## The failure a product team hits first

The first failure is not Claude reading too much from Linear. It is Claude closing, reassigning or deleting work, because nothing in the connect flow narrowed it.

Two defaults stack up. On a native MCP connector, a tool the vendor's server does not mark read-only or non-destructive counts as destructive in Elaichi. On Elaichi's MCP endpoint, the consent checkbox "Run your connected tools" runs every tier of connected tool, deletes included. The "Delete data and remove access" checkbox covers Elaichi's own data, not a connected app's. So the person approving the connection in Claude cannot tick their way to a read-only Linear.

Claude's own connector permissions are set to Always allow, Needs approval or Blocked, for a whole connector, a category of its tools or a single tool ([support.claude.com](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities), checked October 2026). That control cannot single out a Linear tool here, because connected tools are never listed one by one, however few there are. The names in Elaichi's list are search_tools, execute_tool and run_code. A per-tool rule in the client therefore covers every connected app at once. Cursor shows the same shape from the other side: it asks for approval before using MCP tools by default ([cursor.com](https://cursor.com/docs/mcp), checked October 2026), and the tool that prompt would name is execute_tool, not a Linear tool. Per-app and per-tool control belongs in Elaichi, as restrictions: rules that say which connectors and tools a role or one member may reach. [Restricting one tool or the whole app](/blog/per-tool-vs-per-app-restrictions/) covers how to choose between the two shapes.

## Restriction one: block Linear's write and delete tools

Write a block rule naming Linear's write and delete tools, on the role the product team holds. In a restriction rule, a tool from a vendor's MCP server is the resource mcp with the upstream tool name as its method. So you need the names Linear's server actually publishes. Read them off the connector's Tools tab in the console. That tab lists the tools that are on and gives a manager Turn off beside each one.

Two things decide where the rule goes. A restriction targets a role or one member, and nothing wider. Where no rule reaches a member, nothing is restricted for them. A product team is usually a team. So either give it a custom role, which Gold includes, or accept that a rule written on Member applies to everyone on Member. [Designing roles for AI agents](/blog/designing-roles-for-ai-agents/) works through that choice.

Name the trade-off before picking a mode. A layer with only block rules has no allowlist. Every Linear tool you did not name stays reachable, including one Linear ships next month. An allow rule naming only the read tools closes that gap. But an allow rule turns on the allowlist for the whole layer, so the role then needs allow rules for every other app it uses. Blocks match a tool by name or by operation; allows match the pinned operation only. That is why [blocks catch a renamed tool and allows do not](/blog/block-matches-name-allow-matches-operation/).

Writing one needs the restriction:manage permission. Among the built-in roles, Org Owner and Org Admin hold it, and the rule also needs the restrictions feature that Gold and Black both include. A new or changed rule takes effect within about two minutes. A restricted tool is not hidden from the person: search_tools still names it, flagged as restricted and with no way to call it. A product manager can therefore ask an admin for access instead of guessing.

## Restriction two: one Linear connection per person

Have every product manager connect Linear themselves, and share no connection. Every call through a connection uses that connection's own bound account, whoever makes the call. One shared Linear connection would therefore act in Linear as its owner for everyone it is shared with.

Per-person connections buy three things. Linear's own permissions apply per person, so a product manager reaches what they could reach signed in there. The audit row names the right human. And tool discovery runs per connection, with that connection's own credential. Different accounts can see different tools, so nobody inherits a colleague's wider list. [AI agents with employee permissions](/blog/ai-agents-employee-permissions/) is the longer version of this argument. [Offboarding when the agent holds access](/blog/offboarding-when-the-agent-holds-access/) covers what a shared connection costs you at the other end.

## Restriction three: hold new Linear tools at review

A native MCP connector starts with its new-tool policy set to automatic. A tool the server lists for the first time is then usable at once. Switch the policy to review. Under review a newly seen tool waits as pending review until someone who can manage the connector approves it. That approval is bound to the exact definition the reviewer saw. A connection whose server later presents a different definition of that tool cannot call it until the new definition is approved too.

Changing the policy, or a tool's status, needs the connector:manage permission. Among the built-in roles only Org Owner and Org Admin hold it. While you are in there, check each tool's tier and where the tier came from. Elaichi reads the tier from the server's own annotations and treats a tool with none as destructive. The console shows whether a tier is the server's label, the protocol default or a manager's override. A manager can lower a tier per tool. That override is cleared if the server's own tier later rises above it.

Two honest notes. Elaichi staff do not curate a native connector's tools. What a member can call is what Linear's server lists to that member's own connection. And the connector's page carries Linear's own support contact, because reports about its tools go to the vendor rather than to Elaichi.

## The audit query that proves it

In the console's audit log, set the category filter to Assistant and search for linear. Connected-tool calls sit in the Assistant category, because their action is assistant.toolbox_tool. The MCP category holds client grants, not tool calls. The free-text search matches each word of the query anywhere in the action, the resource and the event's stored details.

Skip the action-kind filter for this. A connected-tool call is filed as "other", not as created, updated or deleted. Filtering by kind therefore hides the calls you came for. Use the entry's detail panel instead. It opens with a sentence naming the surface, the person, what they did and the connection, starting "Using Claude, ...". Below that sit lines for Connector, Connection, What it did (Read data, Changed data or Deleted data), Approval and Outcome. For a call from an AI client, the Approval line says it was allowed by the access that client was granted.

Know what the log does and does not prove. Every call that reaches execution is recorded. The row carries the person, the connector, the connection, the tool's advertised and catalog names, its classification, the surface, the MCP client and the outcome. A call a restriction refused before execution writes no row at all. Blocked calls are evidenced by the rule and its restriction.created entry, not by silence in the tool-call list. Any member can read their own events. Reading every event in the organization takes audit:view, held by Org Owner, Org Admin and the free, read-only Auditor role. Elaichi keeps 90 days of audit history, and export to your own Datadog comes with the Black plan, which is launching soon. [What an AI agent audit log must capture](/blog/what-an-ai-audit-log-must-capture/) lists the fields to check before accepting any of this as evidence.

## When your product team does not need Elaichi for this

If Linear is the only app and the product team is the only team, you do not need a second vendor. On Claude Team and Enterprise an Owner adds a remote MCP server as a custom connector from Organization settings, then Connectors ([support.claude.com](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp), checked October 2026). Each member then connects it themselves, and the vendor's own permissions still apply per person.

What you give up is the part this post is about. Calls a client makes straight to a vendor's MCP server do not pass through Elaichi. There is no Elaichi restriction in front of them and no Elaichi audit row behind them. The case for one governed endpoint starts at the second app or the second team. You get one address that Claude, ChatGPT and Cursor all sign into, one set of rules across a catalog of 650+ connectors, and one log to read afterwards. [When you don't need an MCP gateway yet](/blog/when-you-dont-need-an-mcp-gateway/) is the honest test. [MCP governance](/blog/mcp-governance/) is the wider picture. [Which Notion workspace did ChatGPT write to](/blog/product-team-chatgpt-notion-workspace/) runs the same exercise for a product team's other app. The full catalog sits at [connectors](/connectors/), and the [governance use cases](/use-cases/governance/) show where this fits in a rollout.

## FAQ

### Is Linear an official MCP connector, or something Elaichi wrote?

In Elaichi's catalog Linear is a native MCP connector, which means Linear builds and runs the MCP server and its tools. Elaichi handles sign-in, access and audit in front of it. Its tools come through the same Elaichi address, and the same search_tools and execute_tool, as every other connector. Reports about the tools themselves go to Linear's support contact, shown on the connector's page.

### Can a product team get a read-only Linear in Claude without writing a restriction?

Yes, through the consent step. When a person approves an MCP client on Elaichi's consent screen, they can choose "Only the ones I pick". That names up to 50 stored toolboxes, a toolbox being a named list of tools. If those toolboxes hold only read tools, the client reaches only those. A stored toolbox runs on the connection pinned in it. So each person needs their own toolbox, or a shared template they stamp with their own Linear connection. The alternative is a restriction blocking the write and delete tools for that role.

### Will Claude's per-tool permission setting stop a delete in Linear through Elaichi?

Not on its own. Elaichi never lists a connected tool by name in an AI client's tool list, however few there are. The names a client sees are search_tools, execute_tool and run_code. A client-side rule on a single tool therefore acts on every connected-app call made through that one name. It cannot tell one app or one action from another. Per-app and per-tool control is set in Elaichi, as restrictions on a role or one member.

### How fast does a new restriction on Linear tools take effect?

Within about two minutes. Role, team-membership, restriction and access-grant changes all reach every surface on that schedule. A different set of changes is effective on the client's very next call: revoking a grant, removing or suspending a member, revoking a share and disconnecting an account.

### Where do Linear tool calls from Claude appear in the audit log?

In the Assistant category, not the MCP category. A connected-tool call is recorded as assistant.toolbox_tool, so the Assistant filter is the one that returns it. The MCP category holds MCP client grants. Each row names the person, the connector, the connection, the tool, its classification, the surface and the MCP client. The detail panel states whether the call read, changed or deleted data.

## Read next

- [Linear MCP server for our engineering team](/blog/linear-mcp-server-for-our-engineering-team/) — A Linear MCP server for our engineering team changes whose account each call runs as, which tools stay on, and what the audit log keeps.
- [GitHub MCP server for a company with SSO](/blog/github-mcp-server-for-a-company-with-sso/) — A GitHub MCP server for a company with SSO has two sign-ins to settle: your identity provider, and whose GitHub account the tool call actually runs as.
- [Connect Ashby to ChatGPT for recruiters](/blog/connect-ashby-to-chatgpt-for-recruiters/) — Connect Ashby to ChatGPT for recruiters with two restriction rules that hold the role to reads, plus the audit query that proves nothing was changed.