--- title: "How to Connect MCP to Jira and Linear" description: "What the Linear and Atlassian MCP servers can reach, why a tracker is the riskiest easy connection, and the read jobs worth doing before you allow any write." canonical_url: "https://builderscamp.com/guides/tools/mcp-for-jira-and-linear" date_published: "2026-09-18" date_modified: "2026-09-18" author: "Andre Albuquerque, Tiago Pedro da Costa" publisher: "Builders Camp" guide_class: "tools" --- # MCP for Jira and Linear, and what each connection can actually reach **TL;DR:** The Linear MCP server is read-write by default at mcp.linear.app/mcp, with a separate read-only endpoint one URL away. The Atlassian Remote MCP Server covers Jira, Jira Service Management, Confluence and Bitbucket, and acts with whatever permissions your own account already has. Connect either for the weekly read jobs first, because a tracker is the source of truth your team argues from. ## What can each of these two servers actually reach? Linear's server sits at mcp.linear.app/mcp and exposes tools for finding, creating and updating issues, projects and comments. It is read-write by default. Authentication runs on OAuth 2.1 with dynamic client registration, or a bearer token or API key if you prefer. The detail worth knowing before anything else: there is a separate read-only endpoint at mcp.linear.app/mcp/readonly, and Linear notes that asking only for the read scope means the underlying token cannot reach write APIs at all. One is a different URL, the other is a different token. Both remove a category of accident. Atlassian's Remote MCP Server sits at mcp.atlassian.com/v2/mcp and is wider by design. It reaches Jira, Jira Service Management, Confluence and Bitbucket, letting a client search and summarise across them, retrieve Loom recordings, and create or update work items and pages from plain language. Atlassian's own example of the automation it enables is generating work items from meeting notes, which tells you the intended posture: this is built to write. The asymmetry between the two is the useful thing here. Linear hands you a switch. Atlassian hands you a permission model. ## Why is a tracker the riskiest easy connection? Because the tracker is not a data source, it is the thing your team argues from. Everyone's answer to what is happening this sprint comes out of it. A wrong number in an analytics query produces a bad slide. A wrong status change in the tracker produces three people acting on a state that was never true, and nobody looking for a cause because the tracker is what you check when you want the truth. Connections to trackers are also unusually easy to set up, which is the trap. A remote server plus an OAuth flow is about ninety seconds of work, and there is no natural moment in those ninety seconds where anyone asks what the assistant is allowed to change. ## "With your existing permissions" is not a safety boundary Atlassian states plainly that clients act on connected products with your existing permissions, and advises least privilege and audit log monitoring alongside it. That sentence reads as reassurance and functions as a warning, depending entirely on who you are. If you are a product manager on one project, the blast radius is your project. If you are a Jira administrator, a workspace owner, or someone who accumulated permissions across four years and three reorganisations, the connection inherits all of it silently. The protocol's own security guidance makes the general version of this point when it argues for scope minimisation: a broad token turns a small compromise into a large one, and makes revocation disruptive enough that people avoid it. The practical move is unglamorous. Connect the tracker from an account whose permissions match the job, not from the account that happens to be yours. ## Which tracker jobs are worth connecting for, first? The recurring read work, because it is exactly the work that is boring, weekly and verifiable. - The Monday triage pass: open, unassigned, tagged urgent, from the last seven days, grouped by area. - The stale sweep: everything untouched for fourteen days that is still marked in progress, with the last comment attached. - The what-changed digest: what moved between Friday and Monday, and which of those moves affect a commitment someone made outside the team. Each of those is one question, checkable in ten seconds against the board, and none needs write access. That is the whole first month. If the assistant cannot do these three reliably, it is not ready to change anything, and if it can, you have already recovered the setup cost. For the deeper version of the triage job, [Claude Code bug triage for product managers](https://builderscamp.com/guides/tools/claude-code-bug-triage-for-pms) covers how to shape the question so the output is reviewable rather than plausible. ## What does the setup look like in practice? Both are remote servers, so the shape is the same one Claude Code documents for any HTTP server: `claude mcp add --transport http `, with the vendor's own endpoint as the URL, followed by `claude mcp login ` to run the OAuth flow in a browser. For Linear, pointing that URL at the read-only path rather than the default one is the entire safety decision, and it costs nothing to reverse later. Then check it landed. `claude mcp list` shows every configured server and whether it is connected, needs authentication or failed. `claude mcp get ` gives the detail for one, including the HTTP status and error text behind a failure. If you added the server at project scope so the team inherits it, remember that project servers prompt for approval in an interactive session but load without prompting in headless runs, which is worth knowing before a tracker connection ends up inside an automated pipeline. ## When does a write earn its place? When three things hold at once. The write is one narrow action type, not a category. It is reversible, so a mistake costs minutes rather than an incident. And it is attributable to a service identity, so the audit log tells you an assistant did it and not that you did. That test passes for drafting a ticket body a human submits, adding a comment that summarises a linked thread, or applying a single label under a rule you wrote. It fails for auto-closing, bulk relabelling, and reassignment, because all three change what other people believe about state without those people being in the loop. There is one more failure mode the protocol's own security guidance names and trackers are wide open to: content in the system can carry instructions. A ticket description is text, an assistant reads it, and text an outsider can write into your support queue is text that can try to steer the assistant. Read-only does not fully remove that, because a summary can still be poisoned, but it removes the version where the poisoning ends in an action. ## What actually breaks, and it is not the protocol Messy delivery data. An assistant with tracker access inherits your taxonomy exactly as it is. Inconsistent severity labels produce a triage summary that reproduces the inconsistency in fluent prose, which is worse than a messy board because it looks resolved. Half-abandoned workflow states, duplicate epics and tickets nobody closed produce the same effect. None of that is an MCP problem, and none of it gets better by connecting a second server. It is delivery hygiene, which is the thing Builders Camp's Project Management for Product bootcamp works on directly: planning and scoping, dependency management, delivery rituals worth keeping against the ones worth killing, and status communication that reports decisions rather than activity. It runs 1 week with 1 live session and 8 microlessons, inside the Product Delivery Specialist Track. Building with Claude Code is the complement on the tooling side, naming MCP and tool integrations in its own syllabus. [See the Project Management for Product bootcamp](https://builderscamp.com/bootcamps/project-management-for-product?utm_source=guide&utm_medium=organic&utm_campaign=mcp-for-jira-and-linear) One test to run in week two, once the read jobs work: hand someone else the assistant's triage output and your hand-written one, unlabelled, and ask which they would act on. If they pick yours, the connection has not paid for itself yet. For choosing what else to connect, [best MCP servers for product managers](https://builderscamp.com/guides/tools/best-mcp-servers-for-product-managers) sorts the options by job, and [MCP for product managers](https://builderscamp.com/guides/tools/mcp-for-product-managers) covers the protocol these two servers implement. ## Frequently asked questions ### What is the Linear MCP server endpoint, and is it read-write? It is mcp.linear.app/mcp, and it is read-write by default. Linear also publishes a read-only endpoint at mcp.linear.app/mcp/readonly, and notes that requesting only the read OAuth scope keeps the underlying token away from write APIs. Those are two different mechanisms with the same outcome, and either is a reasonable starting point. ### What can the Atlassian Remote MCP Server do? It sits at mcp.atlassian.com/v2/mcp and covers Jira, Jira Service Management, Confluence and Bitbucket, letting a client summarise and search them, retrieve Loom recordings, and create or update work items and pages from natural language. Atlassian gives generating work items from meeting notes as an example of the automation it is built for. ### Does connecting a tracker give the assistant more access than I have? No, and that is the point people misread. Atlassian's own documentation states that clients act on connected products with your existing permissions. If you are an administrator, the connection inherits administrative reach, which is a much larger surface than an individual contributor's. Your own permission level is the real scope of the connection. ### Which tracker tasks are worth connecting first? The recurring read jobs: the Monday triage queue, a stale-ticket sweep, a what-changed-since-Friday summary, and duplicate detection across an inbox. All four are things a product manager already does by hand weekly, all four are verifiable at a glance, and none of them requires the assistant to write anything. ### When is allowing writes justified? When the write is one narrow, reversible action type, attributable to a service account rather than to you personally, and reviewed before it lands. Bulk relabelling and auto-closing fail all three tests. Drafting a ticket body that a human then submits passes them, because the human is the write. ### How do I authenticate these servers? Both use OAuth. Linear supports OAuth 2.1 with dynamic client registration, plus bearer token or API key as alternatives. Atlassian uses OAuth 2.1. In Claude Code, claude mcp login or the /mcp command inside a session starts the browser flow, and claude mcp logout clears the stored credentials. ### What if our tracker data is messy? Then the assistant will be confidently wrong faster. A connection inherits your taxonomy: if severity labels are applied inconsistently, a triage summary built on them repeats that inconsistency with a fluent explanation attached. Fixing the label discipline is a delivery problem, not a protocol one, and it pays off with or without an assistant. ## Sources - [Linear: Model Context Protocol](https://linear.app/docs/mcp) - [Atlassian: Getting started with the Atlassian Remote MCP Server](https://support.atlassian.com/rovo/docs/getting-started-with-the-atlassian-remote-mcp-server/) - [Claude Docs: Connect Claude Code to tools via MCP](https://code.claude.com/docs/en/mcp) - [Model Context Protocol: Security best practices](https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices) ## How this guide was made Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.