Duplicate server

What mcp-scan saw

The scan loop builds a key per server: the url when one is present, otherwise the command joined with its arguments. A key already seen in this run produces this finding and the server is not scanned again. The dedupe set spans all detected clients, so the same server in Claude Desktop and Cursor collides.

Why it fires

The finding exists because of what it prevents: the second copy is skipped, so its findings never appear in the report. That is the real consequence, and it is why the duplicate is reported rather than silently dropped. It also flags configuration drift, since two clients pointing at the same command can diverge in their env blocks without either being obviously wrong.

When this is a false positive

• Running the same MCP server across several clients is the normal setup. One server entry copied into Claude Desktop, Cursor, and VS Code produces two of these findings and no actual problem.
• The key is command plus args only. Two entries with identical commands but different env blocks, for example a staging and a production token, collide as duplicates even though they are genuinely different servers.
• The key ignores the config key name, so renaming one entry does not separate them.

How to fix it

1. Read which two clients the report lists for that command. The duplicate result carries the client name and config path.
2. If the duplication is intentional, note that the second copy was never scanned. To get coverage on both, scan each config separately rather than in one run.
3. If two entries differ only by env, add a distinguishing argument so the dedupe key separates them and both get scanned.
4. If one copy is stale, delete it. Two configs pointing at the same command drift, and the one nobody scans is the one that drifts.
5. To suppress, add 'duplicate-server' to suppressRules in .mcp-scan.json. Note this hides the finding but does not restore the skipped scan.