What does a Linear MCP server for our engineering team actually change?
Someone on the team has already tried it. They pointed Cursor or Claude at Linear's own MCP server, it worked, and now four more engineers want the same thing. Meanwhile the security review asks whose Linear account the assistant is acting as. That is the real question behind "linear mcp server for our engineering team". Not whether the server exists, but what the access model looks like once more than one person uses it.
MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.
Linear is in Elaichi's connector catalog as 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. Elaichi staff publish the connector once for every organization, and Elaichi does not write, review, test or fix the tools that server offers. Reports about those tools go to the Linear team, whose support contact Elaichi shows on the connector's page in the console. You can see the entry on the Linear connector page.
Three things change in the underlying model when calls pass through Elaichi: whose credential each call uses, which tools are callable at all, and what is recorded afterwards.
Who signs in, and whose Linear account each call uses
Each engineer connects Linear with their own Linear sign-in, and every call through that connection acts as that account. A connection someone shares runs on its owner's account instead, for everyone it is shared with. So sharing one tech lead's Linear connection with the team hands the team that lead's reach in Linear, not each person's own.
The credential never reaches the AI client. Elaichi's separate credential service holds it encrypted, and the client holds only an Elaichi token. Elaichi also never forwards its own MCP access token to a vendor's server. Linear's authorization server only ever sees a token it issued itself.
The endpoint is one address for every organization, https://api.elaichi.ai/mcp. Each person connects their client once and approves their own grant there. A grant is the standing permission one named client holds on behalf of one person. Removing or suspending a member revokes their grants, and their clients fail on the next call. Disconnecting the Linear connection takes effect on the next call as well.
Which Linear tools your team can see in Claude or ChatGPT
The callable tools are the ones Linear's server lists to that member's own connection, not a list Elaichi publishes. Discovery runs per connection, with that connection's own credential, because different Linear accounts can see different tools. Elaichi refreshes a connection's list when the connection becomes active and on the organization's daily refresh. It also refreshes when someone presses Refresh tools on the connection's page (at most once a minute), and when a call names a tool the list lacks.
In the client's tool list, connected tools are never listed one by one, however few there are. The model finds a tool with search_tools and runs it with execute_tool. A per-tool allow list inside Claude or Cursor therefore cannot single out one Linear tool, because no tool in the list carries a Linear name. That control lives in Elaichi.
Each remote tool carries a risk tier taken from the server's own annotations. A tool marked read-only counts as read, one marked non-destructive counts as write, and anything else, including a tool with no annotations, counts as destructive. Expect some tools to arrive labeled destructive for that reason alone. Someone who can manage the connector may lower a tool's tier, and that override is cleared if the server later raises the tier above it. Over MCP the tier is a label rather than a gate: the "Run your connected tools" consent covers every tier, deletes included, and the tier shows up in the hint and the audit row.
The same person can switch a tool off on the connector. A member with use access then sees only the tools that are switched on.
Keeping Linear read-only for the roles that should only read it
No consent checkbox makes a connected app read-only. "Run your connected tools" runs the person's connected tools, writes and deletes included, and "Delete data and remove access" covers Elaichi's own deletes rather than Linear's. Two controls do this job instead.
The first is restrictions, the rules that say which connectors and tools a role or a member may reach. To a restriction rule a Linear tool is the resource mcp with the upstream tool name as its method. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A rule meant for the whole engineering team is therefore written on that team's role or on each member. Within a layer, blocks beat allows, and an allow rule switches on an allowlist for everything it does not name. That is the trap worth reading about in why blocks match tool names and allows do not.
The second is narrower consent. On Elaichi's consent screen a person can choose "Only the ones I pick" and name stored toolboxes, and a toolbox built from read tools gives that client nothing else. A toolbox is a named list of tool entries, each pinned to one connection.
Role and restriction changes reach every surface within about two minutes. Revoking a share or disconnecting an account takes effect on the next call.
What the audit log keeps for a Linear call
Every call that reaches execution is written to the organization's audit log. The row records the person, the connector, the connection the call reached, the tool's advertised and catalog names, its tier, the surface, the MCP client's id, the outcome and what the call touched. A call refused earlier writes no row: a tool a restriction withholds, a missing scope and an unknown tool name all stop before the executor runs.
Filter by the Assistant category rather than MCP. A connected-tool call is recorded as an assistant action, while the MCP category holds grant events such as a client connecting. Elaichi keeps 90 days of audit history, and export to your own Datadog comes with the Black plan, which is launching soon. For the fields a reviewer will ask about, see what an AI agent audit log must capture.
Setting it up, in order
The order matters because the tool list does not exist until someone connects.
- Confirm the organization has an active Gold or Black plan. Without one the MCP endpoint is paused with a 403.
- Have each engineer open the Linear connector under Connectors and connect it with their own Linear sign-in. The Native MCP badge reads "The vendor's own MCP server. Elaichi handles sign-in, access and audit."
- Open one connection's page and read the tools Linear's server listed to it. Switch off anything nobody in the organization should call, and lower a tier where the server's annotations overstate what a tool does.
- Write the restrictions. One rule per role, aimed at the role rather than the team, naming the tools that role may not run.
- Have each engineer add https://api.elaichi.ai/mcp in their client, sign in, and approve the scopes and the toolbox choice on Elaichi's consent screen.
- Run one real call, then open the audit log and read the row. If the person, the connection and the tool are not what you expected, fix it before the rest of the team connects.
Product managers reading Linear rather than changing it need a narrower setup. That one is written out in Linear in Claude for a product team.
When you do not need Elaichi for this
If one engineer wants Linear in one client, point that client at Linear's server and stop there. Cursor reads MCP servers from .cursor/mcp.json in a project and ~/.cursor/mcp.json in the home directory. It defines a remote server with a url field and supports OAuth for servers that require it (cursor.com/docs/mcp, checked October 2026). On Claude Pro and Max the user adds a custom connector from Customize > Connectors, and on Team and Enterprise an Owner adds it once for the organization (support.claude.com, checked October 2026). On the protocol side, Elaichi's MCP endpoint speaks Streamable HTTP, and so do the remote servers it fronts (modelcontextprotocol.io, checked October 2026). One app, one person, no second vendor, no extra bill.
The case for a governed endpoint starts when the second app arrives and the second role disagrees with the first. At that point you are deciding things the client cannot decide: which role may close an issue, whose account a shared connection acts as, and what one removal has to switch off. That is the argument laid out in running vendor MCP servers through a control plane.
Pairing Linear with the rest of the engineering stack
GitHub is not in Elaichi's catalog, checked October 2026. A team on Gold can bring GitHub's own remote MCP server in as its own remote MCP connector, created by an Org Owner or Org Admin. Calls through that connector get the same restrictions, scopes and audit rows as a catalog connector. Calls a client makes to a vendor's server directly, outside Elaichi, pass through nothing of Elaichi's and are not governed by it. The SSO side of that decision is worked through in bringing GitHub's MCP server into a company with SSO.
Issue tracking is rarely the whole job. For the wider shape of an engineering rollout, read the notes on MCP for coding agents and the walkthrough of rolling Cursor out to an engineering team. To see which of your other tools Elaichi already carries, and which are the vendor's own servers, browse the connector catalog.
