If you have spent years maintaining business logic inside PHP applications, watching Model Context Protocol tutorials ca

यदि आपने वर्षों तक PHP एप्लिकेशन के भीतर बिजनेस लॉजिक (business logic) को बनाए रखने में बिताए हैं, तो Model Context Protocol के ट्यूटोरियल देखना एक बंद दरवाजे के बाहर खड़े होने जैसा महसूस हो सकता है। लगभग हर गाइड TypeScript या Python को मानकर चलती है। वे आधिकारिक SDKs, npm इंस्टॉलेशन और pip पैकेज के बारे में बताते हैं। इससे भारी मात्रा में बिजनेस डेटा—ग्राहक रिकॉर्ड, ऑर्डर हिस्ट्री, इन्वेंट्री सिस्टम—PHP कोडबेस में पड़ा रह जाता है, जो AI टूल्स की वर्तमान लहर के लिए अदृश्य दिखाई देता है।

अच्छी खबर यह है कि MCP के लिए उन SDKs की आवश्यकता नहीं है। MCP कोई लाइब्रेरी नहीं है। यह एक वायर प्रोटोकॉल (wire protocol) है। यदि आपका रनटाइम standard input से टेक्स्ट की एक लाइन पढ़ सकता है, JSON को पार्स (parse) कर सकता है, और वापस JSON लिख सकता है, तो वह इस प्रोटोकॉल को समझ सकता है। PHP LLMs के अस्तित्व में आने से बहुत पहले से बिल्कुल यही काम कर रहा है।

MCP वास्तव में क्या है

MCP का अर्थ Model Context Protocol है। मूल रूप से, यह AI असिस्टेंट को डेटा, टूल्स और बाहरी APIs से जोड़ने के लिए एक ओपन स्टैंडर्ड है। हर असिस्टेंट या मॉडल के लिए कस्टम इंटीग्रेशन बनाने के बजाय, आप एक अनुपालन करने वाला (compliant) इंटरफ़ेस बनाते हैं। कोई भी क्लाइंट जो MCP को समझता है, वह PHP, Laravel, या आपके विशिष्ट डेटाबेस स्कीमा के बारे में कुछ भी जाने बिना आपके सर्वर से बात कर सकता है।

इसके पीछे, MCP JSON-RPC 2.0 का उपयोग करता है। इसका मतलब है कि प्रत्येक अनुरोध (request) एक सरल JSON ऑब्जेक्ट है जिसमें एक मेथड का नाम, पैरामीटर्स और एक ID होती है। सर्वर एक अन्य JSON ऑब्जेक्ट के साथ उत्तर देता है जिसमें या तो परिणाम (result) या त्रुटि (error) होती है।

एक सर्वर तीन प्रिमिटिव्स (primitives) को एक्सपोज़ करता है:

• Tools: वे क्रियाएं जिन्हें मॉडल इनवोक (invoke) कर सकता है। एक टूल डेटाबेस को क्वेरी कर सकता है, स्टेटस अपडेट कर सकता है, या किसी थर्ड-पार्टी API को कॉल कर सकता है।
• Resources: स्टैटिक या सेमी-स्टैटिक डेटा जिसे मॉडल एक URI के माध्यम से रेफरेंस कर सकता है। फाइलों, कॉन्फ़िगरेशन दस्तावेज़ों, या रेफरेंस डेटासेट के बारे में सोचें।
• Prompts: पूर्व-निर्धारित टेम्पलेट्स जो उपयोगकर्ता को सिस्टम के साथ इंटरैक्ट करने में मदद करते हैं।

याद रखने के लिए एक महत्वपूर्ण कंट्रोल अंतर है। Tools मॉडल-नियंत्रित होते हैं। असिस्टेंट तय करता है कि उन्हें कब कॉल करना है। Resources एप्लिकेशन-नियंत्रित होते हैं। सर्वर तय करता है कि कौन सा डेटा उपलब्ध है और मॉडल केवल वही पढ़ता है जो उसे दिया जाता है। इसे सही ढंग से लागू करने से आपका आर्किटेक्चर प्रेडिक्टेबल (predictable) रहता है। आप नहीं चाहेंगे कि मॉडल उन रिसोर्सेज की तलाश करे जिन्हें टूल्स होना चाहिए था, या इसके विपरीत।

