Terminals और IDEs में MCP config precedence कैसे बदलती है

MCP configuration में टकराव MCP की समस्या नहीं है। यह client की समस्या है, और यह अंतर बहुत-सी गलत debugging से बचाता है।

Protocol client को server शुरू होने के बाद उससे बात करने का तरीका बताता है। वह Claude Code, VS Code, Cursor, GitHub Copilot CLI या किसी extension को यह नहीं बताता कि पहले कौन-सी JSON file पढ़नी है, एक ही नाम वाली दो entries merge होंगी या नहीं, अथवा file-based configuration लोड होने के बाद plugin server register कर सकता है या नहीं। अगर आप एक universal hierarchy मान लेते हैं, तो सही दिखने वाले tool name के साथ गलत executable चल सकता है।

यह गलती आसानी से छूट जाती है। Tool list में github दिखता है, agent github.search_code चलाता है और call सफल हो जाती है। इसी बीच आपका terminal agent test account के विरुद्ध project wrapper चला सकता है, जबकि IDE आपके personal account के विरुद्ध global command चला रही हो। नाम एक था, command अलग थी।

मेरी व्यावहारिक rule यह है: MCP configuration को हर client, हर process और हर server name के लिए अलग resolve करें। Server command, arguments, environment, working directory, transport URL और credential source को एक ही launch definition मानें। Agent panel में दिख रहे label से इनमें से किसी चीज़ का अनुमान न लगाएँ।

MCP की कोई साझा precedence ladder नहीं है

MCP clients और servers के बीच messages और capabilities को standardize करता है। जब configuration sources अलग-अलग हों, तो कौन जीतेगा या portable file layout कैसा होगा, यह MCP तय नहीं करता। कोई client JSON files, settings database, plugin API, managed enterprise policy, command-line flag या इन सभी का इस्तेमाल कर सकता है।

इसलिए ये चार बातें एक-दूसरे की जगह नहीं ले सकतीं:

• User config किसी account या profile के लिए client-specific global definition होती है।
• Project config किसी repository या workspace से जुड़ी definition होती है।
• Plugin config installed extension या plugin द्वारा register या supplied server होती है।
• Editor setting editor से जुड़ी setting होती है, जो MCP server configuration को नियंत्रित करे भी सकती है और नहीं भी।

आख़िरी अंतर अक्सर अनावश्यक परेशानी पैदा करता है। VS Code की सामान्य settings hierarchy में workspace settings, ordinary settings के लिए user settings पर प्राथमिकता रखती हैं। Object values merge हो सकती हैं, जबकि primitive और array values override होती हैं। यह व्यवहार settings.json के लिए है। इससे यह साबित नहीं होता कि .vscode/mcp.json भी वही merge और collision rules अपनाती है। VS Code MCP configuration को अलग mcp.json file के रूप में document करता है, जो workspace या user profile में हो सकती है। Settings engine की धारणाओं को अलग configuration format पर लागू न करें।

व्यावहारिक निष्कर्ष सीधा है: “workspace wins” तब तक उपयोगी उत्तर नहीं है, जब तक client name, client version, config format और exact collision स्पष्ट न हों। Workspace file server जोड़ सकती है, उसी नाम वाले global server को shadow कर सकती है, उसके साथ रह सकती है या untrusted workspace के कारण load ही न हो। ये अलग परिणाम हैं और सामान्य precedence diagram इन्हें छिपा देता है।

Conflict की इकाई server name है

अधिकांश clients MCP configuration को map की तरह व्यवस्थित करते हैं: बाईं ओर server name और दाईं ओर एक launch definition। अक्सर यही map key तय करती है कि दो declarations में टकराव है या नहीं।

इन दो files को देखें:

// user configuration
{
  "mcpServers": {
    "catalog": {
      "command": "node",
      "args": ["/Users/dev/bin/catalog-live.js"],
      "env": { "CATALOG_TARGET": "production" }
    }
  }
}

