जर तुम्ही अनेक वर्षे PHP ॲप्लिकेशन्समध्ये बिझनेस लॉजिक (business logic) सांभाळण्यात घालवली असतील, तर Model Context Protocol चे ट्युटोरियल्स पाहणे एखाद्या बंद दरवाजाबाहेर उभे राहण्यासारखे वाटू शकते. जवळजवळ प्रत्येक मार्गदर्शिका TypeScript किंवा Python गृहीत धरते. ते अधिकृत SDKs, npm installs आणि pip packages बद्दल सांगतात. यामुळे ग्राहकांचे रेकॉर्ड्स, ऑर्डर हिस्ट्री, इन्व्हेंटरी सिस्टम्स यांसारखा प्रचंड प्रमाणात बिझनेस डेटा PHP कोडबेसमध्येच राहतो, जो सध्याच्या AI टूल्सच्या लाटेसाठी अदृश्य वाटतो.

चांगली बातमी ही आहे की MCP साठी त्या SDKs ची आवश्यकता नाही. MCP ही कोणतीही लायब्ररी (library) नाही. तो एक वायर प्रोटोकॉल (wire protocol) आहे. जर तुमच्या रनटाइमला (runtime) standard input मधून मजकुराची एक ओळ वाचता येत असेल, JSON parse करता येत असेल आणि JSON परत लिहू शकत असेल, तर तो या प्रोटोकॉलशी संवाद साधू शकतो. LLMs अस्तित्वात येण्यापूर्वीपासूनच PHP हेच करत आले आहे.

MCP नक्की काय आहे

MCP म्हणजे Model Context Protocol. मूळतः, हे AI असिस्टंट्सना डेटा, टूल्स आणि बाह्य APIs शी जोडण्यासाठी एक ओपन स्टँडर्ड आहे. प्रत्येक असिस्टंट किंवा मॉडेलसाठी वेगळे कस्टम इंटिग्रेशन तयार करण्याऐवजी, तुम्ही एक सुसंगत इंटरफेस (compliant interface) तयार करता. MCP समजणारा कोणताही क्लायंट PHP, Laravel किंवा तुमच्या विशिष्ट डेटाबेस स्कीमाबद्दल काहीही न जाणून घेता तुमच्या सर्व्हरशी संवाद साधू शकतो.

अंतर्गतरीत्या, MCP JSON-RPC 2.0 वापरते. याचा अर्थ असा की प्रत्येक विनंती (request) ही एक साधी JSON ऑब्जेक्ट आहे ज्यामध्ये मेथडचे नाव, पॅरामीटर्स आणि एक ID असतो. सर्व्हर रिझल्ट किंवा एररसह दुसऱ्या JSON ऑब्जेक्टद्वारे प्रतिसाद देतो.

सर्व्हर तीन प्रिमिटिव्ह्स (primitives) उपलब्ध करून देतो:

  • Tools: मॉडेल कार्यान्वित करू शकणारी कृती (Actions). एखादे टूल डेटाबेस क्वेरी करू शकते, स्टेटस अपडेट करू शकते किंवा थर्ड-पार्टी API कॉल करू शकते.
  • Resources: स्टॅटिक किंवा सेमी-स्टॅटिक डेटा ज्याचा संदर्भ मॉडेल URI द्वारे देऊ शकते. फाईल्स, कॉन्फिगरेशन डॉक्युमेंट्स किंवा रेफरन्स डेटासेट्सचा विचार करा.
  • Prompts: वापरकर्त्याला सिस्टमशी संवाद साधण्यास मदत करणारे पूर्व-निर्धारित टेम्पलेट्स (predefined templates).

लक्षात ठेवण्यासारखा एक महत्त्वाचा नियंत्रणाचा फरक आहे. Tools हे मॉडेलद्वारे नियंत्रित असतात. असिस्टंटने कधी कॉल करायचा हे तो स्वतः ठरवतो. Resources हे ॲप्लिकेशनद्वारे नियंत्रित असतात. कोणता डेटा उपलब्ध आहे हे सर्व्हर ठरवतो आणि मॉडेल फक्त उपलब्ध असलेला डेटा वाचते. हे योग्यरित्या समजून घेतल्यास तुमचे आर्किटेक्चर (architecture) प्रेडिक्टेबल राहते. तुम्हाला मॉडेलने अशा रिसोर्सेसचा शोध घ्यावा असे वाटणार नाही ज्यांचे टूल्स असायला हवे होते, किंवा याच्या उलट.

