જો તમે વર્ષો સુધી PHP એપ્લિકેશન્સમાં બિઝનેસ લોજિક જાળવવામાં વિતાવ્યા હોય, તો Model Context Protocol ના ટ્યુટોરિયલ્સ જોવું એ બંધ દરવાજાની બહાર ઊભા રહેવા જેવું લાગી શકે છે. લગભગ દરેક માર્ગદર્શિકા TypeScript અથવા Python નો ઉપયોગ કરે છે તેમ માની લે છે. તેઓ સત્તાવાર SDKs, npm ઇન્સ્ટોલ અને pip પેકેજો વિશે વાત કરે છે. આના કારણે ગ્રાહકોના રેકોર્ડ્સ, ઓર્ડર હિસ્ટ્રી, ઇન્વેન્ટરી સિસ્ટમ્સ જેવો વિશાળ બિઝનેસ ડેટા PHP કોડબેઝમાં જ પડ્યો રહે છે, જે AI ટૂલિંગના વર્તમાન તરંગ માટે અદ્રશ્ય લાગે છે.

સારા સમાચાર એ છે કે MCP માટે તે SDKs ની જરૂર નથી. MCP એ કોઈ લાઇબ્રેરી નથી. તે એક વાયર પ્રોટોકોલ છે. જો તમારું રનટાઇમ સ્ટાન્ડર્ડ ઇનપુટમાંથી ટેક્સ્ટની એક લાઇન વાંચી શકે, JSON પાર્સ કરી શકે અને JSON પાછું લખી શકે, તો તે આ પ્રોટોકોલ સમજી શકે છે. LLMs અસ્તિત્વમાં આવ્યાના ઘણા સમય પહેલાથી જ PHP બરાબર આ જ કામ કરી રહ્યું છે.

MCP ખરેખર શું છે

MCP એટલે Model Context Protocol. તેના મૂળમાં, તે AI આસિસ્ટન્ટ્સને ડેટા, ટૂલ્સ અને એક્સટર્નલ APIs સાથે જોડવા માટેનું એક ઓપન સ્ટાન્ડર્ડ છે. દરેક આસિસ્ટન્ટ અથવા મોડલ માટે કસ્ટમ ઇન્ટિગ્રેશન બનાવવાને બદલે, તમે એક સુસંગત (compliant) ઇન્ટરફેસ બનાવો છો. કોઈપણ ક્લાયન્ટ જે MCP સમજી શકે છે તે PHP, Laravel, અથવા તમારા ચોક્કસ ડેટાબેઝ સ્કીમા વિશે કંઈપણ જાણ્યા વગર તમારા સર્વર સાથે વાત કરી શકે છે.

અંદરના સ્તરે, MCP JSON-RPC 2.0 નો ઉપયોગ કરે છે. તેનો અર્થ એ છે કે દરેક રિક્વેસ્ટ એક સાદો JSON ઓબ્જેક્ટ છે જેમાં મેથડનું નામ, પેરામીટર્સ અને એક ID હોય છે. સર્વર પરિણામ (result) અથવા ભૂલ (error) સાથે બીજા JSON ઓબ્જેક્ટ દ્વારા જવાબ આપે છે.

સર્વર ત્રણ પ્રિમીટિવ્સ (primitives) પ્રદાન કરે છે:

  • Tools: એ ક્રિયાઓ જે મોડલ કરી શકે છે. એક ટૂલ ડેટાબેઝ ક્વેરી કરી શકે છે, સ્ટેટસ અપડેટ કરી શકે છે અથવા થર્ડ-પાર્ટી API ને કોલ કરી શકે છે.
  • Resources: સ્ટેટિક અથવા સેમી-સ્ટેટિક ડેટા જેને મોડલ URI દ્વારા સંદર્ભ તરીકે લઈ શકે છે. ફાઇલો, કોન્ફિગરેશન દસ્તાવેજો અથવા રેફરન્સ ડેટાસેટ્સ વિશે વિચારો.
  • Prompts: પૂર્વ-નિર્ધારિત ટેમ્પ્લેટ્સ જે વપરાશકર્તાને સિસ્ટમ સાથે વાતચીત કરવામાં મદદ કરે છે.

