क्या डुप्लिकेट MCP सर्वर रजिस्ट्रेशन दो बार चल रहे हैं?

डुप्लिकेट MCP रजिस्ट्रेशन शायद ही कभी केवल कॉन्फ़िगरेशन की बेकार गड़बड़ी होता है। जब दो एंट्रियाँ अलग नामों के तहत एक ही सर्वर का विवरण देती हैं, तो एजेंट को एक ही capability तक पहुँचने के दो रास्ते मिल सकते हैं। stdio के साथ इसका अर्थ अक्सर दो child process होता है। रिमोट एंडपॉइंट के साथ दो authenticated connections, दो tool inventories और एजेंट के गलत call करने की दो स्वतंत्र जगहें बन सकती हैं।

परेशानी यह है कि config precedence इस तरह की समस्या हल नहीं करता। Precedence केवल यह तय करता है कि नाम के आधार पर एंट्रियाँ टकराने पर क्या होगा। वह यह नहीं बताता कि repo-api, internal-api और my-api एक ही executable और एक ही account के तीन नाम हैं या नहीं। Registration identity को naming concern नहीं, operational concern समझें।

डुप्लिकेट रजिस्ट्रेशन अलग-अलग execution path बनाते हैं

दो अलग MCP सर्वर एंट्रियाँ एक ही चीज़ को दो बार शुरू कर सकती हैं, क्योंकि क्लाइंट रजिस्ट्रेशन को connection definition मानता है, ऐसे alias नहीं जिन्हें deduplicate करना चाहिए। MCP transport specification के अनुसार क्लाइंट stdio सर्वर को subprocess के रूप में शुरू करता है और उस प्रोसेस के standard input और output पर JSON-RPC का आदान-प्रदान करता है। अगर दो configured entries एक ही command चलाती हैं, तो सामान्य परिणाम दो subprocess होते हैं, जिनका initialization और lifetime अलग होता है।

इसका अर्थ यह नहीं कि एजेंट हर टूल को यांत्रिक रूप से दो बार चलाएगा। मॉडल तय करते हैं कि कौन सा exposed tool call करना है। व्यवहार में जोखिम इससे अधिक जटिल है: एजेंट दोनों रजिस्ट्रेशन से मिलते-जुलते विवरण वाले टूल देख सकता है, पहली turn में एक और retry पर दूसरा call कर सकता है, या दोनों का इस्तेमाल कर सकता है क्योंकि उनके नाम अलग जिम्मेदारियाँ बताते हैं। पहली tool call से पहले ही server startup के side effects हो सकते हैं।

मैंने ऐसे सर्वर देखे हैं जो initialization path देखने तक निष्क्रिय लगते हैं। वे access token refresh करते हैं, cache directory बनाते हैं, स्थानीय SQLite database खोलते हैं, index को तैयार रखने के लिए polling loop शुरू करते हैं या webhook consumer register करते हैं। इनमें से कोई भी चुनाव MCP का उल्लंघन नहीं है। समस्या तब बनती है जब टीम मान लेती है कि «MCP server» एक साझा, निष्क्रिय object होता है।

Remote server failure का रूप बदलता है, उसे रोकने की ज़रूरत नहीं। Streamable HTTP एक स्वतंत्र server process के लिए बनाया गया है जो कई client connections संभाल सके। जब कई clients जानबूझकर इस्तेमाल किए जाएं तो यह उपयोगी है। लेकिन इसका अर्थ यह भी है कि service को दो connections दिखाई दे सकते हैं, जो दोनों खुद को एक ही developer के agent के रूप में बताते हों, जब तक service के पास उन्हें अलग पहचानने और सीमित करने का साफ तरीका न हो।

इसलिए पहला diagnostic सवाल सीधा है: क्या ये दोनों एंट्रियाँ एक ही external authority तक पहुँचने वाले दो execution paths बनाती हैं? अगर हाँ, तो वे duplicate हैं, भले ही उनका JSON अलग हो और नाम उचित लगें।

