Bug: Remote MCP servers fail with "Invalid content type, expected 'text/event-stream'" even when using mcp-remote proxy

[SoraYama]

Description

Description

Remote MCP servers (specifically 智谱 Coding Plan MCP servers) fail to connect with SSE error:

Invalid content type, expected "text/event-stream"

This occurs even when configuring the servers as type: local with mcp-remote as a proxy, which should bypass the native remote transport handling.

Root Cause Analysis

After extensive investigation, I discovered that OpenCode ignores the type: local configuration when a URL is present in the command array. The logs show type=remote found even though the configuration explicitly specifies type=local.

Evidence

Configuration (~/.config/opencode/opencode.json):

{
  "mcp": {
    "web-search-prime": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "mcp-remote",
        "https://open.bigmodel.cn/api/mcp/web_search_prime/mcp",
        "--header",
        "Authorization: Bearer <API_KEY>",
        "--transport",
        "http-only"
      ]
    }
  }
}

Log Output (~/.local/share/opencode/log/opencode.log):

INFO  2026-03-12T09:09:32 +9ms service=mcp key=web-search-prime type=remote found

Notice the log shows type=remote found despite type: local in the config.

mcp-remote Works When Tested Directly

When running the mcp-remote command directly in the terminal, it works perfectly:

$ npx -y mcp-remote "https://open.bigmodel.cn/api/mcp/web_search_prime/mcp" \
    --header "Authorization: Bearer <API_KEY>" \
    --transport http-only

[47754] Using transport strategy: http-only
[47754] Connected to remote server using StreamableHTTPClientTransport
[47754] Local STDIO server running
[47754] Proxy established successfully between local STDIO and remote StreamableHTTPClientTransport

This proves the mcp-remote proxy itself works correctly, but OpenCode's configuration parsing is broken.

Related Issues

• Remote MCP: StreamableHTTPClientTransport missing Accept: text/event-stream header (406 from SSE-over-POST servers) #15103 - Missing Accept header for SSE-over-POST servers (fixed)
• Remote MCP servers using Server-Sent Events (SSE) fail to start with 'UnknownError Server error' #834 - Remote MCP SSE servers fail to start (closed)
• fix(mcp): connection hangs with non-standard SSE/HTTP servers which causes opencode to hang #8406 - Connection hangs with non-standard SSE/HTTP servers (open)
• Unauthenticated streamable HTTP MCP servers are reported as SSE errors instead of missing auth #16247 - Unauthenticated Streamable HTTP servers reported as SSE errors (open)

However, this issue is different: OpenCode is actively ignoring the user's type: local configuration and auto-detecting based on URL presence.

Expected Behavior

OpenCode should respect the type: local configuration and spawn the command as a local process, regardless of whether URLs appear in the command arguments.

Actual Behavior

OpenCode auto-detects the server as type=remote when a URL is present in the command, ignoring the explicit type: local configuration, leading to SSE connection failures.

Environment

• OpenCode Version: 1.2.24
• OS: macOS 15 (Darwin 25.0.0, arm64)
• Node.js: v22.18.0
• npm: 10.9.3

MCP Server Details

The MCP servers are from Zhipu Coding Plan (z.ai's coding assistant platform):

• web-search-prime: https://open.bigmodel.cn/api/mcp/web_search_prime/mcp
• web-reader: https://open.bigmodel.cn/api/mcp/web_reader/mcp
• zread: https://open.bigmodel.cn/api/mcp/zread/mcp

These servers use Streamable HTTP transport (MCP protocol version 2025-03-26) and require:

• Accept: application/json, text/event-stream header
• Authorization: Bearer <API_KEY> header

Workaround Attempted

Following the workaround from #15103, I configured mcp-remote as a local proxy:

{
  "mcp": {
    "web-search-prime": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "mcp-remote",
        "https://open.bigmodel.cn/api/mcp/web_search_prime/mcp",
        "--header",
        "Authorization: Bearer <API_KEY>",
        "--transport",
        "http-only"
      ]
    },
    "web-reader": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "mcp-remote",
        "https://open.bigmodel.cn/api/mcp/web_reader/mcp",
        "--header",
        "Authorization: Bearer <API_KEY>",
        "--transport",
        "http-only"
      ]
    },
    "zread": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "mcp-remote",
        "https://open.bigmodel.cn/api/mcp/zread/mcp",
        "--header",
        "Authorization: Bearer <API_KEY>",
        "--transport",
        "http-only"
      ]
    }
  }
}