યાદ રાખવા જેવું એક મહત્વનું કંટ્રોલ ડિસ્ટિંક્શન (તફાવત) છે. Tools એ મોડલ દ્વારા નિયંત્રિત હોય છે. આસિસ્ટન્ટ નક્કી કરે છે કે ક્યારે તેને કોલ કરવો. Resources એ એપ્લિકેશન દ્વારા નિયંત્રિત હોય છે. સર્વર નક્કી કરે છે કે કયો ડેટા ઉપલબ્ધ છે અને મોડલ ફક્ત જે ઓફર કરવામાં આવ્યું છે તે વાંચે છે. આ બાબતને યોગ્ય રીતે સમજવાથી તમારું આર્કિટેક્ચર અનુમાનિત (predictable) રહે છે. તમે એવું નથી ઈચ્છતા કે મોડલ એવા રિસોર્સિસ શોધે જે ટૂલ્સ હોવા જોઈએ હતા, અથવા તેનાથી ઉલટું.

ટ્રાન્સપોર્ટ કેવી રીતે કામ કરે છે

MCP બે ટ્રાન્સપોર્ટ પદ્ધતિઓ વ્યાખ્યાયિત કરે છે, અને તમારી પસંદગી તમે PHP સાઇડ કેવી રીતે લખો છો તે નક્કી કરે છે.

stdio સૌથી સરળ છે. MCP ક્લાયન્ટ તમારા PHP સ્ક્રિપ્ટને સબપ્રોસેસ તરીકે લોન્ચ કરે છે. ક્લાયન્ટ તમારા સ્ક્રિપ્ટના સ્ટાન્ડર્ડ ઇનપુટ પર JSON-RPC મેસેજ લખે છે, અને તમારી સ્ક્રિપ્ટ સ્ટાન્ડર્ડ આઉટપુટ પર પ્રતિસાદ લખે છે. અહીં મેનેજ કરવા માટે કોઈ સોકેટ્સ નથી, ખોલવા માટે કોઈ પોર્ટ્સ નથી અને પાર્સ કરવા માટે કોઈ ઓથેન્ટિકેશન હેડર્સ નથી. જો તમારું ટૂલ અને તમારો ક્લાયન્ટ એક જ મશીન પર હોય, તો સામાન્ય રીતે અહીંથી શરૂઆત કરવી યોગ્ય છે.

stdio પર ચલાવવાથી તમારા PHP પ્રોસેસ પર બે કડક નિયમો લાદવામાં આવે છે. પ્રથમ, તમારી એપ્લિકેશને ક્યારેય stdout પર નોન-પ્રોટોકોલ ડેટા લખવો જોઈએ નહીં. જો તમે કોઈ ડિબગ સ્ટેટમેન્ટ echo કરો છો અથવા PHP નોટિસ લીક થવા દો છો, તો તમે ક્લાયન્ટના પાર્સરને તોડી નાખશો. તમામ લોગિંગ અને ડાયગ્નોસ્ટિક્સને stderr પર મોકલો. બીજું, આઉટપુટ બફરિંગ સંપૂર્ણપણે બંધ કરો. PHP ને stdout બફર કરવું ગમે છે, ખાસ કરીને CGI અથવા વેબ સંદર્ભમાં, પરંતુ CLI સ્ક્રિપ્ટ્સ પણ ડેટા હોલ્ડ કરી શકે છે. દરેક પ્રતિસાદને તરત જ ફ્લશ (flush) કરો. જો તમે સ્ટ્રીમ્સનો ઉપયોગ કરી રહ્યા હોવ, તો stream_set_write_buffer(STDOUT, 0) સેટ કરો અથવા ઇમ્પ્લીસિટ બફરિંગ બંધ કરો જેથી તમે જે ક્ષણે ન્યૂલાઇન મોકલો તે ક્ષણે ક્લાયન્ટ તેને મેળવી શકે.

Streamable HTTP અલગ રીતે કામ કરે છે. તમારી PHP એપ્લિકેશન એક પર્સિસ્ટન્ટ 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) ક્ષમતાઓ છે. તમારા મેથડ સિગ્નેચરનું નિરીક્ષણ કરો, તમારા ફોર્મ્સ અથવા કમાન્ડ ઓબ્જેક્ટ્સમાંથી હાલના વેલિડેશન નિયમો વાંચો, અને તે નિયમો પરથી સ્કીમા જનરેટ કરો. જો તમારા ઇન્ટરનલ કોડમાં માન્ય ઇમેઇલ ફોર્મેટની જરૂર હોય, તો તમારા MCP સ્કીમામાં પણ એ જ હોવું જોઈએ. જ્યારે વેલિડેશન નિયમો બદલાય છે, ત્યારે સ્કીમા આપમેળે અપડેટ થાય છે. કોઈ તફાવત નહીં, કોઈ છૂપી નિષ્ફળતા નહીં.