// project configuration
{
  "mcpServers": {
    "catalog": {
      "command": "node",
      "args": ["./tools/catalog-fixture.js"],
      "env": { "CATALOG_TARGET": "fixture" }
    }
  }
}

इंसान को दो catalog services दिखती हैं। Client को catalog key पर दो values दिखती हैं। अगर वह एक definition चुनता है, तो सामान्यतः पूरी definition चुनता है। यह न मानें कि client global command को project arguments के साथ या project command को global environment के साथ जोड़ देगा। कुछ settings systems objects merge करते हैं, लेकिन MCP client ऐसा करने के लिए बाध्य नहीं है।

इसीलिए partial overrides खराब design हैं। किसी अलग endpoint की ज़रूरत हो तो project को अपनी पूरी intended command declare करनी चाहिए। Personal tool के लिए अलग नाम रखें। आधा override यह पता लगाना कठिन बना देता है कि client ने पूरा server object बदला या ऐसे fields merge किए जिनका आपने परीक्षण नहीं किया।

Diagnosis के दौरान ownership और उद्देश्य दिखाने वाले नाम इस्तेमाल करें:

{
  "mcpServers": {
    "catalog-user-live": { "command": "node", "args": ["/Users/dev/bin/catalog-live.js"] },
    "catalog-repo-fixture": { "command": "node", "args": ["./tools/catalog-fixture.js"] }
  }
}

ये नाम सुंदर नहीं हैं, लेकिन ईमानदार हैं। Team के पास एक canonical definition आ जाने पर इसे catalog नाम दिया जा सकता है। उससे पहले छोटा duplicate name हर tool call को अनुमान लगाने का अभ्यास बना देता है।

Duplicate name और duplicate capability को भी अलग रखें। दो servers दोनों search नाम का tool दे सकते हैं, फिर भी अलग server names के कारण distinct रहेंगे। Agent समान descriptions से भ्रमित हो सकता है, लेकिन client configuration में name collision ज़रूरी नहीं है। पहले client resolution हल करें, फिर tool descriptions और naming सुधारें।

Claude Code में MCP scope order स्पष्ट है

Claude Code सबसे आसान मामला है, क्योंकि उसके MCP documentation में एक ही नाम वाले server entries का order दिया गया है। Local scope, project scope पर और project scope, user scope पर प्राथमिकता रखता है। इसकी वर्तमान terminology महत्वपूर्ण है: local private, project-specific default है; project shared .mcp.json लिखता है; और user सभी projects पर लागू होता है। Anthropic ने पहले कुछ scopes के लिए अलग नाम इस्तेमाल किए थे, इसलिए पुराने notes और shell history भ्रमित कर सकते हैं।

अगर तीनों scopes में catalog मौजूद हो, तो Claude Code local definition शुरू करता है। उसके बाद shared .mcp.json definition और फिर user definition fallback होती है।

# private to this checkout and this user
claude mcp add catalog --scope local -- node ./tools/catalog-fixture.js

# shared with the repository
claude mcp add catalog --scope project -- node ./tools/catalog-service.js

# available in all repositories for this user
claude mcp add catalog --scope user -- node ~/bin/catalog-personal.js

तीनों मौजूद होने पर expected result एक effective server catalog होना चाहिए, जिसका source local scope हो। हर बदलाव के बाद file पर भरोसा करने के बजाय server list या get करने वाली client command चलाएँ:

claude mcp get catalog

Output में named server और उसका configured transport या command details दिखनी चाहिए। Actual command, arguments और environment की तुलना अपनी expected definition से करें। अगर command आपकी edit की हुई command नहीं है, तो files बदलना रोकें और पता करें कि नाम अभी किस scope के पास है।

इस MCP scope rule को Claude Code की broader settings precedence से न मिलाएँ। Anthropic सामान्य Claude Code settings के लिए managed enterprise policy, command-line arguments, local project settings, shared project settings और user settings document करता है। Managed setting MCP use के आसपास के व्यवहार को सीमित कर सकती है, लेकिन वह दूसरी MCP server definition नहीं होती। दोनों hierarchies अलग सवालों का जवाब देती हैं।

