MCP टूल सूची में बदलाव लाइव सेशन को कैसे बदलते हैं

किसी लाइव MCP सेशन को उन टूल के लिए भरोसा विरासत में नहीं मिलना चाहिए जो आपकी मंजूरी के समय मौजूद ही नहीं थे। टूल डिस्कवरी साधारण पृष्ठभूमि व्यवस्था लगती है, जब तक एजेंट नई उपलब्ध कार्रवाई को उसी बातचीत के प्रवाह और उन्हीं क्रेडेंशियल के साथ नहीं चला सकता। उस समय कार्रवाई की सतह बदल चुकी होती है, भले ही किसी ने prompt न बदला हो।

मैंने इंजीनियरों को repository के काम के लिए coding run मंजूर करते देखा है, फिर उसे चलता छोड़ दिया जबकि किसी connector में deployment या ticketing कार्रवाई जुड़ गई। सामान्य बचाव होता है, "एजेंट के पास केवल जरूरत के टूल थे।" सूची बदलते ही यह बात गलत हो जाती है। लंबे समय तक चलने वाले एजेंट पर छोटे command-line process से कम सहज भरोसा होना चाहिए, ज्यादा नहीं।

मेरा नियम सरल है: जब भी टूल inventory बदले, उसकी तुलना करें, अधिकार में हुए बदलाव को वर्गीकृत करें और अगर बदलाव कोई कार्रवाई सतह जोड़ता है या उसमें बड़ा परिवर्तन करता है तो नया agent run शुरू करें। इसे policy language का प्रोजेक्ट न बनाएं। बात उस मानवीय फैसले को बचाए रखने की है, जिसका अर्थ फैसला लेते समय भी वही था।

टूल सूची अधिकारों की inventory है

MCP टूल सूची कोई menu नहीं है। यह उन operations का समूह है जिन्हें एजेंट प्रस्तावित कर सकता है और client के आधार पर चला भी सकता है। हर entry में नाम, description, input schema और ऐसा behavior शामिल होता है जो अक्सर ऐसी service तक पहुंचता है जिसे model सीधे नहीं देख सकता।

Model Context Protocol specification टूल को server द्वारा उपलब्ध कराए गए model-controlled functions कहता है। यह शब्दावली महत्वपूर्ण है। Client descriptions को model के सामने रख सकता है, लेकिन description सुरक्षा की सीमा नहीं है। Schema और server-side behavior तय करते हैं कि call क्या कर सकता है।

मैं inventory की समीक्षा करते समय हर टूल के बारे में पांच सवाल पूछता हूं:

• यह call कौन-सा डेटा पढ़ सकता है?
• यह call कौन-सी स्थिति बदल सकता है?
• इसका output कहां जा सकता है?
• यह कौन-सा credential या host इस्तेमाल करता है?
• क्या इसके arguments नाम से दिखने वाले दायरे से अधिक विस्तार दे सकते हैं?

get_build_status नाम का टूल केवल पढ़ने वाला और सीमित हो सकता है। request नाम का टूल अपने credential की अनुमति के अनुसार कहीं भी डेटा पढ़, लिख और भेज सकता है। नाम पहले टूल को मंजूर करना आसान बनाते हैं और दूसरे को कम आंकना भी आसान बना देते हैं।

अक्सर लोग टूल discovery और permission को एक ही बात मान लेते हैं। Discovery एजेंट को बताती है कि क्या उपलब्ध है। Permission तय करती है कि एजेंट उसका इस्तेमाल कर सकता है या नहीं। इन दोनों को मिला देंगे तो बीच सेशन का refresh बिना समीक्षा वाला permission बदलाव बन जाएगा।

जोड़े गए टूल की सबसे कड़ी समीक्षा करें

जोड़ा गया टूल नया run मांगता है, अगर उससे डेटा, commands या बाहरी व्यक्ति तक पहुंचने का नया रास्ता बनता है। यह तब भी सही है जब नया टूल एजेंट के मौजूदा काम से जुड़ा हुआ लगता हो।

मान लें कि एजेंट के पास शुरू में repo_search, read_issue और create_branch हैं। सेशन के बीच server post_comment जोड़ देता है। कोई इसे छोटा विस्तार कह सकता है, क्योंकि एजेंट पहले ही issues पढ़ता है। यह छोटा बदलाव नहीं है। Issue पढ़ना निजी retrieval है। Comment पोस्ट करना लोगों तक model-generated text भेजता है, जिस पर वे कार्रवाई कर सकते हैं, और यह बातचीत या workspace की जानकारी उजागर कर सकता है।

