MCP config sprawl is what happens when the same server ends up in several agent and project config files.
It usually starts with one reasonable copy from Claude Code to Cursor. Months later, nobody remembers which copy is current.
TL;DR: Do not delete a duplicate until you know its scope and settings. Build the inventory first, then clean up one server at a time.
Why Claude and Cursor create separate copies
Claude Code and Cursor do not share a source of truth.
- Claude Code uses
~/.claude.jsonand can use a project.mcp.json. - Cursor uses
~/.cursor/mcp.jsonand can use a project.cursor/mcp.json.
Copy a server between them and you now own two definitions. That is fine when it is deliberate. It becomes sprawl when the copies are forgotten.
The duplicate patterns to look for
The same server name can hide different commands, URLs, or environment values. Watch for:
- Identical copies in different agents.
- The same name with different settings.
- The same command with different environment values.
- A user-level copy and an old project-level copy.
The last one is the easiest to miss, because the project config can take precedence while you are testing.
A safe manual cleanup
- Find every relevant user and project config.
- Group entries by name, command, and endpoint.
- Compare differences before touching any file.
- Back up every file you plan to change.
- Keep one entry per intended scope.
- Test the result in the affected agent.
Use MCP config file locations and formats to find the user and project files before you start.
When an inventory tool helps
You can handle a small setup with files and a careful checklist. A tool earns its place when the hard part is seeing the whole picture: repeated servers, overlapping scopes, and small differences that are easy to miss across files.
The goal is not background syncing. It is a clear inventory and a safer review before edits. That is exactly what BFrost’s feature set covers, locally and without an account.
FAQ
Is config sprawl only about duplicate servers?
No. It also covers scattered scopes, mismatched settings, and poor visibility into where a server comes from.
Can I just delete every duplicate and keep one?
Only once you know which copy is current and whether another copy is intentionally scoped to a project.
Which is more confusing: the same name or the same command?
The same name with different settings is more confusing. The same command with different settings is more dangerous.
Does BFrost automatically sync every config in the background?
No. It handles local discovery, inventory, copying, cleanup, and safer writes rather than background sync.