Project scope में एक और trap है। .mcp.json से मिले server को इस्तेमाल करने से पहले Claude Code approval मांगता है। यह approval इस बात से जुड़ी है कि client project-provided server इस्तेमाल कर सकता है या नहीं। इससे same-named server configuration की priority नहीं बदलती। Approval prompt को इस बात का प्रमाण न मानें कि shared command जीती।

VS Code MCP files को सामान्य settings से अलग रखता है

VS Code MCP server configuration के लिए दो documented locations देता है: workspace में .vscode/mcp.json और user profile की mcp.json, जिसे MCP: Open User Configuration command से खोला जा सकता है। Workspace file source control के ज़रिए share करने के लिए है, जबकि profile file user के साथ चलती है और VS Code profile के अनुसार अलग हो सकती है।

यह layout एक उचित अपेक्षा बनाता है: repository configuration repository tools define करे और profile personal tools। लेकिन इससे duplicate name resolution का पूरा नियम document नहीं होता। खास तौर पर public MCP reference schema और locations बताता है, पर यह नहीं कहता कि सामान्य VS Code settings precedence servers entries पर field by field लागू होती है।

यहीं अनुभवी users गलत shortcut लेते हैं। वे जानते हैं कि VS Code workspace settings user settings पर प्राथमिकता रखती हैं। फिर profile और workspace config में वही MCP server name रखते हैं, project command बदलते हैं और मान लेते हैं कि workspace command चलेगी। ऐसा हो सकता है, लेकिन adjacent settings subsystem के आधार पर निकला निष्कर्ष documented contract नहीं है।

VS Code में same-name collision को test requirement मानें। दोनों candidates को साफ़ तौर पर अलग बनाएं और harmless command इस्तेमाल करें, जिससे पता चले कि कौन शुरू हुआ:

{
  "servers": {
    "precedence-probe": {
      "type": "stdio",
      "command": "sh",
      "args": ["-lc", "printf 'workspace probe started\\n' >&2; exec node ./tools/probe-server.js"]
    }
  }
}

User-profile configuration में अलग marker रखें:

{
  "servers": {
    "precedence-probe": {
      "type": "stdio",
      "command": "sh",
      "args": ["-lc", "printf 'profile probe started\\n' >&2; exec node $HOME/bin/probe-server.js"]
    }
  }
}

फिर VS Code के MCP management UI से server को पूरी तरह restart करें, या UI process state स्पष्ट न करे तो editor restart करें। Marker के लिए MCP server output या logs देखें। Real database या deployment target पर test न करें। Precedence check को केवल launch path साबित करना चाहिए, data बदलना नहीं।

Enablement पर भी यही सावधानी लागू होती है। VS Code document करता है कि enable और disable state server configuration से अलग store होती है। इसलिए shared config file मौजूद हो सकती है, फिर भी किसी workspace में server शुरू न हो। “मैं इसे mcp.json में देख सकता हूँ” और “इस client ने इसे launch किया” दो अलग तथ्य हैं।

Multi-root workspaces certainty का एक और स्रोत हैं। सामान्य settings के लिए VS Code में workspace और workspace-folder scopes हैं, लेकिन workspace से जुड़ी MCP file अपने-आप per-folder server declaration नहीं बनती। Repository-relative command चाहिए तो test में workspace root और expected working directory स्पष्ट रखें। कई folders खोलने पर एक root में चलने वाली command fail हो सकती है या चुपचाप किसी दूसरी file तक पहुँच सकती है।

Cursor में project, global और extension registration paths हैं

Cursor project-specific MCP configuration को .cursor/mcp.json और global configuration को ~/.cursor/mcp.json में document करता है। Extension API के ज़रिए extensions MCP servers को programmatically register भी कर सकती हैं। ये तीन अलग sources हैं: repository file, user file और extension के भीतर चलने वाला code।