ट्रांसपोर्ट कैसे काम करता है

MCP दो ट्रांसपोर्ट विधियों को परिभाषित करता है, और आपका चुनाव यह तय करता है कि आप PHP साइड को कैसे लिखते हैं।

stdio सबसे सरल है। MCP क्लाइंट आपके PHP स्क्रिप्ट को एक सबप्रोसेस (subprocess) के रूप में लॉन्च करता है। क्लाइंट आपके स्क्रिप्ट के standard input पर JSON-RPC मैसेज लिखता है, और आपकी स्क्रिप्ट standard output पर रिस्पॉन्स लिखती है। यहाँ मैनेज करने के लिए कोई सॉकेट नहीं हैं, खोलने के लिए कोई पोर्ट नहीं हैं, और पार्स करने के लिए कोई ऑथेंटिकेशन हेडर नहीं हैं। यदि आपका टूल और आपका क्लाइंट एक ही मशीन पर हैं, तो आमतौर पर शुरुआत करने के लिए यही सही जगह है।

stdio पर चलने से आपके PHP प्रोसेस पर दो सख्त नियम लागू होते हैं। पहला, आपके एप्लिकेशन को कभी भी stdout पर नॉन-प्रोटोकॉल डेटा नहीं लिखना चाहिए। यदि आप कोई डिबग स्टेटमेंट (debug statement) echo करते हैं या किसी PHP नोटिस को लीक होने देते हैं, तो आप क्लाइंट के पार्सर को तोड़ देंगे। सभी लॉगिंग और डायग्नोस्टिक्स को stderr पर रूट करें। दूसरा, आउटपुट बफरिंग को पूरी तरह से अक्षम (disable) कर दें। PHP stdout को बफर करना पसंद करता है, विशेष रूप से CGI या वेब कॉन्टेक्स्ट में, लेकिन CLI स्क्रिप्ट भी डेटा को होल्ड कर सकती हैं। प्रत्येक रिस्पॉन्स को तुरंत फ्लश (flush) करें। यदि आप स्ट्रीम का उपयोग कर रहे हैं, तो stream_set_write_buffer(STDOUT, 0) सेट करें या इम्प्लिसिट बफरिंग को बंद कर दें ताकि क्लाइंट को न्यूलाइन (newline) तुरंत मिल जाए जैसे ही आप उसे भेजें।

Streamable HTTP अलग तरह से काम करता है। आपका PHP एप्लिकेशन एक पर्सिस्टेंट (persistent) HTTP एंडपॉइंट के रूप में चलता है, जिसे आमतौर पर POST अनुरोधों के माध्यम से एक्सेस किया जाता है। यह तब उपयोगी होता है जब सर्वर किसी अलग होस्ट पर हो, या जब आप एक लॉन्ग-रनिंग डेमन (daemon) चाहते हैं जिसे कई क्लाइंट एक्सेस कर सकें। PHP में, इसका आमतौर पर मतलब पारंपरिक रिक्वेस्ट-रिस्पॉन्स साइकिल के बजाय RoadRunner, FrankenPHP, या किसी समान प्रोसेस मैनेजर के तहत चलना है, जो हर कॉल के बाद समाप्त हो जाता है।

इसे PHP में बनाना

शुरू करने के लिए आपको किसी फ्रेमवर्क की आवश्यकता नहीं है। PHP में एक न्यूनतम MCP सर्वर STDIN से पढ़ने, JSON को डिकोड करने, एक हैंडलर को डिस्पैच करने और परिणाम को एनकोड करने वाला एक लूप है।

while ($line = fgets(STDIN)) {
    $request = json_decode($line, true);
    // route to tool or resource handler
    // write JSON-RPC response to STDOUT
}

उस लूप के भीतर, असली काम ऐसे इंटरफ़ेस बनाना है जो मॉडल के लिए समझ में आने योग्य हों।

