Add HTTP transport support for MCP servers

[AhegaoBurger]

What this solves

This PR adds support for HTTP and SSE (Server-Sent Events) transports to Zed's context server implementation, enabling communication with remote MCP servers. Currently, Zed only supports local MCP servers via stdio transport. This limitation prevents users from:

• Connecting to cloud-hosted MCP servers
• Using MCP servers running in containers or on remote machines
• Leveraging MCP servers that are designed to work over HTTP/SSE

Why it's important

The MCP (Model Context Protocol) specification includes HTTP/SSE as standard transport options, and many MCP server implementations are being built with these transports in mind. Without this support, Zed users are limited to a subset of the MCP ecosystem. This is particularly important for:

• Enterprise users who need to connect to centralized MCP services
• Developers working with MCP servers that require network isolation
• Users wanting to leverage cloud-based context providers (e.g., knowledge bases, API integrations)

Implementation approach

The implementation follows Zed's existing architectural patterns:

• Transports: Added HttpTransport and SseTransport to the context_server crate, built on top of the existing http_client crate
• Async handling: Uses gpui::spawn for network operations instead of introducing a new Tokio runtime
• Settings: Extended ContextServerSettings enum with a Remote variant to support URL-based configuration
• UI: Updated the agent configuration UI with an "Add Remote Server" option and dedicated modal for remote server management

Changes included

• HTTP transport implementation with request/response handling
• SSE transport for server-sent events streaming
• build_transport function to construct appropriate transport based on URL scheme
• Settings system updates to support remote server configuration
• UI updates for adding/editing remote servers
• Unit tests using FakeHttpClient for both transports
• Integration tests (WIP)
• Documentation updates (WIP)

Testing

• Unit tests for both HttpTransport and SseTransport using mocked HTTP client
• Manual testing with example MCP servers over HTTP/SSE
• Settings validation and UI interaction testing

Screenshots/Recordings

[TODO: Add screenshots of the new "Add Remote Server" UI and configuration modal]

Example configuration

Users can now configure remote MCP servers in their settings.json:

{
  "context_servers": {
    "my-remote-server": {
      "enabled": true,
      "url": "http://localhost:3000/mcp"
    }
  }
}

AI assistance disclosure

I used AI to help with:

• Understanding the MCP protocol specification and how HTTP/SSE transports should work
• Reviewing Zed's existing patterns for async operations and suggesting consistent approaches
• Generating boilerplate for test cases
• Debugging SSE streaming issues

All code has been manually reviewed, tested, and adapted to fit Zed's architecture. The core logic, architectural decisions, and integration with Zed's systems were done with human understanding of the codebase. AI was primarily used as a reference tool and for getting unstuck on specific technical issues.

Release notes:

• You can now configure MCP Servers that connect over HTTP in your settings file. These are not yet available in the extensions API.

  {
    "context_servers": {
      "my-remote-server": {
        "enabled": true,
        "url": "http://localhost:3000/mcp"
      }
    }
  }
  

[AhegaoBurger]

Yo @ConradIrwin, I took your advice and took a more targeted pass at adding HTTP-based servers to the existing code. Current version isn't very good, I actually booked a par-coding slot with you through your Calendly to ask for advice and clarification on certain things.

[oWretch]

A quick comment on the proposed configuration. Can we match the common MCP configuration (such as used by VS Code) rather than something slightly different? That way we would get:

{
  "context_servers": {
    "my-remote-server": {
      "source": "http",
      "enabled": true,
      "url": "http://localhost:3000/mcp"
    },
    "sse-server": {
      "source": "sse", 
      "enabled": true,
      "url": "https://api.example.com/context"
    }
  }
}

Also, since SSE is a deprecated technology for MCP, is there much value in spending the time to include it at this stage?

[AhegaoBurger]

Hey @oWretch, totally agree about the SSE thing, my current implementation doesn't really support sse (cause I didn't bother to finish it) and since MCP is deprecating it that makes even more sense.