ट्रान्सपोर्ट (Transport) कसे कार्य करते

MCP दोन ट्रान्सपोर्ट पद्धती परिभाषित करते आणि तुमची निवड तुम्ही PHP बाजू कशी लिहिता हे ठरवते.

stdio ही सर्वात सोपी पद्धत आहे. MCP क्लायंट तुमच्या PHP स्क्रिप्टला सबप्रोसेस (subprocess) म्हणून सुरू करतो. क्लायंट तुमच्या स्क्रिप्टच्या standard input मध्ये JSON-RPC मेसेजेस लिहितो आणि तुमची स्क्रिप्ट standard output मध्ये प्रतिसाद लिहिते. येथे मॅनेज करण्यासाठी कोणतेही सॉकेट्स (sockets) नाहीत, कोणतेही पोर्ट्स उघडण्याची गरज नाही आणि कोणतेही ऑथेंटिकेशन हेडर्स पार्स करण्याची गरज नाही. जर तुमचे टूल आणि क्लायंट एकाच मशीनवर असतील, तर सुरुवात करण्यासाठी ही सहसा योग्य पद्धत आहे.

stdio वर चालताना तुमच्या PHP प्रोसेसवर दोन कडक नियम लागू होतात. पहिले म्हणजे, तुमच्या ॲप्लिकेशनने stdout मध्ये कधीही नॉन-प्रोटोकॉल डेटा लिहू नये. जर तुम्ही एखादे debug स्टेटमेंट echo केले किंवा PHP notice लीक होऊ दिली, तर क्लायंटचा पार्सर (parser) बिघडेल. सर्व लॉगिंग आणि डायग्नोस्टिक्स stderr कडे वळवा. दुसरे म्हणजे, आउटपुट बफरिंग (output buffering) पूर्णपणे बंद करा. PHP ला stdout बफर करायला आवडते, विशेषतः CGI किंवा वेब संदर्भात, परंतु CLI स्क्रिप्ट्स देखील डेटा धरून ठेवू शकतात. प्रत्येक प्रतिसाद त्वरित फ्लश (flush) करा. जर तुम्ही स्ट्रीम्स वापरत असाल, तर stream_set_write_buffer(STDOUT, 0) सेट करा किंवा इम्प्लिसिट बफरिंग बंद करा जेणेकरून तुम्ही पाठवताच क्लायंटला न्यूलाइन (newline) मिळेल.

Streamable HTTP वेगळ्या पद्धतीने काम करते. तुमचे PHP ॲप्लिकेशन एका पर्सिस्टंट (persistent) HTTP एंडपॉइंट म्हणून चालते, ज्यापर्यंत सहसा POST विनंत्यांद्वारे पोहोचता येते. जेव्हा सर्व्हर दुसऱ्या होस्टवर असतो किंवा जेव्हा तुम्हाला असा लाँग-रनिंग डेमन (long-running daemon) हवा असतो ज्यापर्यंत अनेक क्लायंट पोहोचू शकतात, तेव्हा हे उपयुक्त ठरते. PHP मध्ये, याचा अर्थ सहसा पारंपारिक रिक्वेस्ट-रिस्पॉन्स सायकलऐवजी (जी प्रत्येक कॉल नंतर संपते) RoadRunner, FrankenPHP किंवा तत्सम प्रोसेस मॅनेजर अंतर्गत चालवणे असा होतो.

PHP मध्ये ते तयार करणे