सर्वर का नाम उसकी identity नहीं होता

MCP registration की कम-से-कम दो identities होती हैं, और टीमें अक्सर उन्हें मिला देती हैं।

Display identity configured name होता है, जैसे repo-api या staging-db। यह महत्वपूर्ण है क्योंकि क्लाइंट इसका इस्तेमाल टूल दिखाने और configuration conflicts सुलझाने के लिए करता है। यह लोगों और client bookkeeping के लिए है।

Execution identity वह है जहाँ registration वास्तव में पहुँचता है: executable, उसके arguments और संबंधित environment, या authentication context के साथ remote URL। यह processes और external systems के लिए है।

साफ-सुथरे setup में दोनों identities मिलती हैं। लेकिन उनका मिलना ज़रूरी नहीं है, और यह मान लेना ही वह वजह है जिससे duplicates review से बच जाते हैं।

इन entries पर विचार करें:

{
  "mcpServers": {
    "billing": {
      "command": "python3",
      "args": ["tools/billing_mcp.py", "--account", "prod"]
    },
    "finance-tools": {
      "command": "python3",
      "args": ["tools/billing_mcp.py", "--account", "prod"]
    }
  }
}

नाम अलग हैं, लेकिन यह समान arguments वाला एक ही program है। जब तक program खुद single instance लागू न करे, ये दो launches हैं।

अब कम स्पष्ट उदाहरण देखें:

{
  "mcpServers": {
    "deploy": {
      "command": "./bin/deploy-mcp",
      "args": ["--workspace", "/Users/dev/work/acme"]
    },
    "release-helper": {
      "command": "node",
      "args": ["scripts/mcp-launch.js", "deploy", "--workspace", "/Users/dev/work/acme"]
    }
  }
}

Text comparison कहेगा कि entries अलग हैं। Process-level comparison दिखा सकता है कि wrapper वही deploy-mcp executable उसी workspace के साथ शुरू करता है। इसी वजह से configuration review में simple duplicate-line check नहीं, identity rule चाहिए।

Entries की तुलना इस क्रम में करें:

1. Normalized remote endpoint की तुलना करें, या उस अंतिम executable की जिसे command शुरू करती है।
2. उन arguments की तुलना करें जो account, tenant, repository, workspace या write target चुनते हैं।
3. Working directory और उन non-secret environment variable names की तुलना करें जो behavior बदलते हैं।
4. Credential ownership की अलग से तुलना करें। अलग authorities के साथ एक ही endpoint तक पहुँचने वाली दो entries harmless duplicates नहीं हैं। वे permission design का निर्णय हैं, जिसके पीछे वजह होनी चाहिए।

इस audit के लिए secret values की तुलना न करें। उनकी ज़रूरत नहीं है, और उन्हें audit output में कॉपी करने से दूसरी security problem बनती है। दर्ज करें कि एक entry BILLING_TOKEN और दूसरी PERSONAL_BILLING_TOKEN इस्तेमाल करती है, फिर तय करें कि क्या ये variables उसी account को authorize करते हैं।

Scope precedence अलग नामों की सफाई नहीं कर सकता

Claude Code तीन MCP scopes बताता है: local, project और user। Project-scoped entries repository की .mcp.json file में रहती हैं, जबकि user-scoped entries सभी projects में उपलब्ध होती हैं। इसके documentation के अनुसार, जब एक ही server name हो तो local scope पहले, फिर project और फिर user scope लागू होता है। पुराने documentation में user scope को «global» कहा गया था।

यह behavior केवल एक सीमित स्थिति से बचाता है: एक ही नाम एक से अधिक scope में दिखाई दे। यह सामान्य duplicate registration से नहीं बचाता:

User scope:    personal-git      -> /Users/dev/bin/git-mcp
Project scope: repository-git    -> /Users/dev/bin/git-mcp

