Repository navigation
Description
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/mcpweb-reader:https://open.bigmodel.cn/api/mcp/web_reader/mcpzread: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-streamheaderAuthorization: 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
-
Respect
typeconfiguration: OpenCode should always use the explicitly configuredtypevalue and not auto-detect based on command content. -
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 responseLabels: bug, mcp, configuration, transport
Plugins
OpenCode version
1.2.24
Steps to reproduce
No response
Screenshot and/or share link
Steps to Reproduce
-
Add a remote MCP server configuration with
type: localusing 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" ] } } } -
Start OpenCode
-
Check the logs at
~/.local/share/opencode/log/opencode.log -
Observe that the server is detected as
type=remoteinstead oftype=local
Operating System
macOS 15 (Darwin 25.0.0, arm64)
Terminal
iTerm2 & opencode client
Activity
SoraYama commentedon Mar 16, 2026
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:
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.