इन additions को डिफॉल्ट रूप से महत्वपूर्ण मानें:

• ऐसी कोई भी कार्रवाई जो लिखती, मिटाती, deploy करती, प्रकाशित करती या संदेश भेजती है।
• ऐसा कोई general request टूल जिसका गंतव्य argument से तय होता है।
• कोई भी shell या SSH कार्रवाई, वह diagnostic बताई गई हो तब भी।
• ऐसी कोई कार्रवाई जो नया repository, account, host या डेटा श्रेणी पढ़ती है।
• ऐसा कोई टूल जो मौजूदा टूल से अधिक व्यापक credential इस्तेमाल करता है।

नई read कार्रवाई पर भी restart चाहिए हो सकता है। इंजीनियर कभी-कभी केवल writes की चिंता करते हैं, फिर ऐसा export टूल उपलब्ध करा देते हैं जो customer records, build logs या configuration में रखे secrets पढ़ सकता है। डेटा बाहर जाने की शुरुआत read से होती है।

कुछ सीमित अपवाद हैं। पहले से मंजूर किसी fixed operation के लिए दूसरा नाम जोड़ा जाए तो run जारी रह सकता है, बशर्ते आप जांच लें कि वह उसी service तक, उन्हीं arguments और उसी credential से पहुंचता है। यह इतना दुर्लभ है कि मैं केवल release note देखकर अपवाद नहीं देता।

हटाए गए टूल संकेत हैं, साफ रद्दीकरण नहीं

हटाए गए टूल पर client की जांच करनी चाहिए, क्योंकि नई सूची से गायब होने का अर्थ यह नहीं कि चल रहे एजेंट की पहुंच खत्म हो गई। Server ने घोषित सूची बदल दी हो, जबकि client के पास पहले की सूची memory में हो। कोई दूसरा client तुरंत refresh हो सकता है। केवल हटाए जाने से व्यवहार का सुरक्षित अनुमान नहीं लगाया जा सकता।

Incident review में यह महत्वपूर्ण है। टीम server से delete_environment हटते देखती है, खतरा खत्म मान लेती है और पुराना session चलता रहने देती है। यदि उस client ने पहले ही टूल definition resolve कर ली थी, तो वह फिर भी call करने की कोशिश कर सकता है। Implementation से handler हटने पर server को उसे अस्वीकार करना चाहिए, पर घोषित discovery और वास्तविक execution अलग चीजें हैं। दोनों की पुष्टि करें।

एजेंट को रोकें और पहले व बाद की inventory दर्ज करें। फिर, अगर server आपका है, तो non-production setting में हटाई गई कार्रवाई को test करें, अन्यथा session समाप्त कर दें। Model से न पूछें कि उसके पास टूल अभी भी है या नहीं। Model का उत्तर उसके context को इतनी गलत तरह दर्शा सकता है कि उससे authorization का प्रश्न कभी तय नहीं होना चाहिए।

हटाने का एक सामान्य परिणाम भी है: टूल का नाम बदलना पहले एक removal और एक addition की तरह दिख सकता है। इसलिए नाम गिनने के बजाय definitions की तुलना करें।

नाम बदलने पर समानता का प्रमाण चाहिए

नाम बदलना केवल बाहरी बदलाव हो सकता है, पर इसमें व्यापक contract भी छिप सकता है। खतरनाक मामले अक्सर सामान्य maintenance work होते हैं: search_logs का नाम query_logs हो जाता है, schema में optional project field जुड़ जाती है और service remote project identifiers स्वीकार करने लगती है। नाम मुश्किल से बदला है, अधिकार बदल गया है।

ऐसा comparison record बनाएं जो दबाव में भी इस्तेमाल करने लायक साधारण हो। हर पुराने और नए टूल के लिए नाम, description, JSON Schema, मौजूद होने पर declared read-only या destructive annotations, backing endpoint या command, credential identity और ज्ञात side effects दर्ज करें। JSON Schema server के हर behavior को नहीं बताता, इसलिए इसे प्रमाण मानें, पूरा उत्तर नहीं।

