50 MCP टूल बनाते हुए जो समझ आया: function calling असामान्य रूप से घनिष्ठ संबंध था

सप्ताहांत के दो दिनों में asset management टूल को SQLite-आधारित CLI और MCP server पर शिफ्ट करने के अनुभव के
आधार पर, यह लेख बताता है कि MCP टूल डिज़ाइन RPC से निर्णायक रूप से कहाँ अलग हो जाता है।
लेखक ने करीब 30 CLI commands और 50 के आसपास MCP टूल बनाए, लेकिन इतने काम के बावजूद सबसे लंबे समय तक जिस चीज़ पर अटका रहा, वह कोड नहीं बल्कि functions के descriptions थे — लेख इसी खोज से शुरू होता है।

• जब एक ही function को CLI और MCP दोनों में एक साथ expose किया गया, तो signature/arguments/return values सब एक जैसे होने के बावजूद दोनों interfaces अलग तरह से काम कर रहे थे। बदला सिर्फ इतना था कि caller इंसान है या LLM
• Signature यह बताता है कि function क्या लेता है, लेकिन यह लगभग नहीं बता पाता कि उसे कब बुलाया जाना चाहिए। Function का नाम शब्दकोश की एक पंक्ति जैसा होता है, इसलिए सिर्फ शब्द अपने-आप यह तय नहीं करता कि वह किस वाक्य के ऊपर बैठेगा
• LLM caller के लिए single responsibility principle (SRP) के अनुसार बारीक हिस्सों में टूटे टूल्स की तुलना में ऐसे भारी टूल्स ज़्यादा स्वाभाविक लगे जो सीधे intent तक पहुँचते हैं
• MCP बाहर से देखने पर RPC परिवार (JSON-RPC, signature, schema) का ही हिस्सा लगता है, लेकिन निर्णायक अंतर यह है कि trust की दिशा उलट जाती है। RPC में caller callee पर भरोसा करता है, जबकि MCP में टूल बनाने वाले को caller (LLM) पर भरोसा करना पड़ता है
• Signature एक declaration है और description एक request। एक तरफ enforcement है, दूसरी तरफ persuasion। यानी टूल डिज़ाइन में persuasion की भाषा आनी शुरू हो गई है
• यह कोई बिल्कुल नया बदलाव कम और एक तरह की regression ज़्यादा है। industrial design, architecture और UX बहुत पहले से इसी जगह पर थे; programming ही अब तक असाधारण रूप से घनिष्ठ छोर पर ठहरी हुई थी

Signature क्या नहीं बताता

• Firma के add_txn (transaction), add_balance (asset snapshot), add_flow (income/expense) — इन सबके signatures साफ़ थे और argument types भी zod schema से सख्ती से define किए गए थे, फिर भी LLM अक्सर user utterance से यह तय करने में उलझ जाता था कि कौन-सा टूल बुलाना है
• शुरुआत में शक model पर गया, लेकिन असली समस्या signature में ही थी। add_txn नाम में यह बात शामिल नहीं है कि "अगर user ने buy/sell की बात की है तो यह टूल इस्तेमाल करो"
• Description को "Use this when... Do NOT use this for..." के रूप में लिखकर, call करने के सही समय और दूसरे टूल्स से उसकी सीमा साफ़ की गई, तब जाकर calling स्थिर हुई
• Function का intent signature से खिसककर function description की तरफ चला गया। जैसे हथौड़े का handle अपने आकार से उसके इस्तेमाल का संकेत देता है, वैसे ही MCP function का description LLM के लिए व्यवहारिक रूप से उसी टूल का affordance (Donald Norman) बन जाता है

SRP vs affordance, और trust की दिशा

• शुरुआत में single responsibility principle के अनुसार get_holdings, get_prices, get_pnl जैसे छोटे-छोटे हिस्से बनाने की कोशिश थी, लेकिन जब user पूछता है "मेरा portfolio कैसा है?", तब LLM को चार-पाँच calls जोड़कर काम करना पड़ता है, response धीमा होता है और गड़बड़ी की गुंजाइश बढ़ती है
• अंत में show_portfolio को एक भारी टूल की तरह डिज़ाइन किया गया, जो holdings/average buy price/current price/valuation/cumulative profit and loss एक साथ लौटाता है। get_brief इससे भी आगे जाकर macro indicators और insights भी एक बार में लौटाता है
• SRP function बनाने वाले का गुण है, जबकि affordance टूल इस्तेमाल करने वाले का गुण है। Caller अगर इंसान हो तो assembling चल जाती है; LLM हो तो intent तक सीधे पहुँचने वाला टूल बेहतर है
• Write tools में trust की दिशा सबसे साफ़ दिखती है। add_txn में "Always confirm with the user before recording" लिखने पर LLM हर बार पूछने लगा, और user हर बार "ठीक है" जैसा जवाब देने लगा — natural language interface का फायदा ही खत्म हो गया
• आखिरकार जिम्मेदारी फिर से इस तरह बाँटी गई: "तुरंत रिकॉर्ड करो, सिर्फ ambiguity होने पर पूछो, गलती हो तो उसे वापस लिया जा सकता है"। ऐसे निर्देश टूल का formal description नहीं, बल्कि caller को दिए गए operating principles हैं

हो सकता है function calling खुद ही असल में एक special case रहा हो

• इंसान हमेशा से ऐसे टूल इस्तेमाल करता आया है जिन्हें उसने खुद नहीं बनाया। कुम्हार का बनाया बर्तन, लोहार की बनाई तलवार, डेवलपर का बनाया program — सब इसी श्रेणी में आते हैं
• Function calling दरअसल caller और author के बीच बहुत-सा context साझा होने, और type system/IDE/documentation के लगातार उस घनिष्ठता को मज़बूत करते रहने वाला काफी special relationship था
• अगर caller इंसान नहीं है, तो दो विकल्प हैं: (1) LLM में और ज़्यादा context भरकर उसे एक घनिष्ठ caller बनाया जाए, (2) टूल की तरफ से उस दूरी को पाटा जाए। MCP दूसरे रास्ते के ज़्यादा करीब है
• संभव है कि interface डिज़ाइन करने का तरीका खुद चुपचाप बदल रहा हो। केंद्र signature से description की ओर, enforcement से persuasion की ओर, और घनिष्ठता की धारणा से दूरी को स्वीकार करने की ओर खिसक रहा है