Business Owners के लिए MCP: साझा भाषा, हर Access पर Permission

Owner demo में assistant को stock question का जवाब देते देखती हैं। सोमवार तक उसे orders, inventory और accounting से जोड़ना चाहती हैं। Operations lead का सवाल अलग है: branch manager पूछे तो assistant असल में किस branch के records देख सकेगा?

Retailer काल्पनिक है, लेकिन खरीदने से पहले यही चर्चा जरूरी है। Common connection format integration का काम घटा सकता है; अकेले company permissions तय करना, हर answer सही करना या data local रखना उसके बस में नहीं। MCP, यानी Model Context Protocol, साझा भाषा देता है; boundaries लोग तय करते हैं।

यह operations-AI series का भाग 2 है। भाग 1 agent के लिए उपयुक्त काम चुनता है; भाग 3 approvals और audit evidence बताता है। इस connection को समझने के लिए code नहीं चाहिए।

एक साझा भाषा, तीन अलग जिम्मेदारियाँ

MCP बताता है कि AI application दूसरे program की capabilities कैसे discover और इस्तेमाल करे। परिचित plug shape सोचें: compatibility में मदद करती है, लेकिन कौन device इस्तेमाल कर सकता है या वह क्या data दिखाए, shape अकेली तय नहीं करती।

Host वह assistant application है जिसे व्यक्ति इस्तेमाल करता है। उसका client component MCP server से बात करता है। Server permitted requests को business system की existing operations में बदलता है। यह software role है, जरूरी नहीं कि अलग physical machine हो। एक host कई servers से जुड़ सकता है।

Server resources यानी URI से पहचाना context, tools यानी callable functions और prompts यानी reusable message templates दे सकता है। Stock lookup read-only tool भी हो सकता है; “tool” हमेशा write और “resource” हमेशा non-sensitive नहीं। Prompt template access policy नहीं है। Actual host/server कौन-से features support करते हैं, देखें; तीनों होने की धारणा न बनाएँ।

Reusable Components से Permission Paths नहीं मिटते

मानें तीन assistant applications और तीन business systems हैं। साधारण bespoke design में नौ pair-specific integrations रखनी पड़ सकती हैं। MCP repeated protocol work की जगह reusable host/client support और server interfaces देता है—conceptually तीन plus तीन components।

हर assistant हर system इस्तेमाल करे तो अभी भी तीन × तीन = नौ logical access paths configure और authorise करने होंगे। “छह reusable components” का अर्थ “छह live connections” नहीं। Infrastructure share हो सकता है, systems मिल सकते हैं और adapters का effort समान नहीं होता। यह design example है, guaranteed saving नहीं।

Business mapping, units, identifiers, validation और downstream APIs का काम बाकी रहता है। Authoritative rules उस system में रखें जो operation का owner है; screen, API और MCP उन्हें reuse करें। Hosts और model providers की अपनी security responsibilities हैं; MCP हर rule को जादुई single gateway में नहीं ले जाता।

एक Stock Question देखें, पूरी Company न खोलें

हमारे teaching example में manager Store 2 का stock पढ़ सकता है, दूसरे stores के margins या payroll नहीं। वह पूछता है अपनी location से अभी कितनी bottles बेच सकता है। Host permitted stock lookup चलाता है; server data लौटाने से पहले identity, scope, store और field access जाँचता है।

Snapshot time पर physical on-hand 50 है, जिसमें quality hold की 5 units शामिल हैं। Approved 45 में 20 पहले reserved हैं। इसलिए current free approved stock 50 − 5 − 20 = 25 है। इस example में categories overlap नहीं करतीं। System का “available” figure पहले holds/reservations घटाता हो तो उन्हें दोबारा न घटाएँ।

Answer में location, units, status basis और evidence time आएँ। Database में मौजूद होने से customer address या supplier cost भेजना जरूरी नहीं। Free 25 units snapshot हैं, delivery promise या future-demand forecast नहीं; अगला order availability बदल सकता है।

Manager दूसरी store की restricted figures माँगे तो retrieval से पहले deny हो। Records पहले model context, cache या log में जाएँ तो सिर्फ final sentence filter करना देर है। बाद का draft purchase order अलग permission और workflow है; stock answer से खरीद का अधिकार नहीं मिलता।

Identity, Consent और Business Rights अलग जाँच हैं

Protected remote HTTP connections के लिए supplier के साथ MCP authorisation specification देखें। यह OAuth-based framework देता है। Protocol पर authorisation optional है; इसका अर्थ private ERP data anonymous खोलना नहीं। Local stdio processes के लिए वही HTTP OAuth flow prescribed pattern नहीं; credentials और operating-system access अलग control करें।