Regarding the format, I'm also all for standardisation, the Cursor mcp.json is very well done and I think the other IDE's follow more or less the similar structure, the only thing from that I need to add would be headers (for putting stuff like API key and OAUTH tokens and such) and it should be done

[ConradIrwin]

@AhegaoBurger and I paired a bit on this!

• It's working, which is cool.
• We're going to:
• Simplify the settings UI to use JSON like for the custom ones
• Add support for headers
• Remove SSE placeholder

[AhegaoBurger]

So the stuff from the Todo from @ConradIrwin is done. However, I did learn one thing and that is the fact that I didn't think about adding OAuth support.
Like for example the Notion mcp server, the way you add it is:

1. Go to Notion webpage
2. Go to connections settings and choose which editor to connect to (right now they have ChatGPT, Cursor and Claude)
3. Then a webpage opens that asks your permission to open the editor you selected
4. You add the url to the editor (it basically copy pastes it for you)
5. Last thing is that the editor then sees that the server needs to complete OAuth and that would require adding the whole auth flow

OAuth Authorization Flow:

• Open browser for user to authorize
• Handle redirect with authorization code
• Exchange code for access/refresh tokens
• Store and refresh tokens automatically

So we could merge as is and then I or someone else can add the OAuth flow or I could start working on it now, just curious to hear opinions of Zedders and people who are interested

[ConradIrwin]

Let's merge without OAuth, and add that in as a second step; likely we'll need some changes to https://zed.dev which isn't yet open source

[AhegaoBurger]

Cool, so in that case is there anything needed from my side? I see there is a conflict with the context_server_store file, should I fix or what is the protocol for merge conflicts?

[ConradIrwin]

That would be fabulous if you can

[ConradIrwin]

@AhegaoBurger I've merged this with the latest main and done some cleanup throughout.

Let me know if there's anything else you wanted to do here, otherwise I'll merge.

[AhegaoBurger]

Hey @ConradIrwin, on my side I'm good. Once it's merged I'll start a new PR for OAuth support for remote servers

[ConradIrwin]

Amazing, thanks! Sorry again for the slow turnaround on this.

[AhegaoBurger]

No worries, I know you guys are busy and this isn't high on your priority list

[zcharloppowers-lila]

Awesome!

[clicktodev]

Does this first try the HTTP Stream transport and falls back to SSE if HTTP is not supported?

[AhegaoBurger]

Does this first try the HTTP Stream transport and falls back to SSE if HTTP is not supported?

SSE transport is deprecated in the MCP spec so I removed it from this PR as well along the way to just work through http

[clicktodev]

I understand it's deprecated but atlassian for example (I imagine other companies as well) still uses SSE with no plans to move to http streaming anytime soon.
I'd appreciate it if SSE support was added as a fallback similar the vscode's behavior.
Maybe i'll have a go at it myself if it's not a priority for you right now.

[AhegaoBurger]

I understand it's deprecated but atlassian for example (I imagine other companies as well) still uses SSE with no plans to move to http streaming anytime soon.

I'd appreciate it if SSE support was added as a fallback similar the vscode's behavior.

Maybe i'll have a go at it myself if it's not a priority for you right now.

Yeah, right now I'm working on adding OAuth2 to the mcp functionality so feel free to add SSE if you feel you need it. The MCP servers I use all work through http so I added http first but I also know a bunch of them were built using sse like you said. Originally when I started working on this PR I had placeholders for SSE in the earlier commits so feel free to look over those (not actual implementation but just how it was supposed to be organized) if that helps

[erenatas]

@AhegaoBurger hey, would you mind if I open a PR for OAuth? I have it working with Zed agent

[AhegaoBurger]

@AhegaoBurger hey, would you mind if I open a PR for OAuth? I have it working with Zed agent

Hey, yeah it's cool, I've been working on other projects recently so didn't have time to make this work, I'll definitely check out your PR so just tell me when you open it

[erenatas]

@AhegaoBurger see #44638

[tzutoo]

It seems the tool call timeout setting not working with http transport support.