Connect Cursor to your project tracker with MCP: read the ticket, implement it, comment back

What the connection actually gives you

Without MCP, the loop is: open the ticket in a browser tab, copy the description into the chat, implement, then go back and update the ticket by hand. The copy step loses the comments, the linked requirement, and the labels, and the update step gets skipped when you are tired.

With a remote MCP server connected, Cursor's agent has tools like "get issue", "list issues", "comment on issue" and "set status". You write "implement ATR-212" and the agent fetches the issue, reads the acceptance criteria and the thread, does the work, and ends by writing a comment that says what it changed and which files. The ticket stays the source of truth, and the agent reads it rather than a paraphrase.

What it does not give you is judgment. The agent will happily implement a badly written ticket badly. The connection removes copying, not thinking.

Step 1: pick the server and its URL

Each tracker publishes a remote MCP endpoint. As of October 2026:

All three use Streamable HTTP, which Cursor supports natively. Linear's docs note its older SSE endpoint is a deprecated fallback. If a tracker only ships a local (stdio) server, Cursor runs that too, but you lose the OAuth flow and end up managing an API key in an environment variable.

Step 2: add it to .cursor/mcp.json

Cursor reads two files: .cursor/mcp.json in the project root for project-specific servers, and ~/.cursor/mcp.json for servers available everywhere. A tracker belongs in the project file if the repo maps to one product, and in the global file if you work across several.

The remote entry is a url under mcpServers; headers is optional and only needed for static tokens:

{
  "mcpServers": {
    "atrix": {
      "url": "https://atrix.dev/api/mcp"
    }
  }
}

For Linear, replace the name and URL with https://mcp.linear.app/mcp; for Jira, https://mcp.atlassian.com/v2/mcp. Cursor's docs show the same shape for every remote server, and support ${env:NAME} interpolation inside url and headers if you ever do need a header.

Save the file. Cursor picks it up without a restart and lists the server under Customize in the sidebar, where a toggle enables or disables it. A disabled server does not load and its tools do not appear in chat.

Step 3: authenticate with OAuth, not a pasted key

The first time the agent calls a tool, the server replies 401 with a pointer to its authorization server, Cursor registers itself as a public client (dynamic client registration) and opens your browser. You sign in, see the scopes being requested, approve, and the token lands in Cursor. Cursor uses the authorization-code flow with PKCE, and the two redirect URLs it uses are fixed: https://www.cursor.com/agents/mcp/oauth/callback for web and Cloud Agents, and http://localhost:8787/callback for the desktop app.

Why this is better than a key in headers: the token is scoped to what you approved, it refreshes on its own, and revoking it in the tracker kills Cursor's access immediately. A personal access token in a JSON file is a long-lived secret on disk that every agent in that project can read. Keep the header route for CI, where there is no browser.

If a server does not support dynamic registration, Cursor also accepts an auth object with CLIENT_ID, optional CLIENT_SECRET and scopes on the remote entry.

Step 4: let the agent read the issue and comment back

Approve read tools first, then one write at a time. Cursor asks for approval before using MCP tools by default; the Run Modes that govern terminal commands apply to MCP tools too, so in auto-review mode allowlisted tools run immediately and everything else goes through the classifier.

A working prompt:

Implement ATR-212. Read the issue and its comments first, follow the
acceptance criteria, and when done comment on the issue with the files
changed and anything you could not do.

The agent calls work_get_issue (or get_issue on Linear, getJiraIssue on Atlassian), implements, then calls the comment tool. We do not let it change status on its own: a comment is reversible noise; a "Done" on something half-finished is a lie in the tracker. Status changes stay human, or at least behind a per-call approval.

Two habits that help:

1. Put the issue key in the branch name. atr-212-booking-reminders. The agent and you both know which ticket is in play, and the comment goes to the right place.
2. Ask for a comment, not a summary in chat. Chat scrolls away; the ticket is where the next person looks.

Scopes, audit and limits on the Atrix side

Atrix AI's MCP server exposes 85 tools over OAuth 2.1 and is listed in the Official MCP Registry and on Glama. When Cursor connects, you pick scopes from a list of 49 grantable ones (as of October 2026). A write scope implies its read (work.write includes work.read); named scopes such as feed.post are never implied and have to be granted on purpose. A token can never do more than the person who created it, and permissions are resolved per call, so removing someone's access to deal values also removes it from every token they minted. Pay records are not grantable at all.

For a Cursor connection, we grant work.read and projects.read first, then add work.write once the comment-back step has earned it. Every call is audited with the tool, outcome, subject kind and id, never the contents, and the limits are 120 calls and 30 writes per minute per token. The developer docs list the tools and scopes; the Cursor integration page has the one-click add.

Where Atrix is weaker than Linear for this job: Linear's endpoint has a dedicated read-only URL, so a cautious teammate can connect without seeing a scope picker at all. In Atrix you get the same outcome by granting only read scopes, which takes one more decision. Jira's server reaches Confluence and Bitbucket as well, which matters if your specs live there.

Troubleshooting the usual failures

• "No tools" after adding the server. Check the toggle under Customize, and that the JSON is valid: a trailing comma silently breaks the whole file.
• OAuth loop or "invalid redirect". The provider must accept Cursor's fixed callback URLs. Corporate SSO that blocks localhost redirects breaks the desktop flow.
• Tools run but return 403. Scopes. You granted read and the agent tried to write. Re-authorise with the write scope or keep the write for yourself.
• The agent reads the wrong issue. It guessed from a vague prompt. Give it the key, not "the booking bug".
• Too many tools confuse the model. Disable servers you are not using today; Cursor loads only enabled ones.

FAQ

Does Cursor support remote MCP servers with OAuth?

Yes. As of October 2026 Cursor's docs describe remote servers configured with a url entry in mcp.json, OAuth with the authorization-code flow and PKCE, and dynamic client registration where the server supports it. Cursor registers as a public client.

Where does the Cursor MCP config file live?

.cursor/mcp.json in the project root for that project, or ~/.cursor/mcp.json in your home directory for all projects. Both use an mcpServers object keyed by a name you choose.

Can Cursor read Linear or Jira tickets through MCP?

Yes. Linear's server is at https://mcp.linear.app/mcp (read-only at /mcp/readonly), and Atlassian's Rovo MCP server for Jira and Confluence is at https://mcp.atlassian.com/v2/mcp. Both document Cursor as a supported client and use OAuth 2.1.

Should the agent be allowed to close tickets?

We do not allow it by default. Comments are safe; status changes should go through a human or a per-call approval. Cursor asks before running MCP tools unless you allowlist them.

Is an API key in mcp.json acceptable?

For CI, where no browser exists, yes, kept in an environment variable and interpolated with ${env:NAME}. On a laptop, prefer OAuth: the token is scoped, refreshable and revocable, and nothing long-lived sits in a file.

What is a remote MCP server?

An MCP server reached over HTTPS rather than started as a local process. It authenticates with OAuth and can be shared by a whole team. See the glossary entry for the definition and how it differs from stdio servers.

Next step

Add one server with read scopes today and run a single "implement this issue" prompt; you will know within an hour whether the comment-back step is worth enabling. If your tracker is Atrix, the Cursor integration page has the exact entry to paste, and the MCP feature page lists what each scope unlocks.