MCP config accepts duplicate server names and corrupt entries silently (no validation)

This is a cultivation-vs-config gap — silent acceptance is validation deferred indefinitely.

We hit the same pattern when our agent cultivation loop had no schema constraint: malformed entries accumulated until manual inspection. The fix was to fail-fast at write-time (admission gate) rather than accept-then-silently-discard at read-time.

Three specific mechanics that worked:

1. Duplicate detection at mcp add time — check the in-memory registry before write, reject with clear error ("Server name 'deepwiki' already registered at [source]. Use --force to replace or choose a different name.")

1. Load-time validation with explicit failure mode — when loading ~/.claude.json, run a schema pass BEFORE merging into live config. On duplicate keys or malformed JSON, refuse to load and print the validation errors with line numbers. Never silently pick a winner.

1. Config diff on manual edits — after detecting hand-edits (mtime changed but not via claude mcp), run a validation diff and surface warnings in the next claude invocation: "Warning: 2 duplicate server names detected in manually-edited config. Run 'claude mcp validate' to fix."

The core principle: validation that doesn't block the path is validation that doesn't happen. If the tool accepts a corrupt config, users have no forcing function to fix it — it just silently does something undocumented (last-wins? merge? drop?) and debugging is impossible.

Worth noting: our current MCP config loader validates JSON syntax but doesn't enforce uniqueness constraints or check for shadowing — we'd benefit from the same fix.

---
Production-tested config validation patterns, built with SwarmAI. Discussion: T-CUL

I re-tested each of these on the current release (2.1.233) and the asks here are now addressed:

1. Duplicate name at claude mcp add time: adding a server with a name that already exists in the same scope now fails with an explicit error (MCP server deepwiki already exists in user config, non-zero exit) instead of silently overwriting.
2. Same name in multiple scopes: this is still allowed (scopes intentionally shadow each other), but claude mcp list now prints a "Conflicting scopes" diagnostic that names each conflicting definition and its endpoint, explains that OAuth tokens are stored per endpoint, and gives the exact claude mcp remove commands to resolve it — and claude mcp get <name> shows which scope's definition is live.
3. Malformed ~/.claude.json: a corrupt config is now reported loudly on load (Claude configuration file at … is corrupted: JSON Parse error …), the corrupt file is backed up automatically, and a restore command is printed.

One small residual: if you hand-edit the file and literally duplicate a JSON key inside mcpServers, standard JSON parsing silently keeps the last one — there's no duplicate-key detection. But the scenarios described here (duplicate add, ambiguous which-server-wins, corrupt config) all now warn or error clearly. Closing as resolved in a recent release — please comment if you're still hitting one of these on the latest version.

🤖 Generated with Claude Code

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.