Unique names होने पर पहले दो को समझना आसान है। Repository की shared development service .cursor/mcp.json में रखें। Personal utility, जैसे local notes search service, global file में रखें। Cursor CLI कहती है कि वह mcp.json को detect और respect करती है, इसलिए shared configuration तब उपयोगी है जब IDE और terminal agent वास्तव में एक ही environment में चलें।

कठिन मामला तीनों sources में duplicate name है। Cursor की public MCP documentation project और global files की locations बताती है, लेकिन global configuration, project configuration और dynamically registered extension server के हर collision के लिए पूरी contract प्रकाशित नहीं करती। Forum post, पुरानी release note या किसी एक machine पर देखे गए व्यवहार से नियम न बनाएँ।

सुरक्षित design collision से बचना है। अगर कोई extension issue-tracker देती है, तो .cursor/mcp.json में दूसरी issue-tracker entry डालकर यह उम्मीद न करें कि repository command उसे replace कर देगी। Repository-owned server का नाम issue-tracker-fixture रखें और agent instructions या tool descriptions में स्पष्ट करें कि उसे कब इस्तेमाल करना है।

यह खास तौर पर उन teams के लिए महत्वपूर्ण है जो सुविधा के लिए plugin और reproducibility के लिए file दोनों इस्तेमाल करती हैं। Plugin installation, OAuth, updates या registration अपने schedule पर संभाल सकती है। Repository file code review में दिखाई देती है। ये अलग ownership models हैं। इससे पहले कि दोनों संयोग से एक जैसे व्यवहार करें, तय करें कि server का owner कौन है।

Environment boundaries Cursor conflicts को वास्तविकता से अधिक अजीब दिखाती हैं। Desktop editor एक operating system पर चल सकता है, जबकि उसका terminal, remote workspace या development container कहीं और चल रहा हो। Home directory की global file एक environment में हो सकती है, दूसरे में नहीं। Project file में node, python या relative executable अलग PATH से resolve हो सकता है। Precedence पर चर्चा से पहले लिखें कि client process कहाँ चलता है और server process कहाँ।

हर candidate के लिए यह छोटा launch record रखें:

client: Cursor desktop / Cursor CLI
client environment: local macOS / WSL / remote host / container
config source: ~/.cursor/mcp.json / .cursor/mcp.json / extension registration
server name: issue-tracker
command: node ./tools/issue-mcp.js
working directory: repository root
credential source: OAuth / local environment / external gateway

ऐसा पाँच मिनट का record settings panels को बार-बार बदलने में लगने वाली पूरी दोपहर से अधिक उपयोगी है।

GitHub Copilot CLI project-over-user MCP resolution document करता है

GitHub Copilot CLI कई clients से अधिक स्पष्ट है। उसके documentation के अनुसार .mcp.json या .github/mcp.json में project-level MCP configuration, ~/.copilot/mcp-config.json में उसी नाम की definition पर प्राथमिकता रखती है। CLI में MCP server names के लिए यह साफ़ project-over-user rule है।

इसे client-specific rule मानें, हर editor में GitHub Copilot के लिए सामान्य सत्य नहीं। Copilot CLI की अपनी configuration directory, repository settings, local settings, plugin support, permissions store और command-line process है। VS Code Copilot session एक अलग client surface है, जिसकी अपनी MCP documentation और lifecycle है।

एक साफ़ Copilot CLI setup ऐसा हो सकता है:

// ~/.copilot/mcp-config.json
{
  "mcpServers": {
    "docs": {
      "command": "node",
      "args": ["/Users/dev/bin/company-docs-mcp.js"]
    },
    "catalog": {
      "command": "node",
      "args": ["/Users/dev/bin/catalog-live.js"]
    }
  }
}

// .mcp.json in the repository
{
  "mcpServers": {
    "catalog": {
      "command": "node",
      "args": ["./tools/catalog-fixture.js"]
    }
  }
}