પ્રોટોકોલ એરર્સને ટૂલ એરર્સથી અલગ કરો. JSON-RPC પાસે પોતાનું એરર સ્પેસ છે. તેનો ઉપયોગ બ્રોકન પ્રોટોકોલ માટે કરો: જેમ કે ખોટી રીતે લખાયેલ JSON, અજાણ્યા મેથડ્સ, અથવા ખૂટતી રિક્વેસ્ટ ID. જ્યારે કોઈ ટૂલ યોગ્ય રીતે એક્ઝિક્યુટ થાય પરંતુ બિઝનેસ સમસ્યાનો સામનો કરે, ત્યારે પેલોડની અંદર એરર ફ્લેગ સાથે સામાન્ય પરિણામ પરત કરો. જો કસ્ટમર લુકઅપ ટૂલને કોઈ મેચિંગ રેકોર્ડ ન મળે, તો તે પ્રોટોકોલ ક્રેશ નથી. {"found": false} જેવું સ્ટ્રક્ચર્ડ રિઝલ્ટ પરત કરવાથી મોડેલ સમજી શકે છે કે શું થયું અને પછીનું સ્ટેપ પસંદ કરી શકે છે. તે કદાચ વ્યાપક સર્ચ કરવાનો પ્રયાસ કરી શકે છે, અથવા તે વપરાશકર્તાને સ્પષ્ટતા માટે પૂછી શકે છે. જો તમે તેના બદલે JSON-RPC એરર ફેંકશો, તો મોડેલ ઘણીવાર કોન્ટેક્સ્ટ ગુમાવી દે છે.

લાંબા સમય સુધી ચાલતા કામ માટે આયોજન કરો. PHP ટૂંકી રિક્વેસ્ટ માટે બનાવવામાં આવ્યું છે. વેબ રિક્વેસ્ટ ત્રીસ સેકન્ડમાં ટાઈમ આઉટ થઈ શકે છે, અને CLI સ્ક્રિપ્ટ્સ પણ મેમરી અથવા ધીરજ ખતમ કરી શકે છે. જો કોઈ ટૂલને પૂરું થવામાં મિનિટો લાગે—કદાચ તે મોટો રિપોર્ટ તૈયાર કરે છે અથવા સિસ્ટમ્સ વચ્ચે ડેટા સિંક કરે છે—તો મોડેલને રાહ ન જોવડાવો. તરત જ જોબ આઈડેન્ટિફાયર (job identifier) પરત કરો. પછી તે ID દ્વારા સ્ટેટસ ચેક કરવા માટે બીજું ટૂલ આપો. તમે પ્રગતિ (progress) Redis, ડેટાબેઝ ટેબલ અથવા જો વોલ્યુમ ઓછું હોય તો ફ્લેટ ફાઇલમાં પણ સ્ટોર કરી શકો છો. મોડેલ ID મેળવે છે, પછીથી ચેક કરે છે, અને અંતે પૂર્ણ થયેલ પરિણામ મેળવે છે.

જ્યારે મોડેલ પાસે કી (Keys) હોય ત્યારે સુરક્ષા

AI મોડેલને ટૂલનો એક્સેસ આપવો એ માનવ વપરાશકર્તાને આપવા જેવું નથી. મોડેલ શાબ્દિક રીતે ઝડપથી કામ કરે છે, અને તે વર્ણનોનો ખોટો અર્થ કાઢી શકે છે. દરેક એક્સપોઝ્ડ ટૂલને પ્રિવિલેજ એસ્કેલેશન (privilege escalation) જોખમ તરીકે ગણો.

સ્કોપને આક્રમક રીતે મર્યાદિત કરો. ક્યારેય જનરિક run_sql ટૂલ એક્સપોઝ ન કરો. find_customer_by_email અથવા update_order_status જેવા ચોક્કસ અને મર્યાદિત ટૂલ્સ બનાવો. મોડેલ ફક્ત તમે જે નામ આપ્યું હોય તે જ કરી શકવું જોઈએ, તે પણ તમે વ્યાખ્યાયિત કરેલા પેરામીટર્સ સાથે.

