How to give Cursor context about a specific customer bug report
Cursor doesn't know who filed a bug, how many other accounts hit it, or whether the reporter is a trial user or your biggest renewal this quarter. It only knows what's in the codebase and whatever you put in the prompt yourself. For a single bug, the fastest fix is pasting the ticket text into the chat before you ask Cursor to look at it. For a bug that arrived scattered across a support ticket, a Slack thread, and a sales call, the fastest fix is a connected tool Cursor can query for the pieces you didn't copy.
Both routes work. Which one is worth setting up depends on how often "let me go find the customer story first" happens between opening the ticket and opening Cursor.
What's actually missing, and why grep can't find it
A community thread on the Cursor forum gets at a version of this question from the coding side, asking how much explicit intent an agent still needs once it can already explore the codebase on its own. The consensus in that thread is that stronger models need less hand-holding on the code, because they can trace imports and infer conventions themselves. Nobody in it raises support tickets or customer accounts, and that's the tell. Codebase context and customer context are different categories of missing information, and only one of them lives in files an agent can search.
The bug ticket itself usually carries a stack trace, repro steps, maybe a screenshot. None of that says whether the account behind it is a single free-tier user or a nine-figure customer three weeks from a renewal call. That distinction changes the decision an engineer makes with the fix in hand: patch it today and tell someone, or file it for the next sprint. Cursor can write either fix. It can't tell you which one the business needs without being told.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in Notion
CursorGetting one bug's story into the prompt by hand
For a single, one-off bug, this doesn't need a tool. It needs a habit:
- Paste the ticket text directly into the chat, above or alongside the technical ask. "Customer X on the Enterprise plan reported this in Zendesk #4192, quote: [text]. Here's the stack trace." Cursor treats it as part of the prompt, same as any other context you supply.
- Drop it into a scratch file and reference it with
@Files. Cursor's@mentions pull in the contents of whatever file you point at, so anotes/ticket-4192.mdwith the ticket text, the account name, and the plan tier works the same as pasting, and it's easier to reuse if the same bug comes up again in a follow-up chat. - For something that recurs, write it into
.cursor/rules. Rules files are markdown Cursor loads automatically, either always-on or triggered by a file pattern or description, and they're meant for exactly this kind of standing fact: "the retry job for account X needs three attempts minimum, see ticket #2214." They're static, though. Nobody updates a rules file per bug; they're for the handful of facts worth keeping around.
All three get the job done for one bug at a time. The work is finding the ticket, finding the account record, and copying the right lines into the right place, every time a new bug shows up.
Where copy-paste stops being the fast option
Kessington Robotics builds fleet-management software for warehouse robots, and Isobel Tarrow is one of two backend engineers who rotate through bug triage. A ticket lands with a stack trace. A null pointer fires in the docking-station handoff logic whenever a robot's battery reports below 4% mid-route. No account name in the ticket title, just a customer ID and a repro.
Zendesk #5187, from the customer: "Our robots are stalling out at the charging dock instead of docking. Started this morning. We have a shift change in two hours and half our fleet is affected."
Isobel opens the account record to find out who this is. The account is Norrbridge Distribution, on the plan tier with a four-hour response SLA, and a note that they escalated a similar dock-handoff issue five months ago. None of that is in the ticket. She copies the account name, the SLA, and the prior incident number into her Cursor chat before asking it to trace the null pointer, because the fix she picks (a quick guard clause today versus a proper rewrite of the battery-check ordering next sprint) depends entirely on whether two hours is a real deadline or a customer being dramatic. It's real. She ships the guard clause in 40 minutes and files the rewrite as a follow-up ticket, tagged with Norrbridge's name so whoever picks it up next doesn't have to go looking again.
That one bug cost Isobel about four minutes of searching two other tools before she could even start. On a normal week she triages six or eight of these. Half an hour of tab-switching a week isn't the problem. What breaks down is that nothing about Norrbridge's SLA or the prior incident is written down anywhere Cursor, or the next engineer, can find without her doing the searching again from scratch.
Wiring an MCP server so Cursor can look it up itself
Cursor connects to MCP servers from Settings, under Cursor Settings, Tools & MCP, either through a one-click marketplace install or by adding an entry to .cursor/mcp.json (project-scoped) or ~/.cursor/mcp.json (global). Once a server is connected, Cursor's own docs describe agent mode using it automatically: "Cursor automatically uses MCP tools listed under Available Tools when relevant," and you can also ask for a specific tool by name.
That's the piece that turns Isobel's four minutes into a question inside the same chat. Modem's MCP server is one option built for this. It reads Slack, support tools, and sales calls, clusters what it finds into topics and accounts, and exposes a search_modem tool that answers a plain-language question and returns the matching rows, without spending an agent's turn on it. Setup is three steps, per Modem's MCP docs:
- In Cursor, go to Settings, Cursor Settings, Tools & MCP, and add a server.
- Point it at
https://mcp.modem.dev/mcp, with Streamable HTTP as the transport. - Authorize through the browser OAuth flow when Cursor prompts for it.
With that connected, a question like "what account is Zendesk ticket 5187 tied to, and have they hit this before" gets answered in the same chat where Isobel is already debugging, pulling from whatever Modem has already ingested, instead of a second window and a second search.
Where this fits, and where it's overkill
If bug triage happens a handful of times a month, pasting the ticket into the chat or writing the occasional line into .cursor/rules costs nothing and is the right call; setting up an MCP server for that volume is more infrastructure than the problem needs. Past a few of these a week, spread across a team where the same account context gets rediscovered by whoever happens to pick up the next related ticket, that's the point a connected server starts paying for itself. That's the exact gap Modem is built to close, and it's what we build, so weigh the recommendation with that in mind. The tradeoffs against .cursor/rules, Linear's MCP server, and other single-source options are laid out directly in the six best tools to give Cursor customer context, and the related gap in Cursor's own codebase search is covered in why codebase context disappears in agent mode.
Start with the next ticket you open
Before you paste a stack trace into Cursor, paste one more line above it, saying who's affected and how urgent it actually is. That single habit is free, and it's the same fact an MCP server would otherwise have to fetch for you. If you notice you're writing a version of that line more than once or twice a week, that's your signal that it's time to connect something that can answer it for you.