कोड से टूल स्कीमा जेनरेट करें। समस्या पैदा करने के सबसे तेज़ तरीकों में से एक अपने टूल पैरामीटर्स के लिए हाथ से JSON Schemas लिखना है और उन्हें अपने वास्तविक वैलिडेशन लॉजिक से अलग होने देना है। PHP में समृद्ध रिफ्लेक्शन (reflection) क्षमताएं हैं। अपने मेथड सिग्नेचर का निरीक्षण करें, अपने फॉर्म या कमांड ऑब्जेक्ट्स से मौजूदा वैलिडेशन नियमों को पढ़ें, और उन बाधाओं (constraints) से स्कीमा जेनरेट करें। यदि आपके आंतरिक कोड को एक वैध ईमेल फॉर्मेट की आवश्यकता है, तो आपके MCP स्कीमा को भी वही कहना चाहिए। जब वैलिडेशन नियम बदलते हैं, तो स्कीमा स्वचालित रूप से अपडेट हो जाता है। कोई विचलन (drift) नहीं, कोई साइलेंट फेलियर नहीं।

प्रोटोकॉल एरर्स को टूल एरर्स से अलग करें। JSON-RPC का अपना एरर स्पेस है। इसका उपयोग टूटे हुए प्रोटोकॉल के लिए करें: जैसे कि malformed JSON, अज्ञात मेथड्स, या गायब रिक्वेस्ट IDs। जब कोई टूल सही ढंग से निष्पादित होता है लेकिन किसी व्यावसायिक समस्या (business problem) का सामना करता है, तो पेलोड के अंदर एक एरर फ्लैग के साथ एक सामान्य परिणाम लौटाएं। यदि कोई कस्टमर लुकअप टूल कोई मिलान करने वाला रिकॉर्ड नहीं पाता है, तो वह प्रोटोकॉल क्रैश नहीं है। {"found": false} जैसा स्ट्रक्चर्ड रिजल्ट लौटाने से मॉडल समझ पाता है कि क्या हुआ और अगला कदम चुन पाता है। यह एक व्यापक खोज करने का प्रयास कर सकता है, या उपयोगकर्ता से स्पष्टीकरण मांग सकता है। इसके बजाय, यदि आप JSON-RPC एरर थ्रो करते हैं, तो मॉडल अक्सर संदर्भ (context) खो देता है।

लंबे समय तक चलने वाले काम के लिए योजना बनाएं। PHP छोटे अनुरोधों (requests) के लिए बनाया गया है। एक वेब रिक्वेस्ट तीस सेकंड में टाइम आउट हो सकती है, और यहाँ तक कि CLI स्क्रिप्ट भी मेमोरी या धैर्य को समाप्त कर सकती हैं। यदि किसी टूल को पूरा होने में मिनटों का समय लगता है—शायद यह एक बड़ी रिपोर्ट कंपाइल करता है या सिस्टम्स के बीच डेटा सिंक करता है—तो मॉडल को इंतज़ार न कराएं। तुरंत एक जॉब आइडेंटिफायर (job identifier) लौटाएं। फिर उस ID द्वारा स्टेटस चेक करने के लिए एक दूसरा टूल उपलब्ध कराएं। आप प्रोग्रेस को Redis, एक डेटाबेस टेबल, या यदि वॉल्यूम कम है तो एक फ्लैट फ़ाइल में भी स्टोर कर सकते हैं। मॉडल को ID प्राप्त होती है, वह बाद में चेक करता है, और अंततः पूरा हुआ परिणाम प्राप्त कर लेता है।

सुरक्षा जब मॉडल के पास कीज़ (Keys) हों

एक AI मॉडल को टूल का एक्सेस देना किसी मानव उपयोगकर्ता को देने जैसा नहीं है। एक मॉडल शाब्दिक रूप से बहुत तेज़ी से काम करता है, और वह विवरणों (descriptions) का गलत अर्थ निकाल सकता है। प्रत्येक एक्सपोज़्ड टूल को प्रिविलेज एस्केलेशन (privilege escalation) जोखिम के रूप में मानें।