રીડ (read) અને રાઈટ (write) પાથને અલગ કરો. રીડ-ઓન્લી ટૂલ્સમાં જોખમ ઓછું હોય છે. કોઈપણ વિનાશક (destructive) ક્રિયાને સ્પષ્ટ કન્ફર્મેશન મિકેનિઝમ પાછળ રાખો, અથવા તેને સંપૂર્ણપણે બીજા સર્વર સુધી મર્યાદિત કરો. જો તમારો ક્લાયન્ટ સપોર્ટ કરતો હોય, તો રાઈટ ટૂલ એક્ઝિક્યુટ થાય તે પહેલાં માનવ મંજૂરીનું સ્ટેપ જરૂરી બનાવો.

ટૂલના વર્ણનો એવા લખો જાણે કે તે વધારાની સૂચનાઓ હોય, કારણ કે તે ખરેખર છે. મોડેલે ક્યારે ટૂલ કોલ કરવું જોઈએ તે બાબતે ચોક્કસ રહો. જો કોઈ ટૂલ કિંમત શોધતું હોય, તો તે સ્પષ્ટ કહો. જો તેનો ઉપયોગ કસ્ટમર ID વેરિફાય કર્યા પછી જ કરવો જોઈએ, તો તે સ્પષ્ટપણે જણાવો. અસ્પષ્ટ વર્ણનો અસ્પષ્ટ વર્તન તરફ દોરી જાય છે.

તમારા આઉટપુટને ફિલ્ટર કરો. આખા Eloquent મોડેલ અથવા Doctrine એન્ટિટીને સીરીયલાઈઝ કરીને પરિણામમાં ન નાખો. મોડેલને ખરેખર જે ફીલ્ડ્સની જરૂર હોય તે જ પરત કરો. ઇન્ટરનલ ફીલ્ડ્સ—જેમ કે પડતર કિંમત (cost prices), કર્મચારીની નોંધો, ડેટાબેઝ ID જે ઇન્ટરનલ રહેવા જોઈએ—તેને બહાર મોકલવાનો કોઈ હેતુ નથી. તમારા રિટર્ન શેપ (return shape) વિશે સ્પષ્ટ રહો.

અંતે, બધું લોગ કરો. ટૂલનું નામ, પાસ કરેલા આર્ગ્યુમેન્ટ્સ અને પરિણામ રેકોર્ડ કરો. જો મોડેલ કોઈ મોંઘી ક્વેરી પર લૂપિંગ કરવાનું શરૂ કરે અથવા અણધારી રીતે ટૂલ્સ તપાસવાનું શરૂ કરે, તો તમારા લોગ્સ જ તમને તે જોવાનો એકમાત્ર રસ્તો હશે.

ક્યાંથી શરૂઆત કરવી

તમારા PHP એપ્લિકેશનને AI આસિસ્ટન્ટ સાથે જોડવા માટે તમારે SDK મેન્ટેનરની પરવાનગીની જરૂર નથી. તમારે ફક્ત JSON-RPC, એક લૂપ અને stdout ની આસપાસ થોડી શિસ્તની જરૂર છે.

પહેલા જ દિવસે તમારી આખી API ને MCP ટૂલ્સ તરીકે ફરીથી બનાવવાની ઈચ્છાને રોકો. તમારી સંસ્થામાં કોઈ વારંવાર પૂછતું હોય તેવા ત્રણ રીડ-ઓન્લી ઓપરેશન્સ પસંદ કરો. કદાચ તે ઓર્ડર સ્ટેટસ ચેક કરવું, કસ્ટમર સમરી મેળવવી અથવા તાજેતરના ઇન્વોઇસની યાદી બનાવવી હોઈ શકે છે. તેને ટૂલ્સ તરીકે રેપ કરો, તેને stdio દ્વારા સર્વ કરો અને એક સહકર્મીને તેનો ઉપયોગ કરવા દો. મોડેલ શું સારું કરે છે અને ક્યાં અટકે છે તે જુઓ. તમે ત્રીસ ટૂલ્સનું આયોજન કરવા કરતાં આ ત્રણ ટૂલ્સમાંથી વધુ શીખશો.

MCP એ એક પુલ છે, તમારી એપ્લિકેશનનો વિકલ્પ નથી. તમારો PHP કોડ પહેલેથી જ તમારા બિઝનેસને જાણે છે. પ્રોટોકોલ ફક્ત મોડેલને તે પાર કરીને પ્રશ્નો પૂછવાની મંજૂરી આપે છે.