सुरुवात करण्यासाठी तुम्हाला कोणत्याही फ्रेमवर्कची गरज नाही. PHP मधील एक मिनिमल (minimal) MCP सर्व्हर म्हणजे STDIN मधून वाचणारा, JSON डिकोड करणारा, हँडलरकडे (handler) पाठवणारा आणि रिझल्ट एन्कोड करणारा एक लूप आहे.

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) क्षमता आहेत. तुमच्या मेथड सिग्नेचर्स तपासा, तुमच्या फॉर्म्स किंवा कमांड ऑब्जेक्ट्समधून अस्तित्वात असलेले व्हॅलिडेशन नियम वाचा आणि त्या कन्सट्रेंट्सवरून स्कीमा तयार करा. जर तुमच्या अंतर्गत कोडला वैध ईमेल फॉरमॅटची आवश्यकता असेल, तर तुमच्या MCP स्कीमामध्येही तेच असले पाहिजे. जेव्हा व्हॅलिडेशन नियम बदलतात, तेव्हा स्कीमा आपोआप अपडेट होतो. कोणताही विसंगती (drift) किंवा शांत अपयश (silent failures) येत नाही.

प्रोटोकॉल त्रुटी आणि टूल त्रुटी वेगळ्या करा. JSON-RPC ची स्वतःची एरर स्पेस आहे. खराब प्रोटोकॉलसाठी (उदा. चुकीचा JSON, अज्ञात मेथड्स किंवा गहाळ विनंती आयडी) याचा वापर करा. जेव्हा एखादे टूल योग्यरित्या कार्यान्वित होते परंतु एखाद्या व्यावसायिक समस्येचा सामना करते, तेव्हा पेलोडमध्ये (payload) एरर फ्लॅगसह सामान्य निकाल परत करा. जर कस्टमर लुकअप टूलला कोणताही जुळणारा रेकॉर्ड सापडला नाही, तर ती प्रोटोकॉल क्रॅश नाही. {"found": false} सारखा स्ट्रक्चर्ड रिझल्ट परत केल्यामुळे मॉडेलला काय झाले हे समजते आणि ते पुढचे पाऊल निवडू शकते. ते कदाचित अधिक व्यापक शोध घेण्याचा प्रयत्न करेल किंवा वापरकर्त्याला स्पष्टीकरण विचारू शकते. जर तुम्ही त्याऐवजी JSON-RPC एरर थ्रो केली, तर मॉडेल अनेकदा संदर्भ (context) गमावते.

दीर्घकाळ चालणाऱ्या कामासाठी नियोजन करा. PHP हे लहान विनंत्यांसाठी (short requests) बनवले आहे. एक वेब रिक्वेस्ट तीस सेकंदात टाइम आउट होऊ शकते आणि अगदी CLI स्क्रिप्ट्स देखील मेमरी किंवा संयम संपवू शकतात. जर एखाद्या टूलला पूर्ण होण्यासाठी मिनिटे लागणार असतील—कदाचित ते मोठा रिपोर्ट तयार करत असेल किंवा सिस्टिम्समध्ये डेटा सिंक करत असेल—तर मॉडेलला वाट पाहायला लावू नका. लगेच एक जॉब आयडेंटिफायर (job identifier) परत करा. त्यानंतर, त्या ID द्वारे स्टेटस तपासण्यासाठी दुसरे टूल उपलब्ध करून द्या. तुम्ही प्रगती (progress) Redis, डेटाबेस टेबल किंवा कमी व्हॉल्यूम असल्यास फ्लॅट फाईलमध्ये साठवू शकता. मॉडेलला ID मिळतो, ते नंतर पुन्हा तपासते आणि शेवटी पूर्ण झालेला निकाल घेते.

मॉडेलकडे कीज (Keys) असताना सुरक्षा

AI मॉडेलला टूलचा प्रवेश देणे म्हणजे एखाद्या मानवी वापरकर्त्याला प्रवेश देण्यासारखे नाही. मॉडेल वेगाने काम करते आणि ते वर्णनांचा चुकीचा अर्थ लावू शकते. प्रत्येक उघड केलेल्या टूलकडे 'प्रिव्हिलेज एस्केलेशन रिस्क' (privilege escalation risk) म्हणून पहा.