इस repository में Copilot CLI को project वाली catalog definition इस्तेमाल करनी चाहिए और user-level docs definition बनाए रखनी चाहिए, क्योंकि docs से project entry का conflict नहीं है। उपयोगी model यह है: केवल उस नाम को override करें जिसका owner project है, बाकी personal utilities को वैसा ही रहने दें।

Plugins तस्वीर को जटिल बनाते हैं, क्योंकि plugin अपना agent behavior और MCP server lifecycle ला सकता है। GitHub की configuration documentation repository-enabled plugins को repository-scoped बताती है और कहती है कि repository plugin enable न रहने पर client plugin का MCP server बंद कर देता है। इसका अर्थ है कि plugin का server plugin activation से जुड़ा है, सिर्फ user MCP file में copy नहीं हुआ है।

अगर plugin-provided और file-provided server का नाम एक हो, तो यह अनुमान न लगाएँ कि कौन-सी command जीतेगी। CLI की visible server state, plugin state और startup output देखें। Installed release के documentation में collision behavior न हो तो एक definition का नाम बदलें या एक producer हटाएँ। “Plugin server को repo में बस override कर दें” वाली सलाह आकर्षक है, लेकिन अगर plugin files के बाद registration करता है या अतिरिक्त lifecycle state देता है, तो गलत हो सकती है।

Editor और terminal अलग MCP clients हैं

IDE के भीतर का terminal editor का हिस्सा जैसा लगता है, लेकिन वह फिर भी shell process है। जब आप claude, copilot या cursor-agent चलाते हैं, तो वह command अपनी files, current directory, environment, home directory और configuration override variables पढ़ सकती है। Editor का chat extension अलग client implementation वाला अलग process है।

इसी वजह से अक्सर सुनने को मिलता है: “MCP server IDE में काम करता है, terminal में नहीं।” इसके कुछ सामान्य कारण हैं:

• Editor ने workspace file खोली, जबकि terminal subdirectory या sibling checkout में शुरू हुआ।
• Editor remote host या container इस्तेमाल करता है, जबकि terminal command local चलती है।
• Terminal को shell-specific PATH, HOME, proxy setting या credential variable मिला।
• Editor ने plugin server activate किया, जिसे CLI कभी load नहीं करती।
• CLI को उसी नाम वाला project server मिला और उसने user-level entry को replace कर दिया।

हर config file को हर location में copy करके शुरुआत न करें। इससे collision surface बढ़ती है और मूल कारण छिप जाता है।

इसके बजाय एक समय में एक client चलाएँ और evidence इकट्ठा करें। Terminal clients में servers list या get करने वाली built-in command इस्तेमाल करें। Editor clients में MCP server management view और उसके output या logs देखें। Server name, command, arguments, process location और start timestamp लिखें। अगर terminal और editor में नाम एक है लेकिन commands अलग हैं, तो configuration resolution issue मिल गया। अगर command एक ही है लेकिन व्यवहार अलग है, तो working directory, credentials, network access या server की जाँच करें।

एक उपयोगी test यह है कि intended server command को कुछ समय के लिए ऐसे wrapper से बदल दें, जो real server चलाने से पहले standard error में स्पष्ट marker लिखे। इसे read-only रखें और test के बाद हटा दें।

#!/bin/sh
printf '%s client=%s cwd=%s\n' \
  "MCP probe started" \
  "${MCP_CLIENT_LABEL:-unknown}" \
  "$PWD" >&2
exec node "$(dirname "$0")/real-server.js"

Tokens, headers, credential values, पूरा environment dump या request payloads न लिखें। Logs terminal session के बाद भी रह सकते हैं, और precedence probe को secret leak नहीं बनना चाहिए।

Plugin registration config-file override नहीं है

Plugin server configuration का producer है, सिर्फ कोई दूसरी JSON folder नहीं। वह server को dynamically register कर सकता है, authentication संभाल सकता है, version चुन सकता है, workspace changes पर प्रतिक्रिया दे सकता है या plugin deactivate होने पर server रोक सकता है।

