𝗬𝗼𝘂𝗿 𝗠𝗖𝗣 𝗦𝗲𝗿𝘃𝗲𝗿 𝗗𝗼𝗲𝘀𝗻'𝘁 𝗡𝗲𝗲𝗱 𝟰𝟬 𝗧𝗼𝗼𝗹𝘀
MCP డెమోలు తరచుగా అన్నింటినీ ఒకేసారి చూపిస్తాయి. అవి ప్రతి ఎండ్పాయింట్ (endpoint) మరియు ప్రతి డేటాబేస్ టేబుల్ను చూపిస్తాయి. ఏజెంట్ దేన్నైనా పిలవగలదని (call చేయగలదని) అవి వాదిస్తాయి.
ఇది పది నిమిషాల పాటు శక్తివంతంగా అనిపిస్తుంది. ఆ తర్వాత మోడల్ విఫలమవుతుంది. అది తప్పు టూల్ను పిలుస్తుంది. తప్పు ఫార్మాట్లో ఆర్గ్యుమెంట్లను పంపిస్తుంది. సెర్చ్ ఎండ్పాయింట్ నుండి చార్ట్ను అడుగుతుంది. ఏదైనా డేటాను నాశనం చేసే చర్యను (destructive action) మళ్ళీ మళ్ళీ ప్రయత్నిస్తుంది.
సమస్య MCP లో లేదు. సమస్య ఏమిటంటే, MCPని మీ బ్యాకెండ్ కోసం ఒక మ్యాజిక్ అడాప్టర్లా చూడటం.
ఒక MCP సర్వర్ అంటే కేవలం ఏజెంట్లకు అందుబాటులో ఉండే మీ API మాత్రమే కాదు. ఇది చాలా అక్షరాలా (literal) మరియు త్వరగా తప్పుదారి పట్టే (distractible) వినియోగదారుడి కోసం రూపొందించబడిన ఒక ప్రొడక్ట్ సర్ఫేస్. ఆ వినియోగదారుడే ఒక లాంగ్వేజ్ మోడల్.
మీరు ఒక మోడల్కు 40 ఒకే రకమైన టూల్స్ ఇస్తే, మీరు దానికి శక్తిని ఇవ్వడం లేదు. మీరు దానికి దాదాపు సరిగ్గా ఉండే 40 మార్గాలను ఇస్తున్నారు.
మీ API రూట్లను యథాతథంగా (mirroring) కాపీ చేయడం ఆపండి. మనుషులు డాక్యుమెంట్లను చదివి సందర్భాన్ని (context) అర్థం చేసుకోగలరు. మోడల్స్ పేర్లు మరియు వివరణలను చూసి ప్యాటర్న్-మ్యాచ్ (pattern-match) చేస్తాయి.
మీ MCP లేయర్ను వినియోగదారుడి ఉద్దేశ్యం (user intent) ఆధారంగా నిర్మించండి.
ప్రతి రూట్ను యథాతథంగా కాపీ చేసే బదులు, వాటిని స్పష్టమైన విభజనలుగా (boundaries) సమూహపరచండి:
- మార్కెట్ సమ్మరీల కోసం ఒక టూల్
- రిలీజ్ క్యాలెండర్ల కోసం ఒక టూల్
- నిర్దిష్ట డేటా స్నాప్షాట్ల కోసం ఒక టూల్
- చారిత్రక సూచికల (historical indicators) కోసం ఒక టూల్
ఒక API రూట్ ఇలా చెబుతుంది: మీరు ఈ రిక్వెస్ట్ను పంపితే, సర్వర్ స్పందిస్తుంది. ఒక MCP టూల్ ఇలా చెప్పాలి: ఈ ఖచ్చితమైన పని కోసం, ఈ ఖచ్చితమైన ఇన్పుట్లతో నన్ను ఉపయోగించండి మరియు ఈ నిర్దిష్ట ఫలితాన్ని ఆశించండి.
మంచి టూల్ వివరణలు రూటింగ్ లాజిక్ (routing logic) లాగా ఉండాలి, మార్కెటింగ్ కాపీలా కాదు.
చెడ్డది: 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.
మెరుగైన ఏజెంట్ల కోసం ఈ నియమాలను పాటించండి:
సాధారణ పేర్లను ఉపయోగించండి. డెవలపర్లు fetch లేదా query వంటి చిన్న పేర్లను ఇష్టపడతారు. మోడల్స్కు search_docs లేదా check_deployment_status వంటి నిర్దిష్టమైన పేర్లు అవసరం. అస్పష్టమైన పేర్లు ఖరీదైనవి (అంటే తప్పులు జరిగే అవకాశం ఎక్కువ).
రెస్పాన్స్ షేప్ను (response shape) నియంత్రించండి. భారీ నెస్టెడ్ ఆబ్జెక్ట్లను (nested objects) తిరిగి పంపకండి. పనికి అవసరమైన అతి తక్కువ డేటాను మాత్రమే పంపండి. మోడల్ మరీ ఎక్కువ డేటాను చూస్తే, అది తప్పు ఫీల్డ్ను ఉపయోగిస్తుంది లేదా వివరాలను ఊహించి చెబుతుంది (hallucinate చేస్తుంది).
వైఫల్యానికి సిద్ధంగా ఉండండి (Design for failure). ప్రొడక్షన్ క్వాలిటీ అనేది మీరు ఎర్రర్లను ఎలా హ్యాండిల్ చేస్తారనే దానిపై ఆధారపడి ఉంటుంది. కేవలం 500 ఎర్రర్ లేదా ఖాళీ అర్రేను (empty array) మాత్రమే పంపకండి. అది ఎందుకు విఫలమైందో మోడల్కు చెప్పండి. ఏ రికార్డులు సరిపోలకపోతే, వినియోగదారునికి మరింత విస్తృతమైన తేదీ పరిధిని (wider date range) సూచించమని మోడల్కు చెప్పండి.
ఉత్తమమైన ఏజెంట్ టూల్ అంటే అత్యంత శక్తివంతమైనది కాదు. మోడల్ తప్పుగా అర్థం చేసుకోలేనిదే ఉత్తమమైన టూల్.
Source: https://dev.to/roberttidball/your-mcp-server-doesnt-need-40-tools-2ig1
Optional learning community: https://t.me/GyaanSetuAi