MCP config: HTTP server entry with `url` but no `type` is silently dropped — no warning, even under --strict-mcp-config

Summary

An MCP server entry of the form {"mcpServers": {"myserver": {"url": "http://127.0.0.1:33221/mcp"}}} (a url but no "type": "http") is silently dropped: the CLI starts normally, mcp_servers in the stream-json init event is [], no MCP tools are offered to the model, exit is clean, and nothing on stdout/stderr indicates the entry was rejected. Adding "type": "http" to the same entry connects immediately and offers the server's tools.

Repro (CLI 2.1.198, Windows)

# config A (silently dropped)
echo '{"mcpServers":{"myserver":{"url":"http://127.0.0.1:33221/mcp"}}}' > mcp-a.json
claude -p "Reply OK" --output-format stream-json --verbose --strict-mcp-config --mcp-config mcp-a.json
# init event: "mcp_servers": []  — no warning anywhere

# config B (works)
echo '{"mcpServers":{"myserver":{"type":"http","url":"http://127.0.0.1:33221/mcp"}}}' > mcp-b.json
claude -p "Reply OK" --output-format stream-json --verbose --strict-mcp-config --mcp-config mcp-b.json
# init event: "mcp_servers": [{"name": "myserver", "status": "connected"}] + tools offered

(Server used for the repro is a local Streamable-HTTP MCP server; behavior is independent of the server since config A never attempts a connection.)

Why this is worth a warning/error

• The failure is invisible at every observable layer: clean exit, normal output, empty mcp_servers, no stderr. In automated/headless use (-p), there is no interactive /mcp panel where a user might notice.
• --strict-mcp-config explicitly signals "this config is the complete, intended tool surface" — silently reducing that surface to nothing defeats the flag's purpose. An invalid/ambiguous server entry under strict mode arguably should be a hard error; at minimum a stderr warning naming the dropped entry.
• Real-world cost: in our automated evaluation harness this shape ran for weeks across multiple sessions and reviews — every "with-MCP" condition silently executed with no MCP tools, invalidating the measurements (caught only by auditing per-tool-call traces). A one-line warning would have surfaced it on day one.

Expected behavior

Either accept url-only entries by inferring the transport, or reject the entry loudly (error under --strict-mcp-config, warning otherwise), naming the server and the missing field.