इससे दो लोकप्रिय recommendations असुरक्षित हो जाती हैं।

पहली है, “Plugin को override करने के लिए project file में वही नाम रखें।” यह तभी काम करता है जब client document करे कि files plugins के बाद load होती हैं और same-name collision plugin registration को replace करती है। ऐसी contract के बिना duplicate से error, hidden replacement, समान description वाले दो tools या update के बाद बदलता व्यवहार मिल सकता है।

दूसरी है, “UI में server disable कर दो, project साफ़ है।” Enablement state shared file के बाहर हो सकती है। VS Code स्पष्ट रूप से enable या disable state को MCP configuration से अलग रखता है। Teammate repository clone करके वही file पा सकता है, फिर भी उसका active-server set अलग हो सकता है।

इसके बजाय ownership के इन patterns में से एक चुनें:

1. File-owned server: Repository server definition commit करती है। सभी लोग file इस्तेमाल करते हैं और कोई plugin वही service register नहीं करता।
2. Plugin-owned server: Plugin registration और authentication संभालता है। Repository duplicate declare नहीं करती।
3. Separated server roles: Plugin tracker-live own करता है और project file tracker-fixture। Names, descriptions और permissions targets को अलग दिखाते हैं।

तीसरा विकल्प कम आकर्षक, लेकिन अधिक सुरक्षित होता है। Teams को अक्सर personal live service और repository fixture दोनों एक साथ चाहिए होते हैं। केवल इसलिए उन्हें एक server मानना कि दोनों issue tracker से बात करते हैं, accidental live call की संभावना बढ़ाता है।

Winning command साबित करने का दोहराने योग्य तरीका

Agent behavior पर निर्भर हुए बिना configuration resolution साबित किया जा सकता है। नीचे दी गई method harmless stdio server या wrapper इस्तेमाल करती है और local command शुरू करने वाले या remote service की ओर इशारा करने वाले दोनों clients में काम करती है।

Two-source probe बनाएँ

एक server name चुनें, जैसे precedence-probe। जिन दो sources की तुलना करनी है, उनमें इसे ठीक-ठीक define करें। हर candidate को ऐसा अलग marker देना चाहिए, जो उसी harmless test server को शुरू करने से पहले दिखाई दे।

Command-based server के लिए हर महत्वपूर्ण हिस्सा अलग करें:

{
  "mcpServers": {
    "precedence-probe": {
      "command": "sh",
      "args": ["-lc", "printf 'SOURCE=PROJECT CWD=%s\\n' \"$PWD\" >&2; exec node ./tools/probe.js"],
      "env": { "MCP_PROBE_SOURCE": "project" }
    }
  }
}

User candidate को SOURCE=USER दिखाना चाहिए और अलग, ज्ञात file की ओर इशारा करना चाहिए। केवल environment variable पर निर्भर न रहें, क्योंकि client उसे redact या filter कर सकता है या stale process शुरू कर सकता है। Command path और output में भी स्पष्ट marker रखें।

केवल chat नहीं, server restart करें

MCP servers अक्सर लंबे समय तक चलने वाले child processes होते हैं। Server चलते रहने के दौरान JSON edit करने से अगली request के बारे में कुछ साबित नहीं होता। Client का वह control इस्तेमाल करें जो server को stop और restart करता है। अगर वह स्पष्ट न हो तो संबंधित client पूरी तरह बंद करके workspace फिर खोलें।

फिर पहले client-side logs देखें। Expected evidence इस तरह होनी चाहिए:

MCP probe started
SOURCE=PROJECT
CWD=/path/to/repository

अगर marker नहीं मिलता, तो client ने process launch से पहले configuration reject की हो सकती है, remote transport इस्तेमाल किया हो सकता है या पुराना server जीवित रखा हो सकता है। यह भी उपयोगी परिणाम है। सवाल “कौन-सी config जीती?” से बदलकर “क्या config load हुई और क्या client ने process शुरू किया?” हो जाता है।