दोनों नाम दिखाई दे सकते हैं, क्योंकि नाम के आधार पर कोई conflict नहीं है। दोनों शुरू हो सकते हैं और दोनों लगभग एक जैसे tools expose कर सकते हैं।

एक और जाल है। Developer देखता है कि project file में repository-git है, फिर repository के बाहर भी tool चाहिए इसलिए user scope में personal-git जोड़ देता है, और भूल जाता है कि user entry repository के अंदर भी load होती है। तुरंत अनुभव अच्छा लगता है। सफाई तब तक टलती रहती है जब तक कोई tool call दो audit records न लिख दे या background worker उसी state directory को lock न कर दे।

Scopes का इस्तेमाल सुविधा के लिए नहीं, ownership के लिए करें:

• Registration को project scope में रखें जब repository को इसकी ज़रूरत हो और configuration साझा करना सुरक्षित हो।
• User scope तब रखें जब यह निजी utility हो जो अलग-अलग repositories में काम करे।
• Local scope को निजी, repository-specific experiment के लिए इस्तेमाल करें जिसे commit नहीं करना है।
• Project entry को user scope में duplicate न करें। अगर इसे कहीं और चाहिए, तो इसे केवल वहीं चलाएं जहाँ project config लागू होती है, या जानबूझकर अलग target और documented purpose वाली अलग entry बनाएं।

Same-name override पर भी ध्यान दें। यह दो नामों की तरह दो active entries नहीं बनाता, लेकिन personal entry के पीछे team configuration छिपा सकता है। तब agent private executable या personal endpoint से कार्रवाई करता है, जबकि reviewers मानते हैं कि repository definition लागू है। यह process-count failure नहीं, provenance failure है, फिर भी इसे ठीक करना ज़रूरी है।

Config से process और call तक duplicate साबित करें

जो entry redundant दिखे उसे तुरंत delete न करें। Configuration से process और फिर external action तक की chain स्थापित करें। इससे ऐसा साफ दिखने वाला fix करने से बचेंगे जो सही account या workspace इस्तेमाल करने वाली एकमात्र entry को चुपचाप हटा दे।

प्रभावित repository के भीतर से शुरू करें:

claude mcp list
claude mcp get repository-git
claude mcp get personal-git

Anthropic claude mcp list, claude mcp get और claude mcp remove को सामान्य management commands के रूप में document करता है। Output से हर दिखाई देने वाले नाम की पहचान करें, फिर संदिग्ध entries को एक-एक करके देखें।

हर entry के लिए scratch file में पाँच बातें लिखें: configured name, scope, command या URL, arguments और वह external account या workspace जहाँ यह पहुँचती है। Environment values paste न करें। Remote server के लिए authorization header नहीं, host और path दर्ज करें।

इसके बाद एक छोटा agent session शुरू करें और connection के दौरान processes देखें। macOS या Linux पर billing_mcp.py को उस command के किसी अनोखे हिस्से से बदलें जिसकी आप उम्मीद कर रहे हैं:

ps -ax -o pid,ppid,lstart,command | grep '[b]illing_mcp.py'

Duplicate stdio launch का output कुछ ऐसा दिख सकता है:

91204 91188 Tue Jul 21 10:14:07 2026 python3 tools/billing_mcp.py --account prod
91219 91188 Tue Jul 21 10:14:09 2026 python3 tools/billing_mcp.py --account prod

Process IDs अलग हैं। Parent एक ही agent process या दो संबंधित agent processes हो सकता है। महत्वपूर्ण evidence यह है कि दोनों commands की execution identity समान है और उनकी lifetimes overlap करती हैं।

फिर जानबूझकर एक सुरक्षित, read-only tool call करें। ऐसा call चुनें जिसका अपेक्षित record सीमित हो, जैसे current account identifier प्राप्त करना या किसी ज्ञात object की सूची देखना। Target system के logs, server logs या action journal की जाँच करें। अगर दो independent connections लेकिन एक call दिखाई दे, तो duplicate server startup मिल गया। अगर दो calls दिखाई दें, तो तय करें कि agent ने दो tools चुने, error के बाद retry किया या server ने खुद काम दोहराया। ये अलग कारण हैं और इनके अलग fixes चाहिए।

