Cursor-agent mcp list silently drops entire mcp.json when any entry has type: "streamable-http" (works in IDE)

,

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

cursor-agent mcp list silently drops entire mcp.json when any entry has type: “streamable-http” (works in IDE)

Summary

cursor-agent silently drops the entire mcp.json when any single entry uses "type": "streamable-http" — including unrelated stdio entries in the same file. The Cursor editor accepts streamable-http as an alias; the CLI only accepts http / sse / stdio. Users with a working IDE config hit a silent break the moment they run cursor-agent mcp list, with no diagnostic pointing at the offending entry.

Related (closed) thread describing the same “all-or-nothing” failure mode triggered at connect time:

This report is the schema-parse-time trigger of the same pattern.

Why it matters

  • Silent: no log, no error, no hint at which entry is bad.
  • Cross-cutting: a single bad entry takes down all other MCP servers in the same file, including stdio ones with no relation to HTTP transport.
  • Affects automation: any pipeline driving cursor-agent --print on a host with a normal IDE-authored mcp.json will run with zero MCP tools available and no indication why.

Steps to Reproduce

No network required.

  1. Create a fresh project dir with a minimal mcp.json containing one stdio entry and one streamable-http entry:
mkdir -p /tmp/repro/.cursor && cd /tmp/repro
cat > .cursor/mcp.json <<'JSON'
{
  "mcpServers": {
    "stdio-ok": { "command": "true" },
    "sh-bad":   { "type": "streamable-http", "url": "https://example.com/mcp" }
  }
}
JSON
  1. Run:
cursor-agent mcp list

Actual output:

No MCP servers configured (expected in .cursor/mcp.json or ~/.cursor/mcp.json)

The stdio entry stdio-ok is silently dropped along with the streamable-http one. No error, no log line names the offending entry.

  1. Rename the offending type to “http”:
sed -i '' 's/streamable-http/http/g' .cursor/mcp.json
cursor-agent mcp list

Now both entries appear:

stdio-ok: not loaded (needs approval)
sh-bad:   not loaded (needs approval)

This proves the file is otherwise valid and the failure is specific to the streamable-http type value.

Expected Behavior

One of:

  1. (preferred) CLI parser accepts “streamable-http” as an alias for “http”, matching the Cursor editor — avoids silent IDE/CLI divergence on the same mcp.json.

  2. CLI emits a parse error naming the offending server key (e.g. mcp.json: ignoring "sh-bad": unknown transport type "streamable-http"), instead of falling through to No MCP servers configured and discarding all sibling entries in the file.

In either case, a single malformed entry must NOT invalidate the rest of the file.

Operating System

MacOS

Version Information

CLI:
CLI Version 2026.04.17-787b533
Model Composer 2 Fast
Subscription Tier Ultra
OS darwin (arm64)
Shell zsh

For AI issues: which model did you use?

N/A — this is a CLI mcp.json parser bug, not a model/AI behavior issue.

For AI issues: add Request ID with privacy disabled

N/A — not a model request issue. Privacy mode is enabled on this account; no request ID applies.

Additional Information

  • The same mcp.json file works correctly in the Cursor IDE; the bug is CLI-only.
  • Reproduced from a fresh /tmp directory (no plugins, no settings, no auth state) — does not depend on the user’s home config.
  • The failure mode is identical for both global (~/.cursor/mcp.json) and project (.cursor/mcp.json) scopes.
  • Same root cause family as forum thread #142335 (closed), but triggered at JSON-schema parse time instead of network-connect time. Suggests both code paths share a catch-all that should be replaced with per-entry error isolation.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Hey, thanks for the detailed breakdown. The repro steps and suggested fixes really speed things up.

I can confirm the behavior: the CLI parser for remote MCP only accepts "http" and "sse", and the IDE ignores type and routes based on whether command or url is present. Also, if validation fails, the CLI falls back to an empty config with no logs. That’s why all neighboring servers get silently dropped, including stdio.

Temporary workaround, like you said: change "type": "streamable-http" to "type": "http" in mcp.json. It’s the same transport under the hood, so behavior is identical.

On the fix: I reported the issue internally. Two directions: add an alias streamable-httphttp in the schema, and switch to per-entry parsing with a specific error instead of a silent fallback. I can’t share an ETA yet. I’ll post an update in the thread when I have one.