पब्लिश की गई: 18 मई, 2026
WebMCP टूल का एलान साफ़ तौर पर किया जाना चाहिए. इसके लिए, डेवलपर या एजेंट को आउटपुट देखने और फिर से कोशिश करने की ज़रूरत नहीं होनी चाहिए. चाहे आपने Imperative API या Declarative API का इस्तेमाल किया हो, इन सबसे सही तरीकों को अपनाएं:
- टूल बनाने से पहले, उसकी रणनीति बनाएं.
- साफ़ भाषा और सिमैंटिक एचटीएमएल का इस्तेमाल करें.
- अपने स्कीमा डिज़ाइन करें और इनपुट को मैनेज करें.
- भरोसेमंद टूल बनाएं.
- जांच और डीबग करें.
टूल की रणनीति बनाना
किसी भी सॉफ़्टवेयर ऐप्लिकेशन की तरह, आपका पहला कदम टूल की रणनीति बनाना होना चाहिए:
- हर टूल में एक ही फ़ंक्शन होना चाहिए. उदाहरण के लिए, एक टूल उपयोगकर्ता को किसी खास तरह के फ़ॉर्म पर ले जा सकता है. वहीं, दूसरा टूल, इनपुट फ़ील्ड को उपयोगकर्ता की जानकारी से मैच कर सकता है. ध्यान रखें कि एक जैसे काम करने वाले टूल न बनाएं, क्योंकि इससे एजेंट को यह समझने में मुश्किल हो सकती है कि कौनसे टूल का इस्तेमाल करना है. खुद से पूछें: क्या एक ही फ़ंक्शन से कई टास्क पूरे किए जा सकते हैं?
- टूल के रजिस्ट्रेशन को मैनेज करें. टूल को तब रजिस्टर करें, जब वे किसी पेज की खास स्थिति में काम के हों. इसके बाद, जब टूल का इस्तेमाल न किया जा सके, तो उसे अनरजिस्टर कर दें.
- इंपरेटिव एपीआई: की मदद से, रजिस्ट्रेशन को डाइनैमिक तरीके से मैनेज किया जा सकता है
registerTool. - डिक्लेरेटिव एपीआई: फ़ॉर्म पर
toolnameऔरtooldescriptionकी मदद से, टूल के एट्रिब्यूट जोड़कर या हटाकर, रजिस्ट्रेशन को डाइनैमिक तरीके से मैनेज किया जा सकता है.
- इंपरेटिव एपीआई: की मदद से, रजिस्ट्रेशन को डाइनैमिक तरीके से मैनेज किया जा सकता है
- जटिलता कम करें: ज़्यादातर ऐप्लिकेशन के लिए, स्टैटिक रजिस्ट्रेशन डिफ़ॉल्ट तरीका होना चाहिए.
- टास्क पूरा करने के लिए एजेंट पर भरोसा करें. सख्त या नकारात्मक निर्देश लिखने के बजाय, यह मान लें कि एजेंट को यह समझ में आता है कि टास्क पूरा करने के लिए क्या करना है. यह ज़रूरी नहीं है कि एजेंट, चरणों के सटीक फ़्लो को मैनेज करे.
ज़्यादा से ज़्यादा कितने टूल इस्तेमाल किए जा सकते हैं, इसकी कोई सीमा नहीं है. हालांकि, हर टूल, कॉन्टेक्स्ट विंडो का कुछ हिस्सा लेता है और टास्क पूरा होने में लगने वाले समय को बढ़ाता है. जितने ज़्यादा टूल उपलब्ध कराए जाएंगे और जितने ज़्यादा टूल एक जैसे काम करेंगे, एजेंट के लिए सही टूल चुनना उतना ही मुश्किल होगा. यह तय करने के लिए अलग-अलग तरीके आज़माएं कि आपके ऐप्लिकेशन के लिए क्या सही है.
इससे आपको एक जैसे काम करने वाले टूल बनाने से बचने में मदद मिलती है. साथ ही, यह मैनेज करने में मदद मिलती है कि ये टूल कब उपलब्ध होंगे.
साफ़ भाषा और सिमैंटिक कोड का इस्तेमाल करना
टूल के नाम रखने और उनके इस्तेमाल के बारे में बताने के लिए, साफ़ और सीधे शब्दों वाली भाषा का इस्तेमाल करें. इससे एजेंट को अपनी ज़रूरत की चीज़ें ढूंढने, उन्हें समझने, और डेवलपर की उम्मीद के मुताबिक उस जानकारी का इस्तेमाल करने में मदद मिलती है.
टूल के नाम लिखते समय, एक्ज़ीक्यूशन और इनिशिएशन के बीच अंतर करें. साथ ही, ऐसे वर्ब का इस्तेमाल करें जिनसे यह पता चले कि असल में क्या होता है. उदाहरण के लिए, create-event एक ऐसा टूल है जिससे तुरंत इवेंट बनाया जा सकता है. वहीं, start-event-creation-process एक ऐसा टूल है जो उपयोगकर्ता को इवेंट बनाने के लिए, फ़ॉर्म पर रीडायरेक्ट करता है.
साफ़ तौर पर दी गई जानकारी में यह बताया जाना चाहिए कि टूल क्या करता है और इसका इस्तेमाल कब करना है. नकारात्मक भाषा के बजाय, सकारात्मक भाषा और प्राथमिकताओं का इस्तेमाल करें. जैसे, सीमाओं के बारे में बताने के लिए नकारात्मक भाषा का इस्तेमाल न करें.
"मौसम की जानकारी के लिए इस टूल का इस्तेमाल न करें."
सीमाओं के बारे में, सही तरीके से लिखी गई जानकारी में बताया जाना चाहिए."यह टूल, किसी खास तारीख और समय के लिए शेड्यूल किया गया कैलेंडर इवेंट बना सकता है."
कॉग्निटिव कंप्यूटिंग को कम करना
जिस तरह आपको मुश्किल टास्क पूरे करने वाले लोगों के लिए कॉग्निटिव लोड को कम करना चाहिए, उसी तरह आपको मॉडल के लिए कॉग्निटिव कंप्यूटिंग को भी कम करना चाहिए:
- उपयोगकर्ता से मिले रॉ इनपुट को स्वीकार करें. एजेंट से गणित के सवाल हल करने या इनपुट स्ट्रिंग को बदलने के लिए न कहें. उदाहरण के लिए, अगर कोई उपयोगकर्ता "11:00 से 15:00" कहता है, तो टूल को इसे स्ट्रिंग के तौर पर स्वीकार करना चाहिए. मॉडल से इन समय के बीच के मिनटों की गिनती करने के लिए न कहें.
- पैरामीटर के लिए खास टाइप तय करें. जैसे, स्ट्रिंग, नंबर या enum.
- यह बताएं कि आपने कुछ विकल्प क्यों चुने हैं. आपने जो विकल्प चुना है वह अपने-आप समझ में आना चाहिए. यह बताने से एजेंट को बेहतर विकल्प चुनने में मदद मिलती है. उदाहरण के लिए, अगर आपकी कोई ई-कॉमर्स शॉप है, तो शिपिंग टाइप के बारे में बताने के लिए, अस्पष्ट आईडी का इस्तेमाल करने के बजाय, सामान्य भाषा का इस्तेमाल करें:
shipping="Express"का इस्तेमाल करें, न किshipping_id=1का.
भरोसेमंद होने को अहमियत देना
एजेंट और लोगों को ऐसे टूल से फ़ायदा मिलता है जो उम्मीद के मुताबिक काम करते हैं:
- रेट लिमिट के लिए, ग्रेसफ़ुल फ़ेलियर सेट करें. टूल में, कीमत की तुलना जैसे कामों के लिए, बार-बार इस्तेमाल करने की अनुमति होनी चाहिए. अगर किसी टूल पर रेट लिमिट लागू है, तो काम की गड़बड़ी की जानकारी दें या उपयोगकर्ता को सलाह दें कि वह टास्क को मैन्युअल तरीके से पूरा करे.
- फ़ंक्शन पूरे होने के बाद, इंटरफ़ेस का स्टेटस अपडेट करें. एजेंट, अगले चरण की योजना बनाने के लिए इंटरफ़ेस पर निर्भर हो सकते हैं. वहीं, फ़ंक्शन को पूरा होने में, इंटरफ़ेस लोड होने में लगने वाले समय से ज़्यादा समय लग सकता है. इंटरफ़ेस के अपडेट होने के बाद, एजेंट को पुष्टि करनी चाहिए कि फ़ंक्शन पूरा हो गया है या फिर से अपडेट का अनुरोध करना चाहिए.
- कोड में सख्ती से और स्कीमा में ढीले-ढाले तरीके से पुष्टि करें. बाइनरी लॉजिक वाले फ़ंक्शन और कोड के लिए, कंस्ट्रेंट और टेस्टिंग का इस्तेमाल किया जाना चाहिए. स्कीमा कंस्ट्रेंट काम के हो सकते हैं. हालांकि, इनकी कोई गारंटी नहीं होती. अपने फ़ंक्शन कोड में, गड़बड़ियों के बारे में जानकारी जोड़ें, ताकि मॉडल खुद से गड़बड़ी ठीक कर सके और नए, मान्य पैरामीटर के साथ फिर से कोशिश कर सके.
Eval टेस्टिंग और डीबग करना
इवैल्युएशन टेस्ट बनाएं और अपने टूल को डीबग करने के लिए उपलब्ध कराएं. डिटरमिनिस्टिक यूनिट टेस्ट के उलट, इवैल्युएशन को हार्ड-कोड नहीं किया जा सकता, क्योंकि आउटपुट अनचाहे फ़ॉर्म में हो सकते हैं.
- समस्या तय करें. अपनी समस्या को एपीआई कॉन्ट्रैक्ट की तरह फ़्रेम किया जा सकता है. इसमें, इनपुट टाइप, आउटपुट फ़ॉर्मैट, और अन्य कंस्ट्रेंट शामिल किए जा सकते हैं.
- बेसलाइन और बेहतर नतीजा तय करें. खास तौर पर, टेक्स्ट इनपुट के मामले में, यह समझना ज़रूरी है कि किस तरह के नतीजों से आपको अपनी उम्मीद के मुताबिक आउटपुट मिल सकता है.
- तय करें कि आउटपुट का आकलन कैसे किया जाएगा. संभव है कि आप इनपुट की क्वालिटी, काम के होने, और अगले टास्क को पूरा करने की क्षमता के आधार पर, व्यक्तिपरक और गुणात्मक नतीजों की पहचान और माप कर रहे हों. आउटपुट का आकलन करने के लिए, कई तकनीकों का इस्तेमाल किया जा सकता है. इनमें, नियम-आधारित आउटपुट (कैरेक्टर लिमिट) के लिए कोड-आधारित जांच और LLM-as-a-judge शामिल हैं.
किसी खास मॉडल से जुड़ी समस्याओं को ठीक करने के लिए, संकुचित नियम न जोड़ें. उदाहरण के लिए, अगर आपने ऑनरिफ़िक के लिए कोई सेलेक्ट फ़ील्ड शामिल किया है, तो मॉडल गलत विकल्प चुन सकता है. इस समस्या को ठीक करने के लिए, संकुचित नियम जोड़ने के बजाय, अपने टूल को ऐब्स्ट्रैक्ट करें और उसमें बदलाव करें. इस फ़ील्ड को ज़रूरी नहीं के तौर पर सेट करना सबसे अच्छा हो सकता है. इसके बाद, एजेंट से उपयोगकर्ता से यह पूछने के लिए कहें कि कौनसे विकल्प का इस्तेमाल करना सही है, ताकि यह पक्का किया जा सके कि उपयोगकर्ता नतीजे से खुश है.
सुझाव, शिकायत या राय शेयर करना और बातचीत में शामिल होना
WebMCP पर फ़िलहाल चर्चा चल रही है. आने वाले समय में, इसमें बदलाव हो सकता है. अगर आपने इन एपीआई को आज़माया है और आपके पास कोई सुझाव, शिकायत या राय है, तो हमें इसके बारे में बताएं.
- WebMCP के बारे में जानकारी देने वाला लेख पढ़ें, सवाल पूछें, और चर्चा में शामिल हों.
- Chrome Status पर, Chrome के लिए लागू करने की प्रोसेस की समीक्षा करें.
- नए एपीआई को सबसे पहले देखने और हमारी मेलिंग सूची का ऐक्सेस पाने के लिए, अर्ली प्रीव्यू प्रोग्राम में शामिल हों
- अगर आपके पास Chrome के लागू करने की प्रोसेस के बारे में कोई सुझाव, शिकायत या राय है, तो Chromium में गड़बड़ी की शिकायत करें.