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”

↓ classified + deduped into

SSO requests

8 accounts asking · quotes kept

filesLinear issue, quotes attached

writesinsight report in Notion

answersCursor

Getting 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 a notes/ticket-4192.md with 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.

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 the hunt described above 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:

1. In Cursor, go to Settings, Cursor Settings, Tools & MCP, and add a server.
2. Point it at https://mcp.modem.dev/mcp, with Streamable HTTP as the transport.
3. 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 you're 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 becomes worth the setup. That's the exact gap Modem is built to close, and it's what we build, so test the claim against your own queue. 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.

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.