यह न्यूनतम inventory shape उपयोगी है:

{
  "name": "query_logs",
  "inputSchema": {
    "type": "object",
    "properties": {
      "project": {"type": "string"},
      "query": {"type": "string"}
    },
    "required": ["query"]
  },
  "destination": "logs-api",
  "credential": "logs-read",
  "effects": ["read"]
}

यह जिस गलती को रोकता है, वह खराब request नहीं है। यह reviewer को rename मंजूर करते समय नया project selector भूलने से बचाता है, जो local query को कई projects से data retrieval में बदल सकता है।

अगर पुराने और नए record में destination, credential, effects या argument scope अलग हो, तो उसे नई capability मानें और restart करें। पीछे का behavior पहचान न सकें तो भी restart करें। "शायद वही है" समीक्षा का नतीजा नहीं है।

Schema में बदलाव descriptions से अधिक महत्वपूर्ण हैं

टूल का नाम वही रह सकता है, फिर भी वह ज्यादा खतरनाक बन सकता है। Input schemas अक्सर बताते हैं कि ऐसा कहां होता है: नए URL fields, path fields, account selectors, free-form command strings, recipient lists और execution mode बदलने वाले optional flags।

मान लें कि टूल की शुरुआत इस input से होती है:

{
  "type": "object",
  "properties": {"issue_id": {"type": "string"}},
  "required": ["issue_id"]
}

बाद में यह include_private_notes या destination_url स्वीकार करने लगता है। पहला field बदलता है कि टूल क्या पढ़ता है। दूसरा बाहर जाने का रास्ता जोड़ता है। किसी को नई मंजूरी की सीमा चाहिए हो, इसके लिए टूल का नाम नाटकीय ढंग से बदलना जरूरी नहीं।

Descriptions भी बदलती रहती हैं। कोई server schema बदले बिना "Get release details" को "Get and update release details" कर सकता है। Descriptions पढ़ें, लेकिन वहीं न रुकें। Owner से पूछें कि कौन-सा handler चलता है, वह किस principal का इस्तेमाल करता है और क्या वह outbound requests भेजता है। अच्छे उत्तर में command, endpoint या service account का नाम होता है। "यह बस internal helper है" कोई उपयोगी जानकारी नहीं देता।

MCP specification टूल metadata और annotations की अनुमति देता है, लेकिन annotation support और client interpretation अलग-अलग हो सकते हैं। इन्हें सहायक labels की तरह लें। केवल read-only जैसे label के आधार पर मंजूरी न दें, जब call आखिर में general-purpose endpoint तक पहुंचता हो।

नया run ऐसी सीमा बनाता है जिसे समझाया जा सके

जब inventory बदलने के बाद मंजूरी का अर्थ बदल जाए, तब नया run जरूरी है। इस सीमा का व्यावहारिक महत्व है: यह वर्तमान process को रोकती है, अगली मंजूरी को किसी ज्ञात executable से जोड़ती है और आपके records में पुराने calls को नए calls से अलग करती है।

प्रक्रिया छोटी है:

1. Inventory में अनपेक्षित बदलाव होने पर आगे की tool calls रोक दें।
2. पुराने और नए inventories को सहेजें, उपलब्ध हो तो schemas और server version भी।
3. हर अंतर को removed, renamed, modified या added चिह्नित करें।
4. अगर कोई अंतर data access, effects, destination scope या credential scope बढ़ाता है तो restart करें।
5. नए run को तभी मंजूर करें जब आप सामान्य भाषा में उसकी अनुमति वाली action surface बता सकें।

सिर्फ रीति निभाने के लिए restart न करें। इसलिए restart करें कि वह पहले की एक खास मंजूरी को अमान्य कर देता है। यही अंतर नियम को उपयोगी रखता है। हर spelling correction पर restart करने वाली टीम नियम को नजरअंदाज करने लगती है। नए अधिकार पर restart करने वाली टीम उसे पहचानना सीखती है।

Per-session authorization तब अच्छा काम करता है जब मंजूरी ऐसे process से बंधी हो जो बंद होता है। Sallyport इसी मॉडल का पालन करता है: वह नए agent process की code-signing authority दिखाता है, फिर process बंद होने तक उस run की मंजूरी बनाए रखता है। Actions के दायरे के बढ़ने पर बदली हुई inventory फिर भी उस process को समाप्त करने का कारण है।