स्कोप को आक्रामक रूप से सीमित करें। कभी भी एक जेनेरिक run_sql टूल एक्सपोज़ न करें। find_customer_by_email या update_order_status जैसे विशिष्ट और सीमित टूल बनाएं। मॉडल केवल वही करने में सक्षम होना चाहिए जो आपने नाम दिया है, और उन्हीं पैरामीटर्स के साथ जिन्हें आपने परिभाषित किया है।

रीड (read) और राइट (write) पाथ को अलग करें। रीड-ओनली टूल में जोखिम कम होता है। किसी भी विनाशकारी (destructive) क्रिया को एक स्पष्ट पुष्टिकरण तंत्र (confirmation mechanism) के पीछे रखें, या इसे पूरी तरह से दूसरे सर्वर तक सीमित कर दें। यदि आपका क्लाइंट इसका समर्थन करता है, तो राइट टूल निष्पादित होने से पहले मानव अनुमोदन (human approval) चरण की आवश्यकता रखें।

टूल के विवरण ऐसे लिखें जैसे कि वे अतिरिक्त निर्देश हों, क्योंकि वे वास्तव में निर्देश ही हैं। इस बारे में सटीक रहें कि मॉडल को टूल कब कॉल करना चाहिए। यदि कोई टूल प्राइसिंग देखता है, तो ऐसा ही कहें। यदि इसका उपयोग केवल कस्टमर ID सत्यापित करने के बाद ही किया जाना चाहिए, तो उसे स्पष्ट रूप से बताएं। अस्पष्ट विवरण अस्पष्ट व्यवहार की ओर ले जाते हैं।

अपने आउटपुट को फ़िल्टर करें। पूरे Eloquent मॉडल या Doctrine entity को सीरियलाइज़ (serialize) करके परिणाम में न डालें। केवल वही फ़ील्ड लौटाएं जिनकी मॉडल को वास्तव में आवश्यकता है। आंतरिक फ़ील्ड—लागत मूल्य (cost prices), कर्मचारी नोट्स, डेटाबेस ID जिन्हें आंतरिक रहना चाहिए—का डेटा ट्रांसफर के दौरान बाहर आना उचित नहीं है। अपने रिटर्न शेप (return shape) के बारे में स्पष्ट रहें।

अंत में, सब कुछ लॉग करें। टूल का नाम, पास किए गए तर्क (arguments), और परिणाम रिकॉर्ड करें। यदि कोई मॉडल किसी महंगे क्वेरी पर लूप करने लगता है या अप्रत्याशित क्रम में टूल की जांच करने लगता है, तो आपके लॉग ही एकमात्र तरीका हैं जिससे आप इसे देख पाएंगे।

कहाँ से शुरू करें

अपने PHP एप्लिकेशन को AI असिस्टेंट से जोड़ने के लिए आपको किसी SDK मेंटेनर से अनुमति की आवश्यकता नहीं है। आपको JSON-RPC, एक लूप, और stdout के आसपास कुछ अनुशासन की आवश्यकता है।

पहले ही दिन अपने पूरे API को MCP टूल के रूप में फिर से बनाने की इच्छा से बचें। तीन रीड-ओनली ऑपरेशन्स चुनें जिनके बारे में आपके संगठन में कोई वास्तव में बार-बार पूछता है। शायद यह ऑर्डर स्टेटस चेक करना हो, कस्टमर समरी निकालना हो, या हाल के इनवॉइस की सूची बनाना हो। उन्हें टूल के रूप में रैप (wrap) करें, उन्हें stdio के माध्यम से सर्व करें, और एक सहकर्मी को उनका उपयोग करने दें। देखें कि मॉडल क्या अच्छी तरह से करता है और कहाँ लड़खड़ाता है। आप उन तीस टूल की योजना बनाने के बजाय उन तीन टूल से अधिक सीखेंगे।

MCP एक पुल है, आपके एप्लिकेशन का विकल्प नहीं। आपका PHP कोड पहले से ही आपके व्यवसाय को जानता है। प्रोटोकॉल बस मॉडल को पार करने और उससे प्रश्न पूछने की अनुमति देता है।