This workaround does not work because OpenCode ignores the type: local configuration.

Log Excerpts

Config Loading

INFO  2026-03-12T09:09:31 +4ms service=config path=/Users/sorayama/.config/opencode/opencode.json loading
INFO  2026-03-12T09:09:31 +0ms service=config path=/Users/sorayama/.opencode/opencode.json loading

MCP Detection (Incorrect)

INFO  2026-03-12T09:09:32 +1ms service=mcp key=web-reader type=remote found
INFO  2026-03-12T09:09:32 +0ms service=mcp key=zread type=remote found
INFO  2026-03-12T09:09:32 +9ms service=mcp key=web-search-prime type=remote found

Working Local Server (Correct)

INFO  2026-03-12T09:09:32 +1ms service=mcp key=zai-mcp-server type=local found
...
INFO  2026-03-12T09:09:36 +5ms service=mcp key=zai-mcp-server toolCount=8 create() successfully created client

Working Remote Server (Different Provider)

INFO  2026-03-12T09:09:32 +9ms service=mcp key=websearch type=remote found
...
INFO  2026-03-12T09:09:33 +478ms service=mcp key=websearch transport=StreamableHTTP connected
INFO  2026-03-12T09:09:34 +416ms service=mcp key=websearch toolCount=1 create() successfully created client

Note: websearch from oh-my-opencode plugin works fine, but 智谱's servers don't - possibly due to different Accept header requirements.

Suggested Fix

1. Respect type configuration: OpenCode should always use the explicitly configured type value and not auto-detect based on command content.

2. Alternative: If auto-detection is intentional, provide a way to force a specific transport type, such as:

   {
     "mcp": {
       "server-name": {
         "type": "local",
         "forceType": true,
         "command": [...]
       }
     }
   }

Additional Context

The MCP servers that fail are from Zhipu Coding Plan, a Chinese AI coding assistant platform similar to GitHub Copilot. The servers implement the MCP protocol correctly using Streamable HTTP transport.

Direct curl test confirms the servers work correctly:

curl -X POST "https://open.bigmodel.cn/api/mcp/web_search_prime/mcp" \
  -H "Accept: application/json, text/event-stream" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <API_KEY>" \
  -d '{"jsonrpc":"2.0","method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}},"id":1}'

# Returns valid JSON response

---

Labels: bug, mcp, configuration, transport

Plugins

oh-my-opencode@3.11.2

OpenCode version

1.2.24

Steps to reproduce

No response

Screenshot and/or share link

Steps to Reproduce

1. Add a remote MCP server configuration with type: local using mcp-remote proxy:

   {
     "mcp": {
       "test-server": {
         "type": "local",
         "command": [
           "npx",
           "-y",
           "mcp-remote",
           "https://example.com/api/mcp",
           "--header",
           "Authorization: Bearer <TOKEN>",
           "--transport",
           "http-only"
         ]
       }
     }
   }

2. Start OpenCode

3. Check the logs at ~/.local/share/opencode/log/opencode.log

4. Observe that the server is detected as type=remote instead of type=local

Operating System

macOS 15 (Darwin 25.0.0, arm64)

Terminal

iTerm2 & opencode client

[SoraYama]

Closing this — the root cause was on my side, not an opencode bug. Sorry for the noise!

After deeper investigation, I found that the issue was caused by my local configuration interacting with the oh-my-opencode plugin's MCP loading pipeline:

1. I had previously configured Zhipu MCP servers in ~/.claude.json via npx @z_ai/coding-helper. These are stored in Claude Code format ("type": "http").
2. When oh-my-opencode is enabled, its claude-code-mcp-loader reads ~/.claude.json, transforms type: "http" → type: "remote", and injects them into the opencode MCP config. This is why my opencode.json type: "local" config appeared to be "ignored" — it was being overwritten by the plugin's merged config from ~/.claude.json.
3. The transformed config didn't include oauth: false, so opencode's OAuth auto-discovery interfered with the StreamableHTTP connection to Zhipu's servers, causing a fallback to SSE transport — which these servers don't support for GET requests, hence the "Invalid content type" error.
   Fix: Adding "claude_code": { "mcp": false } to oh-my-opencode.jsonc to disable loading MCP configs from ~/.claude.json resolved the issue completely.
   Apologies for the misleading report — the "type being ignored" was actually correct opencode behavior; it was the plugin silently overriding my config. Should have investigated the plugin layer more thoroughly before filing. Thanks to the maintainers for looking into this.