यह कहाँ तक पहुँच सकता है
ईमानदार सीमा।
कौन से टूल मौजूद हैं, यह आपका रोल तय करता है
सर्वर आपकी ही तरह काम करता है, उस कनेक्शन पर जिसे आपने सक्रिय किया है। कोई अलग सर्विस अकाउंट नहीं है और आपकी अपनी पहुँच से ज़्यादा कोई पहुँच नहीं। रोल आने के बाद से आपके रोल से ज़्यादा भी कोई पहुँच नहीं है। क्लाइंट को दी जाने वाली टूल सूची उन अनुमतियों से बनती है जो सक्रिय वर्कस्पेस में आपके पास हैं, इसलिए किसी व्यूअर के क्लाइंट में sendEmail, createRule या sendWithTemplate सूचीबद्ध होते ही नहीं।
यह कॉल को अस्वीकार करने से कहीं मज़बूत बात है। सूची में जो टूल है ही नहीं, मॉडल उस पर सोचता नहीं, वह कॉन्टेक्स्ट नहीं खाता, और किसी की ओर से उसे आज़माकर बाद में उसकी माफ़ी नहीं माँगी जा सकती। इसका यह भी मतलब है कि खाली दिखने वाला क्लाइंट आमतौर पर वह अनुमति है जो आपके पास नहीं, न कि इस सर्वर में गायब कोई सुविधा, और whoAmI ठीक यही बताने के लिए मौजूद है।
रजिस्ट्रेशन और इनवोकेशन दो द्वार हैं, और टिकता सिर्फ़ दूसरा है। सूची एक ही बार बनती है, सेशन खुलते समय, और setActiveConnection उस सेशन को ऐसे मेलबॉक्स में ले जा सकता है जहाँ आप कम कर सकते हैं, इसलिए सूची बनावट से ही बासी है और प्रोटोकॉल के पास सेशन के बीच में कोई टूल वापस लेने का रास्ता नहीं। इसलिए हर नियंत्रित टूल चलने से पहले आपके रोल को उसी कनेक्शन के सामने दोबारा हल करता है जो इस समय सक्रिय है। रजिस्ट्रेशन शिष्टाचार है; इनवोकेशन सीमा है।
अस्वीकृति दोनों हिस्सों का नाम लेती है, जैसे Refused (missing_permission): your role in this mailbox is Viewer, which does not include “Send email”, ताकि कोई एजेंट जिस व्यक्ति के लिए काम कर रहा है उसे यह समझा सके और कोशिश करना बंद कर दे, बजाय इसके कि किसी अपारदर्शी त्रुटि को तब तक दोहराता रहे जब तक कोई हार न मान ले। सेशन खुले रहते हुए किसी एडमिन का बदला हुआ रोल भी ठीक अगली कॉल पर इसी तरह सामने आता है।
पते दूसरी धुरी हैं और इनमें से किसी बात का उन पर असर नहीं पड़ता। रोल बताता है कि आप क्या कर सकते हैं; आपको दिए गए पते बताते हैं कि किन मेलबॉक्स पर कर सकते हैं, और संदेश निकलने से पहले दोनों का सहमत होना ज़रूरी है।
टोकन खुद अब भी बिना स्कोप का है
जो नहीं बदला है वह है ग्रांट। किसी ऐप को मिलने वाला टोकन वहाँ तक पहुँचता है जहाँ तक आपका रोल इजाज़त देता है, न कि उस हिस्से तक जिसे आपने मंज़ूरी देते समय चुना था, इसलिए किसी क्लाइंट को मंज़ूरी देना उसे वह सब करने की मंज़ूरी देना है जो आप उस वर्कस्पेस में कर सकते हैं। कुछ भी दिए जाने से पहले आपको दिखाया जाता है कि माँग कौन कर रहा है, और बाद में Account → Connected apps उसे हटा देता है, उसके सारे टोकन और उनके पीछे की मंज़ूरी मिटाते हुए, लेकिन “सिर्फ़ पढ़ने के लिए, इस ऐप के लिए” चुनने की सुविधा बनी ही नहीं है।
इसलिए किसी MCP क्लाइंट की छत वही है जो आपकी अपनी छत है। किसी ऐप का दायरा घटाने का मतलब है उस व्यक्ति का रोल घटाना जिसने उसे जोड़ा, जिससे ऐप में उसका अपना दायरा भी घट जाता है। आज इसकी ईमानदार शक्ल यही है, और यही वजह है कि प्रति-ग्रांट स्कोप बनाना अब भी सार्थक है।
शब्दावली पहले से साझा है: किसी रोल की अनुमतियाँ और किसी API key के स्कोप एक ही वर्णमाला से लिए गए हैं, और इसी से किसी key का अधिकार दोनों के प्रतिच्छेदन के रूप में निकाला जा सकता है। प्रति-ग्रांट MCP स्कोप जब आएगा तो उन्हीं शब्दों में कहा जाएगा।