How to read support tickets in Windsurf with MCP

Windsurf's Cascade can read your whole repo, run your tests, and refactor across twenty files. It has no idea what your users are complaining about. So you do the shuttle run: open the support inbox in a browser tab, read the ticket, alt-tab back to the editor, and retype the bug report into the chat panel. Every detail that gets dropped on the way (the exact error text, the page the visitor was on, the third message where they mention it only happens on Safari) is a detail the agent now has to guess.

There is a cleaner way. muro ships a hosted MCP server, and Windsurf speaks MCP through one small JSON file. Wire them together and your support inbox becomes a tool Cascade can call, the same way it reads files or greps the codebase. You ask what users are complaining about today, it pulls the real conversations, and you fix the bug without leaving the editor. This is the complete setup for reading support tickets in Windsurf over MCP: one API key, one config entry, and a couple of prompts that do the heavy lifting.

What Cascade gets when you connect the inbox

The Model Context Protocol (MCP) is an open standard that gives an AI agent typed tools it can call on external systems. Your editor's agent already has tools for reading files and running commands. An MCP server adds new ones. muro hosts its server at https://muro.chat/api/mcp, so there is nothing to deploy or keep alive on your machine. Once connected, Cascade sees a small set of inbox tools:

• →list_conversations finds threads by status, tag, or full-text search, so "what came in today" is a single call.
• →get_conversation returns the entire thread, every message included, not a lossy summary.
• →send_reply posts an answer to the visitor, or an internal note for your team.
• →update_conversation handles triage: status, tags, assignment.
• →list_contacts and get_contact tell the agent who it is talking to.

What the agent can actually do is governed by the key you mint. A read scope lets Cascade look but never touch, which is the right way to start. Add write scope later and it can draft replies and triage threads, with you approving before anything reaches a customer.

Prerequisite: a muro site with real conversations

If muro already runs on your product, skip to step 1. If not, create a site in the dashboard and paste the widget before the closing </head> tag. It is a single async script, about 6 KB, so it will not touch your load times:

html<script>
  (function(w,d,s,o){
    w.MuroChat=o;w[o]=w[o]||function(){(w[o].q=w[o].q||[]).push(arguments)};
    var j=d.createElement(s);j.async=1;j.src='https://muro.chat/widget.js';
    d.getElementsByTagName('head')[0].appendChild(j);
  })(window,document,'script','muro');
  muro('init',{widgetId:'YOUR_WIDGET_ID'});
</script>

Out of the box, the AI answers visitors from your published help articles and hands the thread to a human when it is unsure, which is exactly when bugs surface: refunds, account issues, or someone getting genuinely angry. Those handed-off threads are what you are about to read from inside Windsurf. You can watch the handoff happen on the live demo.

Step 1: mint a per-site API key

In the muro dashboard, create an API key and scope it to the site this repo belongs to. This is the part worth being deliberate about. muro keys are scoped per site, so a key minted for your invoicing app can only ever see the invoicing app's tickets. Your other products stay invisible to it. Pick read scope for now. The key looks like mr_live_... and is shown once, so copy it immediately.

Step 2: add muro to Windsurf's mcp_config.json

Windsurf reads MCP servers from a file called mcp_config.json, which lives at ~/.codeium/windsurf/mcp_config.json. You can edit it directly, or open Windsurf's settings and look for the MCP servers section under Cascade, which opens the same raw config. Windsurf launches MCP servers as local processes, and muro's server is remote, so the bridge is mcp-remote, a small npx package that forwards everything to the hosted endpoint with your key attached. The only requirement on your machine is Node.

json{
  "mcpServers": {
    "muro": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://muro.chat/api/mcp",
        "--header",
        "Authorization: Bearer mr_live_PASTE_YOUR_KEY"
      ]
    }
  }
}

Save the file, then hit the refresh button in Cascade's MCP toolbar so it picks up the new server. The first run downloads mcp-remote through npx, connects, and the muro tools appear in Cascade's tool list. If nothing shows up, the usual suspects are Node missing (npx -v should print a version) or a stray character in the Authorization header. Fix, refresh, done.

Step 3: ask what users are complaining about

Open Cascade in the repo and type something like: what are users complaining about in muro today? Then watch the loop run:

1. 01Cascade calls list_conversations and pulls the open threads from the last day.
2. 02It summarizes the patterns: three visitors stuck on checkout, one asking about CSV export, one nudging an old thread.
3. 03You point at the checkout one. It calls get_conversation and reads the full thread, including the exact validation error and the URL the visitor was on.
4. 04With the symptom in context, it searches the repo, finds the postal code regex that rejects valid Dutch codes, and proposes a diff.
5. 05You review, apply, run the tests, and deploy. The bug went from reported to fixed without the inbox tab ever opening.

The point is not that the agent got smarter. It is that it finally read the primary source. The detail that pins a bug down is usually buried three messages into the thread, and that is precisely the detail that evaporates when a human paraphrases a ticket from memory into a chat box.

Add write scope when you want drafts

Once the read loop feels normal, mint a key with write scope and swap it into the config. Now the same session can finish the job: ask Cascade to draft a reply telling the visitor the fix is deployed, review the wording, and let it send. It can also tag the thread and mark it resolved. Keep the human review step. Write scope is a power tool, and customers can tell the difference between a reply you checked and one you did not.

A few prompts that earn their keep once the connection is live:

• →"List open conversations and group them by feature area."
• →"Read the newest handed-off thread and try to reproduce the issue against the local dev server."
• →"Which open threads mention the new onboarding flow?"
• →"Draft replies for every thread that has been waiting on us for more than a day, and show me each one before sending."

Why this beats the browser tab

Support and shipping are usually two different jobs done in two different tools, and the context dies in transit between them. This setup collapses the two: the agent that writes your fix is the same agent that read the complaint, verbatim. For a solo founder or a two-person team, that means support stops being the thing that interrupts building and becomes an input to it. And because muro's MCP server and REST API are included on every plan, with unlimited agents and no per-seat pricing, connecting your editor costs nothing extra. If you would rather script the same tools over HTTP, the API docs cover the matching endpoints.

Thirty seconds of security

• →The key sits in a config file in your home directory, not in the repo, so it stays out of version control by default. Keep it that way.
• →Site-scoped keys cap the blast radius. One product per key, always.
• →Start read-only. Add write scope only once you have a review habit for outgoing drafts.
• →Rotate a key from the dashboard the moment you suspect a leak. Revocation is instant.

That is the whole setup: create a site in muro, paste the snippet, and point the AI at your docs by importing your help center URL so it answers the easy tickets on its own. Then drop one entry into mcp_config.json and the hard tickets follow you into Windsurf, where the fix actually happens. You can start free with a 14-day trial, no card needed, and be asking Cascade what users are complaining about before lunch.