व्याप्ती (scope) आक्रमकपणे मर्यादित करा. कधीही सामान्य run_sql टूल उघड करू नका. find_customer_by_email किंवा update_order_status सारखी विशिष्ट आणि मर्यादित टूल्स तयार करा. मॉडेलने तुम्ही दिलेल्या पॅरामीटर्ससह आणि तुम्ही दिलेल्या नावाप्रमाणेच नेमके काम केले पाहिजे.

रीड (read) आणि राईट (write) पाथ्स वेगळे करा. रीड-ओन्ली टूल्समध्ये कमी धोका असतो. कोणत्याही विनाशकारी कृतीला (destructive action) स्पष्ट कन्फर्मेशन मेकॅनिझमच्या मागे ठेवा किंवा पूर्णपणे दुसऱ्या सर्व्हरपुरते मर्यादित करा. जर तुमचा क्लायंट सपोर्ट करत असेल, तर राईट टूल कार्यान्वित होण्यापूर्वी मानवी मंजुरीची पायरी आवश्यक करा.

टूलची वर्णने अशा प्रकारे लिहा की जणू ती अतिरिक्त सूचना आहेत, कारण ती तशीच आहेत. मॉडेलने टूल कधी कॉल करावे याबद्दल अचूक असावे. जर एखादे टूल किंमत (pricing) शोधत असेल, तर तसे स्पष्ट सांगा. जर ते फक्त कस्टमर आयडी सत्यापित केल्यानंतरच वापरले जावे, तर ते स्पष्टपणे नमूद करा. अस्पष्ट वर्णनांमुळे अस्पष्ट वर्तन होते.

तुमचा आउटपुट फिल्टर करा. संपूर्ण Eloquent मॉडेल किंवा Doctrine entity सिरीयलाईज करून निकालामध्ये टाकू नका. मॉडेलला खरोखर ज्या फील्ड्सची गरज आहे तीच परत करा. अंतर्गत फील्ड्स—जसे की खरेदी किंमत (cost prices), कर्मचारी नोट्स, डेटाबेस आयडी जे अंतर्गत राहिले पाहिजेत—त्यांना बाहेर पाठवण्याची गरज नाही. तुमच्या रिटर्न शेप (return shape) बद्दल स्पष्ट रहा.

शेवटी, सर्व काही लॉग करा. टूलचे नाव, पास केलेले आर्ग्युमेंट्स आणि निकाल रेकॉर्ड करा. जर मॉडेल एखाद्या महागड्या क्वेरीवर लूपिंग करू लागले किंवा अनपेक्षित क्रमाने टूल्स तपासू लागले, तर तुमचे लॉग्स हेच ते पाहण्याचे एकमेव साधन असतील.

सुरुवात कोठून करावी

तुमचे PHP ॲप्लिकेशन AI असिस्टंटशी जोडण्यासाठी तुम्हाला SDK मेंटेनर्सच्या परवानगीची गरज नाही. तुम्हाला फक्त JSON-RPC, एक लूप आणि stdout च्या बाबतीत शिस्त हवी आहे.

पहिल्याच दिवशी तुमचे संपूर्ण API MCP टूल्स म्हणून पुन्हा तयार करण्याच्या इच्छेला रोखा. तुमच्या संस्थेतील कोणीतरी वारंवार विचारत असलेल्या तीन रीड-ओन्ली ऑपरेशन्स निवडा. कदाचित ते ऑर्डर स्टेटस तपासणे, कस्टमर समरी काढणे किंवा अलीकडील इनव्हॉइसची यादी करणे असू शकते. त्यांना टूल्स म्हणून गुंडाळा (wrap), stdio द्वारे सर्व्ह करा आणि एका सहकाऱ्याला ते वापरू द्या. मॉडेल काय चांगले करते आणि कुठे अडखळते ते पहा. तुम्ही तीस टूल्सचे नियोजन करण्यापेक्षा त्या तीन टूल्समधून अधिक शिकाल.

MCP हा एक पूल (bridge) आहे, तुमच्या ॲप्लिकेशनचा पर्याय नाही. तुमचा PHP कोड आधीच तुमच्या व्यवसायाबद्दल जाणतो. प्रोटोकॉल फक्त मॉडेलला पलीकडे जाण्यास आणि प्रश्न विचारण्यास मदत करतो.