તમારા MCP સર્વરને 40 ટૂલ્સની જરૂર નથી
MCP ડેમોમાં ઘણીવાર બધું એકસાથે બતાવવામાં આવે છે. તેઓ દરેક એન્ડપોઈન્ટ (endpoint) અને દરેક ડેટાબેઝ ટેબલ બતાવે છે. તેઓ દાવો કરે છે કે એજન્ટ કંઈ પણ કોલ કરી શકે છે.
આ દસ મિનિટ માટે શક્તિશાળી લાગે છે. પછી મોડેલ નિષ્ફળ જાય છે. તે ખોટું ટૂલ કોલ કરે છે. તે ખોટા ફોર્મેટમાં આર્ગ્યુમેન્ટ્સ (arguments) પાસ કરે છે. તે સર્ચ એન્ડપોઈન્ટમાંથી ચાર્ટ માંગે છે. તે કોઈ વિનાશક ક્રિયા (destructive action) ફરીથી કરવાનો પ્રયાસ કરે છે.
સમસ્યા MCP ની નથી. સમસ્યા MCP ને તમારા બેકએન્ડ (backend) માટે એક મેજિક એડેપ્ટર તરીકે ગણવાની છે.
MCP સર્વર એ માત્ર એજન્ટ્સ માટે ઉપલબ્ધ કરાયેલ તમારી API નથી. તે ખૂબ જ શાબ્દિક (literal) અને ખૂબ જ વિચલિત થઈ શકે તેવા વપરાશકર્તા માટેનું પ્રોડક્ટ સરફેસ છે. તે વપરાશકર્તા એક લેંગ્વેજ મોડેલ છે.
જો તમે મોડેલને 40 સમાન ટૂલ્સ આપો છો, તો તમે તેને શક્તિ નથી આપતા. તમે તેને લગભગ સાચા હોવાના 40 રસ્તાઓ આપો છો.
તમારા API રૂટ્સનું મિરરિંગ (mirroring) કરવાનું બંધ કરો. માણસો ડોક્યુમેન્ટ્સ વાંચી શકે છે અને સંદર્ભ (context) સમજી શકે છે. મોડેલ્સ નામ અને વર્ણનોમાં પેટર્ન-મેચિંગ કરે છે.
તમારા MCP લેયરને વપરાશકર્તાના ઈન્ટેન્ટ (intent) ની આસપાસ બનાવો.
દરેક રૂટનું મિરરિંગ કરવાને બદલે, તેમને સ્પષ્ટ સીમાઓમાં જૂથબદ્ધ કરો:
- માર્કેટ સમરી માટે એક ટૂલ
- રિલીઝ કેલેન્ડર માટે એક ટૂલ
- ચોક્કસ ડેટા સ્નેપશોટ માટે એક ટૂલ
- હિસ્ટોરિકલ ઈન્ડિકેટર્સ માટે એક ટૂલ
એક API રૂટ કહે છે: જો તમે આ રિક્વેસ્ટ મોકલશો, તો સર્વર પ્રતિસાદ આપશે. એક MCP ટૂલ કહેવું જોઈએ: આ ચોક્કસ કામ માટે, આ ચોક્કસ ઇનપુટ્સ સાથે મારો ઉપયોગ કરો, અને આ ચોક્કસ પરિણામની અપેક્ષા રાખો.
સારા ટૂલ વર્ણનો રૂટિંગ લોજિક છે, માર્કેટિંગ કોપી નથી.
ખરાબ: name: get_data description: Gets data from the API.
વધુ સારું: name: lookup_release_calendar description: Return scheduled economic events for one currency and date range. Use this before answering questions about upcoming macro events.
વધુ સારા એજન્ટ્સ માટે આ નિયમો અનુસરો:
સાદા (boring) નામોનો ઉપયોગ કરો. ડેવલપર્સ fetch અથવા query જેવા ટૂંકા નામો પસંદ કરે છે. મોડેલ્સને search_docs અથવા check_deployment_status જેવા ચોક્કસ નામોની જરૂર હોય છે. અસ્પષ્ટ નામો મોંઘા પડે છે.
રિસ્પોન્સના આકાર (shape) પર નિયંત્રણ રાખો. વિશાળ નેસ્ટેડ (nested) ઓબ્જેક્ટ્સ પરત કરશો નહીં. કામમાં મદદરૂપ થાય તેવો સૌથી નાનો આકાર પરત કરો. જો મોડેલ ખૂબ વધારે ડેટા જોશે, તો તે ખોટા ફિલ્ડનો ઉપયોગ કરશે અથવા વિગતોની ભ્રમણા (hallucinate) કરશે.
નિષ્ફળતા માટે ડિઝાઇન કરો. પ્રોડક્શન ક્વોલિટી તમે ભૂલો (errors) ને કેવી રીતે હેન્ડલ કરો છો તેના પરથી આવે છે. ફક્ત 500 એરર અથવા ખાલી એરે (array) પરત કરશો નહીં. મોડેલને જણાવો કે તે શા માટે નિષ્ફળ ગયું. જો કોઈ રેકોર્ડ મેચ ન થાય, તો મોડેલને વપરાશકર્તાને વ્યાપક તારીખ રેન્જ સૂચવવાનું કહો.
શ્રેષ્ઠ એજન્ટ ટૂલ સૌથી શક્તિશાળી નથી હોતું. તે એ છે જેને મોડેલ ભૂલથી પણ ખોટું ન સમજી શકે.
સ્ત્રોત: https://dev.to/roberttidball/your-mcp-server-doesnt-need-40-tools-2ig1
વૈકલ્પિક લર્નિંગ કોમ્યુનિટી: https://t.me/GyaanSetuAi