Sign-in user पहचानता है, consent client access authorise करता है, scopes token सीमित करते हैं और application rules तय करते हैं कि यह user यह record पढ़ या action approve कर सकता है या नहीं। OAuth हर ERP role, record filter या approval अपने आप reproduce नहीं करता। हर call पर user rights, delegated scope और current policy लागू हों।

Token audience/resource validation, लागू जगह PKCE, secure storage, expiry, revocation और user-disable checks कैसे होते हैं, पूछें। कोई भी stolen credentials या compromised host का universal shield नहीं। Shortcut में एक service का token unrelated service तक passthrough न करें। Unattended काम की limited service identity, owner और review हो; चुपचाप manager बनकर नहीं।

Local MCP server executable software है। Trusted publisher और controlled version चुनें; उसे कौन-सी files, credentials और network destinations मिलती हैं, समझें। “मेरे laptop पर चलता है” security certificate नहीं है।

Connect करने से पहले Data Journey देखें

Server ERP के पास और host/model बाहर चल सकते हैं। Host तय करता है returned context का कितना हिस्सा model या दूसरे service को जाए; हर byte automatically forward होना जरूरी नहीं। Prompts, results, caches, logs, support access, subprocessors, retention और training terms सहित actual journey देखें।

Minimum जरूरी fields, permitted records और approved model destination लें। Customer text, internal notes और supplier files में hostile instructions हो सकती हैं; company के भीतर होना उन्हें authority नहीं देता। Tool description या read-only hint भी safe implementation का प्रमाण नहीं। Model गलत माँग करे तब भी application checks लागू रहें।

Vendor से table की boundaries दिखाने को कहें। Audit evidence घटना investigate करने में मदद करता है; log होने मात्र से घटना रुकती नहीं। Access control और redaction रखें; हर raw argument/result अनिश्चित समय तक न जमा करें।

Boundary	Vendor से माँगने वाला Practical Proof
Identity और Records	ID देने पर भी दूसरी store का restricted record नहीं मिलता
Data Minimisation	Stock response में private cost, address या unrelated field नहीं
Action Control	Draft hidden reserve/send नहीं करता; execution में proper approval
Failure Recovery	Unknown committed result reconcile; retry duplicate न बनाए
Evidence और Revocation	Restricted, redacted audit; stated disable/revocation policy पर access बंद

Version पूछें, Scaling का वादा न खरीदें

इस review में official 2026-07-28 specification जाँची गई, जिसका core self-contained requests उपयोग करता है। पुराने revisions connection-scoped sessions रखते थे। दोनों ends के actual revision, transport, optional features, compatibility tests और update owner पूछें।

Protocol stateless होने से purchase workflow stateless नहीं होता और shared business data खत्म नहीं होता। Authentication, capacity, database consistency, operation references और long-running work का design अभी चाहिए। Protocol version से यह सिद्ध नहीं कि load balancers जोड़कर ERP safely scale हो जाएगा।

पहली Connection इतनी छोटी हो कि जाँच सकें

एक manager, एक location और एक useful lookup चुनें। Allowed fields, evidence freshness, provider destination और owner लिखें। Empty, stale और ambiguous cases सहित source system से answers मिलाएँ। Forbidden record सीधे माँगकर देखें, केवल menu hidden देखकर नहीं।

Document में instruction, expired/revoked access, बदली tool definition और provider outage जाँचें। Write tool जोड़ने से पहले exact-version approval, सच में inert draft और commit के बाद timeout test करें। Bounded backoff/retry से पहले existing operation reconcile करें; duplicate commitment रोकें और unknown outcome का owner हो। Denied/invalid requests बार-बार retry न करें।

Tests और business value सही हों तभी access बढ़ाएँ, चार सप्ताह बीतने से नहीं। StoreConsole demo चर्चा के workflows दिखाता है; आपके installation का कोई खास MCP host, version या permission enabled होने का प्रमाण नहीं।

Retailer का उपयोगी सोमवार सीधा है: manager अपनी store में timestamp सहित 25 free approved bottles verify कर सकता है, दूसरों का data नहीं खींच सकता। MCP ने दोनों programs को request समझाई; tested access policy ने वही answer उचित बनाया।

समीक्षा: 5 नवंबर 2026। Anichur Rahaman StoreConsole के निर्माता हैं। Retailer, stock quantities और connection counts teaching examples हैं।