MCP lifecycle specification सामान्य operation से पहले initialization ज़रूरी बताती है। दो initialization events दिखना दो connections साबित करने के लिए पर्याप्त है। इससे कोई business action हुआ, यह साबित नहीं होता। इसलिए केवल दो handshakes देखकर incident responders को «deployment दो बार चला» न बताएं।

Credentials पढ़े बिना configurations का fingerprint बनाएं

एक उपयोगी duplicate check हर configured entry के लिए stable fingerprint बनाता है और secret values को बाहर रखता है। नीचे दी गई script एक या अधिक JSON configuration files पढ़ती है, mcpServers निकालती है और transport, command, arguments, URL, working directory तथा environment variable names की तुलना करती है। इसे केवल उन्हीं files पर चलाएं जिनका निरीक्षण करने की अनुमति आपके पास है।

#!/usr/bin/env python3
# save as mcp_duplicates.py
import hashlib
import json
import pathlib
import sys
from collections import defaultdict

if len(sys.argv) < 2:
    raise SystemExit("usage: mcp_duplicates.py CONFIG [CONFIG ...]")

entries = defaultdict(list)

for raw_path in sys.argv[1:]:
    path = pathlib.Path(raw_path).expanduser()
    with path.open() as handle:
        document = json.load(handle)

    for name, server in document.get("mcpServers", {}).items():
        identity = {
            "type": server.get("type", "stdio"),
            "command": server.get("command"),
            "args": server.get("args", []),
            "url": server.get("url"),
            "cwd": server.get("cwd"),
            "env_names": sorted(server.get("env", {}).keys()),
            "header_names": sorted(server.get("headers", {}).keys()),
        }
        encoded = json.dumps(identity, sort_keys=True, separators=(",", ":"))
        fingerprint = hashlib.sha256(encoded.encode()).hexdigest()[:12]
        entries[fingerprint].append((str(path), name, identity))

for fingerprint, matches in sorted(entries.items()):
    if len(matches) < 2:
        continue
    print(f"DUPLICATE EXECUTION IDENTITY {fingerprint}")
    for path, name, identity in matches:
        print(f"  {path}: {name}")
        print(f"    {json.dumps(identity, sort_keys=True)}")

इसे project की .mcp.json और client द्वारा इस्तेमाल की जाने वाली user-level configuration की sanitized export या copy पर चलाएं:

python3 mcp_duplicates.py .mcp.json ~/tmp/user-mcp.json

Output कुछ ऐसा दिखना चाहिए:

DUPLICATE EXECUTION IDENTITY 64e0e2509d8a
  .mcp.json: repository-git
    {"args":["tools/git_mcp.py"],"command":"python3","cwd":null,"env_names":["GIT_ACCOUNT"],"header_names":[],"type":"stdio","url":null}
  /Users/dev/tmp/user-mcp.json: personal-git
    {"args":["tools/git_mcp.py"],"command":"python3","cwd":null,"env_names":["GIT_ACCOUNT"],"header_names":[],"type":"stdio","url":null}

यह check जानबूझकर conservative है। यह समान घोषित execution shape वाली entries को flag करता है। यह साबित नहीं कर सकता कि दो अलग wrapper commands एक ही process तक नहीं पहुँचतीं, और यह भी साबित नहीं कर सकता कि दो अलग URLs एक ही service तक route नहीं होतीं। Output को review queue समझें, automatic deletion list नहीं।

जब एक config relative path और दूसरी absolute path इस्तेमाल करती हो, तब false negatives की भी उम्मीद रखें। अगर आपकी टीम दोनों रूप इस्तेमाल करती है तो तुलना से पहले paths normalize करें। यह काम repository root को समझने वाली controlled script में करें। Configuration files पर broad search-and-replace न चलाएं।

दो independent instances state पर असहमत हो सकते हैं