Per-call approval उन कार्रवाइयों के लिए है जिन्हें जानबूझकर कठिन रखना चाहिए

Per-call approval उन कार्रवाइयों के लिए है जिनके नतीजे इतने बड़े हों कि वे व्यापक session approval में छिप न जाएं। इसे production changes, destructive operations, public messages, financial actions और ऐसे requests के लिए रखें जो runtime पर चुने गए destination तक sensitive data भेज सकते हैं।

कुछ टीमें इसे natural-language conditions की लंबी allowlist से हल करने की कोशिश करती हैं। यह तरीका इसलिए लोकप्रिय रहता है कि इसमें कम interruptions का वादा होता है। साथ ही यह reviewers को एक कमजोर rules engine दे देता है, जिसे एजेंट चलते समय समझना पड़ता है। सुरक्षित design में कुछ स्पष्ट विकल्प होते हैं: vault लॉक होने पर मना करें, सीमित run के लिए किसी ज्ञात process को मंजूरी दें या किसी खास credential के इस्तेमाल पर क्लिक मांगें।

Sallyport की per-call key setting इसी आखिरी श्रेणी में आती है। एजेंट कार्रवाई करने का अनुरोध कर सकता है, लेकिन उसे API key या SSH key plaintext में कभी नहीं मिलती। इससे credential leakage कम होता है और व्यक्ति यह तय करता रहता है कि यह खास request machine से बाहर जानी चाहिए या नहीं।

हर कार्रवाई को per-call न बनाएं। अगर हर सामान्य read पर बार-बार prompts आएंगे, तो लोग पढ़े बिना मंजूरी दे देंगे। रुकावट वहां रखें जहां वह सोच-विचार बचाती है।

Audit record विवादित बदलाव में भी काम आना चाहिए

Audit trail को यह बताना चाहिए कि कौन-सा agent process चला, उसने क्या call किया और call से पहले किसी ने उपलब्ध surface बदली या नहीं। जब विवाद यह हो कि "क्या session मंजूर करते समय वह टूल उपलब्ध था?", तब केवल अंतिम request log करना पर्याप्त नहीं है।

Session records के साथ stable digest वाली inventory snapshot रखें। टूल नाम, canonical schema, server identity और client द्वारा देखे जाने का समय दर्ज करें। बदलाव होने पर दोनों snapshots और classification decision सुरक्षित रखें। शुरुआत के लिए जटिल database की जरूरत नहीं है। Raw discovery response वाला signed या tamper-evident record, अगली सुबह की मौखिक पुनर्रचना से कहीं बेहतर है।

Sallyport अपने Sessions journal में agent runs और Activity journal में individual calls दर्ज करता है। दोनों एक encrypted hash-chained audit log से तैयार होते हैं। उसका sp audit verify command vault key के बिना ciphertext पर offline उस chain की जांच करता है। बदलाव के बाद यह उपयोगी सबूत है, लेकिन तभी जब टीम यह भी दर्ज करे कि run ने कौन-सी inventory देखी थी।

Hash chain सुरक्षित रखी entries में बदलाव पकड़ लेती है। यह साबित नहीं करती कि हर component में हर event log हुआ, न ही बताती है कि मंजूरी सही थी या नहीं। इन दावों को अलग रखें। जब लोग एक ही mechanism से उन सवालों के उत्तर मांगते हैं जिनके लिए वह बना नहीं है, तो security reviews कमजोर होते हैं।

Dynamic discovery को deployment event मानें

अगर आपका MCP server client restart किए बिना टूल बदल सकता है, तो टीम ने लाइव control channel में प्रभावी रूप से नई action surface deploy कर दी है। इस event पर release discipline लागू करें: owner पहचानें, diff की समीक्षा करें, अपेक्षित authority स्पष्ट लिखें और ऐसा record बनाएं जिसे बाद का investigator पढ़ सके।

सबसे पहला व्यावहारिक कदम है हर agent run की शुरुआत में inventory snapshot जोड़ना और किसी refresh के लागू होने से पहले उसकी तुलना करना। किसी बड़े incident का इंतजार न करें। एक optional destination field जोड़ने वाला मामूली rename ही ऐसा बदलाव है जो व्यस्त और सक्षम लोगों की नजर से निकल जाता है।