Zed MCP: read support tickets and draft replies without leaving your editor

You are deep in a refactor in Zed, and somewhere in a browser tab there are four unread support conversations. One of them probably describes the exact bug you are fixing right now. The context you need lives in your inbox; the fix lives in your editor. Switching between the two fifty times a day is how afternoons disappear.

Zed ships with an agent panel that speaks MCP (Model Context Protocol), which means you can plug external tools straight into the assistant. muro exposes a hosted MCP server for exactly this: your support inbox becomes something the agent can query. Ask what users reported this week, pull a full thread, fix the bug it describes, and draft the reply, all inside the editor. Setup takes about ten minutes. Here is the whole thing.

How MCP works in Zed

Zed calls MCP servers context servers. You register them in your settings.json (the zed: open settings action in the command palette gets you there), and the agent panel picks up whatever tools each server exposes. Some servers arrive as Zed extensions; custom ones, like muro's, you declare by hand with a command that Zed spawns in the background.

One wrinkle: Zed launches MCP servers as local processes talking over stdio, while muro's server is hosted at https://muro.chat/api/mcp. The bridge is mcp-remote, a small npm package that runs locally, forwards stdio traffic to the remote URL, and passes along your auth header. Nothing to install permanently; npx pulls it on demand.

Step 1: create a scoped API key in muro

You need a muro account with at least one site. A site is one project or product: its own widget, its own inbox, its own settings. If you do not have one yet, signup takes a minute and the 14-day trial does not ask for a card.

In the muro dashboard, create an API key for the site you want the agent to see. Two decisions matter here:

• →Scope by site. Keys in muro are scoped per site, so a key minted for your SaaS cannot read your client project's inbox. This is the core of the whole setup: one key per project.
• →Read or read/write. A read-only key lets the agent list conversations and pull threads. That is safe, and enough for the debugging workflow. A read/write key also lets it post replies. Start read-only if you are cautious; upgrade the scope once you trust the loop.

Copy the key. It looks like mr_live_ followed by a random string, and muro shows it once. Key management and the full endpoint reference live in the API docs.

Step 2: register muro as a context server

Open Zed's settings.json and add a context server entry that shells out to mcp-remote:

json{
  "context_servers": {
    "muro": {
      "command": {
        "path": "npx",
        "args": [
          "-y",
          "mcp-remote",
          "https://muro.chat/api/mcp",
          "--header",
          "Authorization: Bearer mr_live_YOUR_KEY"
        ]
      }
    }
  }
}

Restart Zed (or toggle the server off and on in the agent panel's settings view) and open the agent panel. The muro server should appear with its tools: listing recent conversations, reading full threads, and, if your key has write scope, posting replies. If you see an error state instead, jump to the troubleshooting section below.

Step 3: the actual workflow

Here is the loop as it plays out on a normal morning, before you have opened anything except your editor.

Ask what came in

The agent calls the muro server, pulls recent conversations, and summarizes them. No tab switch, no scanning an inbox UI. Three separate people mentioning a broken webhook signature stops looking like three tickets and starts looking like one bug with three witnesses.

Read the thread that matters

Pick the conversation that describes the bug and ask for the full thread. The agent fetches every message, including what muro's AI auto-reply already told the user and the point where it handed off to a human. That detail matters: the AI answers from your published help articles and hands off when it is unsure, so the thread shows you exactly what the user was told and what they were promised.

Fix the bug with the report in context

This is where Zed earns its keep. The user's report now sits in the agent's context right next to your code. Ask it to find the code path the user is describing: the user says CSV exports drop rows with commas in the name field, find where we generate exports and check the escaping. The agent has the symptom from the thread and the source from your project. That combination is the entire point of this setup, and it is surprisingly hard to replicate by pasting ticket fragments into a chat window.

Draft the reply

Once the fix is committed, ask the agent to draft a reply on the original conversation: what was wrong, what changed, when it ships. With a read/write key it can post that reply straight to the thread. With a read-only key it drafts the text and you paste it into the muro inbox yourself. Either way, you closed the loop on a support ticket without opening the inbox once during the debugging session.

One key per project, one inbox per repo

If you run several products, or client sites, scoping is where this setup gets quietly great. Zed supports per-project settings in a .zed/settings.json file inside the repo. Register the muro context server there instead of in your global settings, using that project's site key, and the agent in each repo only ever sees that product's inbox. Open your SaaS repo and ask about tickets: you get SaaS tickets. Open the client project and ask the same question: you get that client's tickets. No mental bookkeeping, no wrong-inbox accidents.

This maps cleanly onto how muro is priced, too. Solo covers up to 2 projects at $19/mo, Fleet is $59/mo for unlimited projects, and both come with unlimited agents, so giving a teammate inbox access never costs a seat. Details on the pricing page.

Troubleshooting

• →The server never starts. Zed spawns npx directly, and GUI-launched apps sometimes get a different PATH than your shell. If npx cannot be found, put its absolute path in the config instead (run which npx, or where npx on Windows, to find it).
• →401 Unauthorized. The header must be exactly Authorization: Bearer mr_live_yourkey, with one space between Bearer and the key. Also confirm the key was not revoked and belongs to the site you think it does.
• →Tools appear but calls fail. Usually a scope problem: a read-only key trying to post a reply. Mint a read/write key for that site and swap it in.
• →Config errors after a Zed update. The context server settings shape occasionally shifts between Zed releases. Compare your block against the current Zed docs and keep the mcp-remote command and arguments unchanged.

If you want a known-good starting point, the open-source repo at github.com/Muro-chat/muro-mcp collects ready-made client configs for MCP-capable editors and assistants, plus notes on scopes and headers. If your config looks meaningfully different from the samples there, that is the first diff to check.

The whole integration is one API key and one settings block. Create a site in muro, paste the widget snippet on your product, and point the AI at your docs by importing a URL so it can answer the easy questions on its own. Then register the MCP server in Zed, and your support inbox becomes just another tool your editor can call. If you want to poke at the inbox side first, the live demo is open, no account needed.