सबसे महंगी failures हमेशा duplicate API calls नहीं होतीं। दो instances स्थानीय state पर असहमत हो सकते हैं, जबकि दोनों अपने लेखक की अपेक्षा के अनुसार व्यवहार कर रहे हों।

मान लें कोई server repository metadata का local cache रखता है। Instance A पुराने checkout से शुरू होता है और shared default directory में cache records लिखता है। Branch switch के बाद शुरू हुआ Instance B उसी directory को पढ़ता है और file मौजूद होने के कारण cache को valid मान लेता है। अब tool call ऐसा data लौटाता है जो किसी भी process के current view से मेल नहीं खाता। Agent stale object पर पूरी तरह valid call कर सकता है।

Queue consumer से जुड़ी एक और आम failure है। दोनों instances एक ही principal के रूप में authenticate होकर उसी job stream को poll करते हैं। अगर queue at-least-once delivery देती है तो duplicate handling पहले से अपेक्षित हो सकती है। अगर tool author local deduplication map जोड़ता है, तो हर process को अपना अलग map मिलता है। Map एक process के भीतर duplicates रोकता है, दोनों processes के बीच नहीं।

यहाँ खराब सलाह है, «बस server को stateless बना दें।» यह इसलिए लोकप्रिय है क्योंकि सुरक्षित लगती है और stateless HTTP services कई connections अच्छे से संभालती हैं। लेकिन स्थानीय tools के लिए यह गलत है जो जानबूझकर caches, OAuth refresh state, file watchers या operation handles रखते हैं। सही requirement अधिक सीमित है: document करें कि concurrent instances supported हैं या नहीं, वे कौन से resources साझा करते हैं और जब दो instances एक ही identity इस्तेमाल करें तो क्या होता है।

Server owners से README या startup output में इन सवालों के जवाब देने को कहें:

• क्या startup local files लिखता है, credentials refresh करता है या background task शुरू करता है?
• क्या दो processes एक ही workspace, account और cache directory इस्तेमाल कर सकते हैं?
• External system बदलने वाली हर tool call में idempotency key होती है?
• क्या operator उस client process या session की पहचान कर सकता है जिसने record बनाया?

अगर दूसरे सवाल का जवाब नहीं है तो conflict स्पष्ट करें। Operating-system lock, हर process के लिए unique runtime directory या server-side lease इस्तेमाल करें। इस भरोसे पर न रहें कि लोग याद रखेंगे कि इसे केवल एक बार configure करना है।

Tool duplication और action duplication अलग incidents हैं

Client दो समान tools expose कर सकता है, बिना किसी को दो बार execute किए। इसके उलट, एक ही tool के ज़रिए repeated external action हो सकता है। जब कोई दोनों परिणामों को «duplicate MCP» कह देता है तो investigation गलत दिशा में चली जाती है।

Duplicate tool exposure का अर्थ है कि दो registrations overlapping capabilities advertise करते हैं। Agent को दो servers से billing_get_invoice दिखाई दे सकता है। यह configuration और prompting का खतरा है। Registrations और descriptions ठीक करें।

Duplicate execution का अर्थ है कि दो local processes या दो remote sessions मौजूद हैं। यह connection और lifecycle का खतरा है। Registration path, server concurrency behavior या दोनों ठीक करें।

Repeated external action का अर्थ है कि target system को एक से अधिक meaningful request मिली। इसका कारण duplicate exposure, retry logic, timeout, user intervention, server behavior या client bug हो सकता है। इसे target पर operation identifier से साबित करें, MCP processes की संख्या से अनुमान न लगाएं।

Incident के दौरान ये records साथ रखें:

Agent run ID:          run-7f3a
Configured name:       repository-git
Server process ID:     91204
MCP connection start:  2026-07-21T10:14:07Z
Tool request ID:       58
Target operation ID:   commit-3a8b