एक बार में एक boundary बदलें

पहले terminal client में probe चलाएँ, फिर IDE client में। Baseline मिलने के बाद ही current working directory बदलें। File-only behavior मापने के बाद ही plugin disable करें। Local overrides या managed settings जोड़ने से पहले user और project sources test करें।

Repository issue या team notes में छोटी result table रखें:

Table में observed behavior लिखें, expected behavior नहीं। Team observed behavior पर कार्रवाई कर सकती है। किसी दूसरे client से copy किया गया diagram केवल hypothesis है।

Credentials को precedence contest से बाहर रखें

Command conflict execution problem है। Credential conflict security problem है। पहली समस्या हल करने के लिए secrets को project, plugin, user और editor configuration में तब तक न फैलाएँ जब तक कुछ काम न करने लगे।

Committed project configuration में सामान्यतः server command, non-sensitive endpoint information और credentials प्राप्त करने के instructions होने चाहिए। env में long-lived bearer token, ऐसा SSH private key path जिसे हर teammate के पास न हो, या production access देने वाला custom header न रखें। Project file हर clone और उस client द्वारा अनुमति पाए हर agent के लिए execution invitation बन जाती है।

Server को secret चाहिए तो काम के अनुरूप credential boundary चुनें:

• OAuth उपयुक्त है, जब server और client उसका समर्थन करते हों और user को interactively access देना हो।
• Personal server definition के लिए local secret manager या environment injection उपयुक्त है।
• Repository fixture को सीमित permissions वाले non-production credentials इस्तेमाल करने चाहिए।
• जब agent को underlying API या SSH credential दिए बिना action request करानी हो, तो action gateway उपयुक्त है।

यहीं server command harmless दिखकर भी खतरनाक हो सकती है। npx some-mcp-server machines के बीच अलग installed version resolve कर सकता है। node ./tools/server.js parent process से AWS_PROFILE, GH_TOKEN या corporate proxy ले सकता है। Project declaration review की जा सकती है, लेकिन उसका वास्तविक credential source छिपा रह सकता है।

जब agents को HTTP या SSH access चाहिए, Sallyport API या SSH credential को अपने encrypted vault में रख सकता है। Agent sp mcp shim के ज़रिए connect करता है और केवल action results पाता है। इससे यह तय नहीं होता कि कौन-सी client config जीतेगी, लेकिन winning command को agent तक raw credentials पहुँचाने से रोका जा सकता है।

Configuration precedence को permission system न समझें। Project definition command चुन सकती है, लेकिन यह साबित नहीं करती कि command बिना review के action कर सकती है। Approval, credential storage और audit evidence को अलग controls रखें।

Canonical command को स्पष्ट रखें

Team को इस सीधे सवाल का एक उत्तर चाहिए: इस repository का agent इस service के लिए कौन-सी command शुरू करे? अगर उत्तर user files, plugin behavior, README snippets और editor settings के बीच छिपा है, तो setup पहले ही बहुत ढीला है।

Canonical shared definition एक जगह लिखें। Stable server name दें। बताएँ कि कौन-से clients इसे support करते हैं और कौन-सा source इसका owner है। Personal variants के लिए अलग नाम रखें। अगर plugin को service own करनी है, तो document करें कि plugin canonical है और competing file definition ship न करें।

Repository में छोटा verification command या probe भी रखें। Configuration changes को deployment scripts की तरह tests चाहिए। गलत command शुरू करने वाला server agent के कुछ कहने से पहले गलत files पढ़ सकता है, गलत endpoint call कर सकता है या गलत credential inherit कर सकता है।

उपयोगी परिणाम universal precedence chart नहीं है। बेहतर setup वह है जिसमें हर client के पास एक observable launch path हो, हर server name का एक owner हो और किसी को यह अनुमान न लगाना पड़े कि उसका agent कौन-सी command चलाएगा।