feat: Add HTTP Streaming transport support for MCP servers

[z80dev]

Summary

This PR expands OpenCode's MCP (Model Context Protocol) server support by adding HTTP Streaming as a transport option alongside the existing SSE (Server-Sent Events) implementation. HTTP Streaming provides a more reliable and performant alternative for MCP server communication.

Why HTTP Streaming over SSE?

While SSE has served well as the initial transport protocol, HTTP Streaming offers several advantages:

1. Better Error Handling: HTTP Streaming provides clearer error states and recovery mechanisms compared to SSE's limited error handling capabilities
2. Reduced Latency: Direct streaming without the overhead of SSE's event framing and reconnection logic
3. Simpler Implementation: No need for EventSource polyfills or SSE-specific server configurations
4. Better Proxy Support: Works more reliably through corporate proxies and firewalls that may block or interfere with SSE connections
5. Standardization: As MCP adoption grows, HTTP Streaming is becoming the preferred transport method in tools like Claude Code and other LLM tooling

Changes

1. Configuration Schema Update

Based on community feedback, we've simplified the configuration by using the type field to specify both the connection type and transport protocol:

type: z
  .enum(["remote", "sse", "http"])
  .describe("Type of MCP server connection and transport protocol (remote is alias for sse)")

• "remote" - Kept as an alias for SSE to maintain backward compatibility
• "sse" - Explicitly uses SSE transport
• "http" - Uses HTTP Streaming transport

2. MCP SDK Version Override

Added a version override for @modelcontextprotocol/sdk to 1.13.2 in package.json. This was necessary because:

• OpenCode's dependencies specify an outdated version of the MCP SDK (1.6.1)
• The StreamableHTTPClientTransport class we need for HTTP Streaming support was introduced in later versions
• Version 1.13.2 includes the necessary HTTP Streaming transport implementation while maintaining backward compatibility

3. Transport Selection Logic

Updated the MCP client initialization to support the new type values:

if (mcp.type === "http") {
  transport = new StreamableHTTPClientTransport(new URL(mcp.url))
} else {
  // SSE transport (for both "remote" and "sse")
  transport = {
    type: "sse",
    url: mcp.url,
  }
}

Usage

Users can now specify the transport method directly in the type field:

SSE Transport (default):

{
  "mcp": {
    "myserver": {
      "type": "sse",
      "url": "https://my-mcp-server.com"
    }
  }
}

HTTP Streaming Transport:

{
  "mcp": {
    "myserver": {
      "type": "http",
      "url": "https://my-mcp-server.com"
    }
  }
}

Backward Compatible (uses SSE):

{
  "mcp": {
    "myserver": {
      "type": "remote",
      "url": "https://my-mcp-server.com"
    }
  }
}

Testing

• Tested with SSE, HTTP Streaming, and remote (SSE alias) transports
• Verified backward compatibility with existing "remote" configurations
• Confirmed successful connection and operation with HTTP Streaming servers
• All TypeScript checks pass

Impact

This change is fully backward compatible. Existing configurations using type: "remote" will continue to work as before, using SSE transport. Users can opt into HTTP Streaming by setting type: "http".

[thdxr]

is there any way to autodetect this?

[z80dev]

maybe by trying to make a request and falling back to sse if it fails, but that's kinda hacky. I tried to prototype that and kept getting 400 errors so I probably just wasnt forming the request body properly for that "test request"

fwiw claude code and all the other tools I checked make you specify sse vs. streaming http explicitly

[JonnyBGod]

Why not reusing the type field and instead of remote, accept: sse, http and http+sse?

{
  "mcp": {
    "myserver": {
      "type": "http",
      "url": "https://my-mcp-server.com"
    }
  }
}

[z80dev]

yeah thats actually a really good point, specially because I run local mcp servers that communicate over http so "remote" isnt fully accurate to describe the "type" of mcp server

what do you think @thdxr ?

[z80dev]

hey @thdxr anything you want changed in this PR? I use this feature a lot and am hoping to get back to using the main release so I can get updates more easily

[thdxr]

we ended up fixing this in a different way - thank you for the contribution though