Identifiers के नाम यही होना ज़रूरी नहीं। उन्हें agent, server और target service के बीच संबंध बनाने लायक होना चाहिए। अगर किसी layer में correlation value नहीं बन सकती तो timing guesses से खाली जगह न भरें, बल्कि incident record में यह बात लिखें।

Sallyport का Sessions journal और Activity journal के बीच विभाजन यहाँ उपयोगी है, क्योंकि यह distinction बनाए रखता है। दूसरा run या connection अपने-आप दूसरी external action का प्रमाण नहीं है। Call records को भी यह दिखाना होगा।

Blind spot बनाए बिना एक registration हटाएं

सच्चे duplicate की पहचान होने के बाद कुछ हटाने से पहले canonical registration चुनें। Canonical entry का owner स्पष्ट, scope predictable, command या endpoint reviewed और credential source documented होना चाहिए। «यह मेरे machine पर काम कर गया» चयन का नियम नहीं है।

Team-owned integration के लिए project entry आम तौर पर बेहतर होती है, क्योंकि codebase के साथ उसकी समीक्षा की जा सकती है। Shared file से credentials बाहर रखें। Claude Code .mcp.json में environment-variable expansion का समर्थन करता है, जिसमें commands, arguments, environment fields, URLs और headers की values शामिल हैं। इससे token commit किए बिना shared definitions संभव होती हैं।

Personal cross-project utility के लिए user scope सही जगह हो सकती है। Project entry तभी हटाएं जब repository को अन्य contributors के लिए common tool definition की ज़रूरत न हो। Team dependency को undocumented personal prerequisite न बनाएं।

Change के बाद यह शांत validation sequence अपनाएं:

1. Test के दौरान हटाई गई entry को active configuration से बाहर किसी जगह सुरक्षित रखें।
2. नया agent process शुरू करें। पुराने processes पुराने connections बनाए रख सकते हैं।
3. claude mcp list चलाएं और बची हुई entry को claude mcp get <name> से देखें।
4. एक सुरक्षित read-only call करें और एक connection तथा एक target request दर्ज करें।
5. एक बार फिर restart करें और पुष्टि करें कि हटाया गया registration वापस नहीं आता।

अगर removal से workflow टूटे तो केवल canonical definition वापस लाएं और उसका missing path, environment variable या permission ठीक करें। जल्दी में दोनों entries वापस न लाएं। इससे वही ambiguity फिर पैदा हो जाएगी जिसे diagnose करने में आपने समय लगाया।

Duplicate detection को configuration review का हिस्सा बनाएं

सबसे अच्छा control एक छोटा review rule है: हर MCP registration का owner और scope होना चाहिए, और उसके intended purpose के लिए execution identity unique होनी चाहिए। इससे अधिकांश गलतियाँ agents के चलने से पहले पकड़ी जा सकती हैं।

अगर टीम .mcp.json को version control में रखती है तो fingerprint check को repository script में रखें। Shared configuration के विरुद्ध इसे local review और continuous integration दोनों में चलाएं। यह developer की user-scope entries नहीं देख पाएगा, इसलिए अजीब tool behavior की शिकायत करने वाले contributors की setup checklist में claude mcp list भी शामिल करें।

User-scope configuration के लिए config से अलग एक छोटा inventory रखें। हर server के लिए एक line पर्याप्त है:

personal-git | user | git tooling across repositories | owner: developer
repository-git | project | repository release workflow | owner: platform team

अगर दोनों lines एक ही executable और account की ओर इशारा करती हैं, तो एक को हटाना होगा या उनके targets को जानबूझकर अलग बनाना होगा। केवल इसलिए दो labels स्वीकार न करें कि prompt में एक नाम अधिक friendly लगता है।

अनुशासन सरल है: एक purpose के लिए एक route, स्पष्ट ownership और यह evidence कि एक requested action से एक external record बना। इसके बाद duplicate process कोई देर रात का रहस्य नहीं, बल्कि दिखाई देने वाला defect बन जाता है, जो लगभग समान दो tool names के पीछे छिपा नहीं रहता।