Can Cursor's Background Agent Read Linear or Jira Tickets Directly?
Not automatically, and not from a ticket ID typed into a chat box. Cursor's background agent (Cursor now calls it a Cloud Agent, having renamed it from Background Agent) starts from a prompt plus a repo and branch. It doesn't have a standing connection to your Linear workspace or your Jira site just because you mentioned a ticket key.
There are two ways around that, and they behave differently. Cursor ships native integrations for both Linear and Jira that read a ticket automatically the moment you trigger the agent from the ticket itself, whether by assigning it or mentioning @Cursor in a comment. And separately, Cursor's cloud agents support MCP servers, so if you're starting the agent somewhere else, from the IDE, from Slack, from the web app, and want it to look something up in your tracker mid-task, that requires an MCP server pointed at Linear or Jira (or, if you want the customer story behind the ticket too, at Modem).
+ ChatGPT
issue filedagent taskThe trigger path: assign or mention, and the ticket rides along
Cursor's Jira integration is the more surprising of the two, because it isn't a generic connector. It's a purpose-built app installed through the Atlassian Marketplace, and it requires Jira Commercial Cloud with Rovo enabled, plus admin access on both the Jira side and the Cursor side to wire it up. Once connected, you assign a work item to Cursor, or comment @Cursor with instructions, and the agent starts with the item's title, description, comments, and your connected repository already loaded in. Nobody pastes a stack trace or a repro from the ticket into the prompt; the agent reads the ticket the same way a person opening it would.
The Linear integration works the same way from the trigger side, minus the Atlassian scaffolding. A Cursor admin connects the Linear workspace by OAuth, picks a team, and once that's live, assigning an issue to Cursor or mentioning @Cursor in a comment kicks off a cloud agent that has the issue's contents already. Cursor also shows the agent's progress back on the Linear issue and opens the PR from there when it's done.
Both integrations solve the same real problem, someone shouldn't have to hand-copy a bug report into a chat window for the agent to act on it, but both are one-shot. The agent gets the ticket that triggered it. It doesn't get a standing line into the rest of your tracker to check whether the same bug was already reported on a different ticket, or to look up an unrelated issue mid-task.
Starting elsewhere: this is where MCP does the work
If you're not triggering from the ticket itself, say you're in Cursor's IDE and want the agent to check what ENG-4521 actually says before it starts, none of the above applies. The agent has no memory of your tracker unless an MCP server is configured for it. Cursor's own docs are direct about this: cloud agents "support MCP servers, giving them access to external tools and data sources like databases, APIs, and third-party services," configured per team from the MCP dropdown in the agent dashboard.
Linear publishes an official MCP server for exactly this. Point Cursor at it and the agent can find, create, and update issues, projects, and comments on demand, using either OAuth or a Linear API key. There's also a read-only endpoint at /mcp/readonly if you want the agent looking things up without the ability to change anything. Atlassian ships a hosted equivalent for Jira: the Rovo MCP server at mcp.atlassian.com, which lists Cursor as a supported client and can search, summarize, and update Jira work items by key, the same job Linear's server does for issues. Either official server gets an agent read and write access to the ticket. Neither one knows anything about the customer behind it, which is the gap a third-party server like Modem's is built to close instead.
How this played out at Warehouse Nine
At Warehouse Nine, a query-performance monitoring tool for Postgres, the team had already turned on the Linear-Cursor integration, so assigning a bug to "Cursor" as the issue assignee reliably kicked off a working agent. The trouble started when staff engineer Kofi Adjei watched a teammate try to get the same result from inside the IDE instead.
Teammate, in a Cursor chat: can you look at ENG-4521 and fix the slow query detector regression
Kofi, reviewing the run afterward: It didn't fix anything, because it didn't know what ENG-4521 was. It just guessed from the ticket number that "detector regression" meant something about the anomaly threshold and went and changed the wrong file.
The fix wasn't a better prompt. Kofi added Linear's official MCP server to the team's Cursor MCP config, scoped to a read-only API key at first so agents could look issues up without editing them. After that, the same kind of request worked, because the agent could actually query the issue instead of pattern-matching on a ticket number. "Once it could read ENG-4521 for itself, it stopped hallucinating what the bug was," he said. A few weeks later he widened the key's scope so agents could also comment progress back onto the issue, which meant nobody had to relay status between Linear and Slack by hand anymore.
What ticket access alone doesn't solve
The trigger integrations and a bare tracker MCP server solve "can the agent read the ticket," which is a narrower question than "does the agent know everything relevant to the ticket." Two gaps show up quickly on a real team:
- The ticket rarely has the full story. A Linear issue titled "export times out for large workspaces" usually doesn't say which customer hit it, how many times it's been reported elsewhere, or what they were told last time. That context lives in a support thread, a Slack DM, or a call transcript, none of which a Linear or Jira MCP server can see.
- Read access on a tracker MCP server is one tool among many. The agent can fetch an issue, but it still needs a human to have already decided the issue is worth working, deduped it against the four other tickets describing the same bug, and attached the right customer to it.
That's the point where we'd bring up Modem, because it's built to sit underneath exactly this gap. Modem's own MCP server lets Cursor, Claude Code, or any MCP-compatible client ask about your users in plain language, and it reads and writes to Linear and Jira the same way Modem's dashboard does, pulling in status, priority, and comments, and creating or updating issues from a conversation. The difference from a bare tracker MCP server is what's attached to the ticket before the agent ever asks. Modem already knows the ticket traces back to two enterprise accounts asking for the same thing, because it deduped the request across your support tool and Slack before the issue existed. The Modem-Cursor integration takes that a step further and lets the Modem agent hand a task straight to a Cursor cloud agent with that customer context already written into the task description. We build Modem, and it's worth saying plainly: if all you need is an agent that can read and update issues, with no customer context attached, Linear's own MCP server or Atlassian's Rovo MCP server already does that job on its own.
Setting it up without the customer-context layer
If a customer graph is more than you need today, the smallest useful setup turns on Cursor's native Linear or Jira integration for the trigger flow (assign or @Cursor mention), and separately adds the matching official MCP server, Linear's at https://mcp.linear.app/mcp or Atlassian's Rovo server at mcp.atlassian.com, scoped read-only at first, for every other case where an agent needs to check a ticket it wasn't started from. That combination covers both the "just fix this ticket" flow and the "does this already exist" question, without giving every agent write access to your tracker on day one. For the sibling question of what happens once several agents are running against the same repo from different tickets, see why multiple Cursor background agents conflict on the same repo; for the MCP landscape beyond just Linear and Jira, the best MCP servers for customer feedback compares six, Modem included.
