ToolsConnector
Linear
Search, create and update Linear issues, projects and cycles from Claude or ChatGPT, through Tulina's own MCP server, not Linear's own hosted one.
Official site: linear.app
What it can do
1 read/3 write/1 send
- 01Read
List and search issues, filter by team, project, cycle, assignee or status
- 02Write
Create and update issues, including assignee, priority, labels, status and sub-issues
- 03Send
Read, post and thread comments on an issue
- 04Write
List and create projects, teams, cycles and labels
- 05Write
Create and manage webhook subscriptions
A Linear API key is personal: it acts as the person who created it, with that person's access to teams and projects. Tulina keeps it in the vault at the level you choose. Set your own and the agent acts as you; set one at the organisation's level and the whole team works through that one identity, which is also the name Linear writes against every issue and comment the agent creates.
Is there a Linear MCP?
Yes. Linear hosts its own MCP server at https://mcp.linear.app/mcp,
with tools to find, create and update issues, projects and comments, and
a read-only endpoint beside it. Tulina reaches Linear through its own MCP
server instead, on the same link that carries the rest of your stack, so
a model can read a call in Granola, open the
ticket in Linear and post the outcome to Slack in one
conversation.
How do you connect Linear to Claude and ChatGPT?
Through Tulina's own MCP server, in three steps:
- In Linear, open Settings, then Security & access, then Personal API keys, and create a key.
- Paste it into Tulina's Linear connector, for yourself or for the organisation. It is stored in the vault and never shown to the model.
- Add
https://mcp.tulina.ai/mcpto Claude or ChatGPT and sign in with your Tulina account. The MCP page has the same link.
From there, list and search issues by team, project or status, create or update one with an assignee and labels, post a comment, or set up a webhook, from the same chat. Several Linear workspaces can be connected as named accounts, and a request names the one it is for.
Tulina vs Linear's official MCP server
Both reach the same workspace. They differ in who holds the credential and what else rides on the connection.
| Linear's MCP server | Tulina | |
|---|---|---|
| Endpoint | mcp.linear.app/mcp, hosted by Linear | mcp.tulina.ai/mcp, one link for every connected tool |
| Sign-in | OAuth per person and per workspace, or an API key in the header | One Linear API key, held in Tulina's vault, set for a person or for the organisation |
| Read-only use | A separate /mcp/readonly endpoint, or the read scope | A Linear key created with Read permission only, and roles deciding who reaches the connector at all |
| In the same conversation | Linear | Linear plus Granola, Slack, your CRM and the other connected tools |
| Without a chat open | Your MCP client's own options | Hosted agents run a process on a schedule or a webhook |
If Linear is the only system the model needs, Linear's own server is the shorter path. Tulina earns its place when a ticket is one step in a longer piece of work.
What you can ask it
"Which issues on the Product team moved this week?" The agent lists the team's issues updated since Monday, ordered by last update, and returns each title, status and assignee. Bounding the read by update date matters: Linear sorts by creation date by default, so an old ticket touched yesterday can sit on any page.
"Turn this bug report into a ticket for Platform, high priority,
labelled billing, assigned to Jane." The agent reads the team's labels
and members to get their ids, creates the issue with that title,
description, priority, label and assignee, and hands back its
identifier, such as ENG-123.
"Move ENG-123 to In Progress and tell the reporter in a comment." A status in Linear is a workflow state that belongs to one team, so the agent first reads that team's states, then updates the issue with the right state and posts the comment on it.
Processes chain these steps without a prompt each time. Merged PRs move tickets and post a digest and Triage and route bug reports run on Linear and Slack; the full list is below.
What the Linear connector can't do
- It covers issues, comments, projects, teams, cycles, labels, members and webhooks. Linear documents, initiatives and file attachments are out of its reach.
- Search matches text in an issue's title and description. It is a contains match, closer to a filter than to Linear's own ranked search.
- Changing a project's status takes a status id read from an existing project. There is no free-text status to set.
- It acts as the key's owner, with exactly that person's access. A private team the owner cannot see is invisible to the agent too.
- Deleting an issue moves it to Linear's trash and archiving it is reversible. Both are available on a full key, so a workspace that should only read connects a key created with Read permission.
- Linear applies its own rate limit per key, so a bulk rewrite of thousands of issues is paced rather than instant.
Why through Tulina
The connection was never the hard part.
Most systems now publish their own way for a model to reach them, and that is good: it is what Tulina connects to. The hard part is deciding who may use it, what it is allowed to return, and what the model knows before it asks.
The keys stay in one place
YouTeamOrganisation
Connect Linear once. The credential is encrypted in a vault, never held in clear, and never pasted into a chat or a workflow file. A person uses their own key where they have one, their team's where they do not, the organisation's after that, so nobody is blocked and nobody holds more access than they need. Revoke it once and everything running on it stops.
What leaves is filtered before it leaves
fields droppedmasked or hashedpseudonymised
Roles decide who can reach Linear at all. Beyond that, a policy on the connector itself decides what comes back. The data is minimised at the source rather than after it has already reached a model.
Every call is on the record
whatwhowhen
Runs are logged for the organisation. That is what makes an automated action reviewable after the fact, and it is what a security review asks for first.
The run starts knowing your company
namingkey accountsdecisions
A direct connection gives a model access. It does not tell it how your company names things, which accounts matter, or what was decided last quarter. Tulina carries that across every tool, so the same request against Linear returns something usable instead of something generic.
Processes that run on Linear
Call feedback becomes tickets and docs
Every call recorded in the day is distilled overnight, with bugs and feature requests routed to the right team as tickets and docs, plus a Friday digest.
5 steps →Expand accounts from usage
Each morning, accounts near a plan limit or on a feature their plan lacks get an offer priced on your packaging rules, an expansion deal and a drafted proposal.
7 steps →Follow through on sales calls
After every sales call, the follow-up email is drafted from what was said, the deal gets a dated next step, product asks are filed and any risk is flagged.
7 steps →Merged PRs move tickets and post a digest
Every merged pull request is matched to its ticket, the ticket moves forward with a comment naming the PR, and the team gets one daily summary of what shipped.
4 steps →Prepare for a customer call
Before the call, the last conversations, the account's state, how the product is actually used, and where requested features stand, in one brief.
5 steps →Revive deals that went cold
Deals lost more than 90 days ago come back with fresh signals, contacts checked for job moves, and the features they asked for that have since shipped.
6 steps →Triage and route bug reports
An incoming report is read, matched against open issues to catch duplicates, and filed to the right team's board with severity attached.
5 steps →
