WebMCP के लिए इवैल

Kasper Kulikowski

पब्लिश किया गया: 19 मई, 2026

WebMCP, जनरेटिव एआई मॉडल का इस्तेमाल करने वाले एजेंट के साथ काम करता है. जनरेटिव एआई का इस्तेमाल करने वाले किसी भी सिस्टम की जांच करने के लिए, आपके टेस्ट में संभावित नतीजों की सुविधा होनी चाहिए. इसका मतलब है कि एक इनपुट से, सटीक जवाबों के साथ-साथ हज़ारों जवाब मिल सकते हैं. जांच की इस तकनीक को इवैल्युएशन या इवैल कहा जाता है.

टूल को प्रोडक्शन में रिलीज़ करने से पहले, आपको यह पक्का करना होगा कि एजेंट को यह पता हो कि टूल को कब कॉल करना है, इसे कैसे चलाना है, और इसके कौनसे जवाब स्वीकार किए जा सकते हैं. समस्याएं होने से पहले ही उन्हें हल करने के तरीके ढूंढें.

अपने सिस्टम के टचपॉइंट की जांच करने के लिए, लार्ज लैंग्वेज मॉडल (एलएलएम) के साथ इवैल्युएशन लिखें:

• पक्का करें कि मॉडल, आपके टूल के मकसद को समझता हो. यह जानकारी, टूल के ब्यौरे और स्कीमा के आधार पर तय की जाती है.
• पुष्टि करें कि मॉडल, उपयोगकर्ता के मकसद को पूरा करने के लिए सही पैरामीटर के साथ सही टूल चुनता है.
• पक्का करें कि मॉडल, मिली जानकारी के आधार पर काम कर रहा हो. उदाहरण के लिए, किसी दूसरे टूल को कॉल करने के लिए जानकारी का इस्तेमाल करना.
• उपयोगकर्ता के सफ़र की पुष्टि करें. क्या एजेंट, उपयोगकर्ता के मकसद को देखते हुए, उपलब्ध टूल की मदद से मेरी वेबसाइट पर उपयोगकर्ता के सफ़र को पूरा कर सकता है?

आपको ऐसे किसी भी सिस्टम इंटरैक्शन के लिए, क्लासिक डिटरमिनिस्टिक टेस्ट लिखना जारी रखना चाहिए जो मॉडल के साथ कम्यूनिकेट नहीं करता.

फ़ेलियर मोड

डेवलपर को अपने सिस्टम की जांच करनी चाहिए, ताकि समस्याएं होने से पहले ही उन्हें हल किया जा सके. इसके लिए, आपको यह समझना होगा कि सिस्टम कब फ़ेल हो सकता है. ऐसा तब भी हो सकता है, जब वह अपने-आप काम कर रहा हो और तब भी, जब वह एक्सटर्नल फ़ैक्टर के साथ इंटरैक्ट कर रहा हो. WebMCP के लिए, टूल खुद फ़ेल हो सकता है. साथ ही, एजेंट, टूल का इस्तेमाल उम्मीद के मुताबिक नहीं कर सकते.

WebMCP टूल फ़ेल हो सकते हैं. साथ ही, एजेंट, WebMCP टूल के साथ काम नहीं कर सकते. उदाहरण के लिए, मान लें कि आपका उपयोगकर्ता अपने कार्ट में टी-शर्ट जोड़ना चाहता है.

अपलोड नहीं हुआ	उदाहरण	समस्या हल करें
एजेंट, सही टूल नहीं चुन पाता या सीधे गलत टूल को कॉल करता है.	एजेंट, addToCart को छोड़ देता है और सीधे checkout पर चला जाता है.	क्या टूल का description साफ़, पूरा, और सटीक है? साथ ही, क्या यह टूल के काम करने के तरीके को सही तरीके से दिखाता है? क्या functionName समझने में आसान और जानकारी देने वाला है? क्या टूल को मौजूदा स्थिति/कॉन्टेक्स्ट में एलएलएम के लिए सही तरीके से दिखाया गया है? क्या इस टूल का स्कीमा, किसी दूसरे टूल के स्कीमा से काफ़ी मिलता-जुलता है? इसकी वजह से, कॉल करने में कोई समस्या तो नहीं आ रही है?
एजेंट, टूल को गलत क्रम में कॉल करता है	एजेंट, पहले checkout को कॉल करता है और फिर addToCart को.	क्या टूल के ब्यौरे एक-दूसरे से मिलते-जुलते हैं? इसकी वजह से, एलएलएम को ज़रूरी क्रम के बारे में समझने में कोई समस्या तो नहीं आ रही है? क्या पहले टूल का आउटपुट, अगले टूल को कॉल करने के लिए ज़रूरी कॉन्टेक्स्ट उपलब्ध कराता है? क्या स्थिति सही तरीके से अपडेट की गई है? साथ ही, क्या एलएलएम को नए टूल, उम्मीद के मुताबिक दिखाए गए हैं? अगर कुछ टूल को अलग-अलग क्रम में कॉल किया जाता है, तो क्या एंड-टू-एंड यूज़ केस अब भी सही है? क्या आपने एलएलएम के सही अगले चरण को चुनने की पुष्टि करने के लिए, पहले के कॉल को फ़ोर्स करके, टूल कॉल चेन को अलग से टेस्ट किया है?
एजेंट, गलत आर्ग्युमेंट के साथ टूल को कॉल करता है	एजेंट, addToCart को कॉल करता है, लेकिन टी-शर्ट के बजाय जूते जोड़ता है.	क्या inputSchema को साफ़ तौर पर तय किया गया है? इसमें enum वैल्यू और हर प्रॉपर्टी के लिए एक अच्छा description शामिल है? क्या सभी ज़रूरी पैरामीटर को साफ़ तौर पर मार्क और चेक किया गया है? क्या आर्ग्युमेंट का ब्यौरा, एलएलएम को साफ़ तौर पर यह बताता है कि उपयोगकर्ता के इनपुट को उम्मीद के मुताबिक स्ट्रक्चर्ड डेटा (जैसे, कोई खास आईडी या फ़ॉर्मैट) में कैसे मैप करना है?

अगर उपयोगकर्ता यह देखना चाहता है कि उसके कार्ट में क्या-क्या है, तो क्या होगा?

अपलोड नहीं हुआ	उदाहरण	समस्या हल करें
टूल का आउटपुट गलत है या टूल में कोई जानकारी मौजूद नहीं है.	उपयोगकर्ता, viewCart के लिए कहता है, लेकिन एजेंट, प्रॉडक्ट के नामों और अलग-अलग कीमतों के बजाय, कार्ट की कुल कीमत दिखाता है.	क्या टूल की लॉजिक में कोई गड़बड़ी है? इसकी जांच डिटरमिनिस्टिक टेस्ट से करें. क्या यूज़र इंटरफ़ेस (यूआई) की स्थिति सही तरीके से अपडेट की गई है? साथ ही, क्या एजेंट को साइड इफ़ेक्ट के बारे में सही जानकारी मिली है? अगर एलएलएम, अगले कॉल के लिए आउटपुट का इस्तेमाल करता है, तो क्या आउटपुट को एलएलएम के इस्तेमाल के लिए साफ़ तौर पर फ़ॉर्मैट किया गया है? क्या आउटपुट में ज़रूरत से ज़्यादा जानकारी है? क्या इसमें सिर्फ़ वह ज़रूरी जानकारी है जो एलएलएम को अगले ऐक्शन के लिए चाहिए?

आखिर में, कोई टूल किसी भी तरह से फ़ेल हो सकता है. जैसे, JavaScript फ़ेल हो जाती है. समस्या हल करने के लिए, इन चीज़ों की जांच करें:

• क्या टूल का कोड, रनटाइम में होने वाली सभी संभावित गड़बड़ियों और अपवादों को सही तरीके से हैंडल करता है?
• क्या गड़बड़ी की जानकारी, एजेंट और मॉडल को सही तरीके से दी जाती है?
• क्या एक्सटर्नल एपीआई या सेवाएं, जिन पर टूल निर्भर करता है, सही तरीके से काम कर रही हैं?
• क्या गड़बड़ी का स्ट्रक्चर इतना साफ़ है कि मॉडल, अस्थायी समस्या (फिर से कोशिश करें) और गंभीर गड़बड़ी के बीच अंतर कर सके?

टूल को अलग से टेस्ट करना

अगर कोई एजेंट, "मुझे एक छोटा पिज़्ज़ा चाहिए" जैसे अनुरोध के लिए यह नहीं समझ पाता कि किस टूल को कॉल करना है, तो वह उपयोगकर्ता के जटिल सफ़र में काम नहीं कर पाएगा.

टूल को अलग से टेस्ट करके, ब्राउज़र सिम्युलेशन चलाने से पहले ही अपने स्कीमा और ब्यौरे को ऑप्टिमाइज़ किया जा सकता है.

अहम जानकारी: WebMCP टूल कॉल को ट्रिगर किया जा सकता है using navigator.modelContext.executeTool(...).

कॉल की सटीकता का मेज़रमेंट करना

हमारा डेमो, the WebMCP zaMaker देखें. जब उपयोगकर्ता, "मुझे एक छोटा पिज़्ज़ा चाहिए" के लिए प्रॉम्प्ट करता है, तो आपको मॉडल का ऐसा जवाब मिल सकता है जिससे यह पता चलता है कि "size":"Small" आर्ग्युमेंट के साथ set_pizza_size कॉल करने का इरादा है.

expectedCall फ़ंक्शन, उम्मीद के मुताबिक फ़ंक्शन और आर्ग्युमेंट तय करता है. इस तरीके से यह पुष्टि होती है कि एजेंट, दिए गए स्कीमा के आधार पर, उपयोगकर्ता के मकसद को पूरा करने के लिए सही टूल चुनेगा.

{
  "messages": [
    {
      "role": "user",
      "content": "I'd like a small pizza."
    }
  ],
  "expectedCall": [
    {
      "functionName": "set_pizza_size",
      "arguments": { "size": "Small" }
    }
  ]
}

expectedCall का इस्तेमाल, नियम के आधार पर डिटरमिनिस्टिक टेस्ट करने के लिए किया जाता है:

आपके पास अपने WebMCP टूल को किसी कॉम्पोनेंट के लाइफ़साइकल से जोड़ने का विकल्प होता है. इसका मतलब है कि आपको यह टेस्ट करना होगा कि आपके ऐप्लिकेशन की स्थिति, WebMCP की उम्मीद के मुताबिक है या नहीं. इसे मैनेज करने के लिए, टूल की पूरी सूची दें. यह सूची, उस स्थिति के हिसाब से होनी चाहिए जिसका आपको आकलन करना है. उदाहरण के लिए, कोई उपयोगकर्ता अपने एजेंट के साथ को-ब्राउज़ कर रहा है और WebMCP zaMaker खोलता है.

[
...
  {
    "name": "add_topping",
    "description": "Add one or more toppings to the pizza",
    ...
  },
  {
    "name": "set_pizza_size",
    "description": "Set the pizza size directly.",
    "inputSchema": {
      "type": "object",
      "properties": {
        "size": {
          "type": "string",
          "enum": [
            "Small",
            "Medium",
            "Large",
            "Extra Large"
          ],
          "description": "The specific size name."
        },
      }
    }
  },
  {
    "name": "set_pizza_style",
    "description": "Set the style of the pizza (colors/theme)",
  ...
  },
...
]

...
 "expectedCall": [
   {
     "functionName": "set_pizza_size",
     "arguments": { "size": "Small" }
   }
 ]
...

खोलने पर, WebMCP, add_topping, set_pizza_size, और set_pizza_style टूल दिखाता है. इनमें से किसी भी टूल को सटीक तरीके से टेस्ट करने के लिए, आपको सिम्युलेटेड और पूरी स्थिति बनाने के लिए, सभी टूल शामिल करने चाहिए.

ध्यान दें: हो सकता है कि किसी एजेंट के पास अन्य टूल का ऐक्सेस हो, लेकिन आपके पास सिर्फ़ उन टूल का आकलन करने का विकल्प होता है जो आपने उपलब्ध कराए हैं.

अब आपको पता है कि एजेंट, ज़रूरत के हिसाब से सही टूल को कॉल करता है. इसलिए, अब यह टेस्ट किया जा सकता है कि टूल कॉल में सही पैरामीटर हैं या नहीं. साथ ही, नतीजा उम्मीद के मुताबिक है या नहीं. इसके लिए, दो चरण हैं: डिटरमिनिस्टिक टेस्ट और प्रॉबेबिलिस्टिक टेस्ट.

डिटरमिनिस्टिक टेस्ट करना

WebMCP टूल, JavaScript या एचटीएमएल एनोटेशन की मदद से बनाए जाते हैं. इसलिए, डिटरमिनिस्टिक टेस्ट लिखकर, ये टास्क किए जा सकते हैं:

• टूल की लॉजिक की पुष्टि करना.
• पुष्टि करना कि डिपेंडेंसी को सही तरीके से कॉल किया गया है.
• पुष्टि करना कि यूज़र इंटरफ़ेस (यूआई), उम्मीद के मुताबिक अपडेट हुआ है. साथ ही, अन्य साइड इफ़ेक्ट भी अपडेट हुए हैं.
• पुष्टि करना कि दिखाई गई जानकारी, उम्मीद के मुताबिक वैल्यू से मेल खाती है.
• टेस्ट पैरामीटर की पुष्टि करना.

उदाहरण के लिए, अगर आपका टूल, SearchComponent फ़ंक्शन का इस्तेमाल करता है, तो SearchComponent का मॉक पास करके टेस्ट किया जा सकता है. सबसे सही नतीजे पाने के लिए, उस एनवायरमेंट को सिम्युलेट करना न भूलें जिसमें टूल काम कर रहा है. यह वही तरीका है जिसका इस्तेमाल, किसी अन्य ऐप्लिकेशन इंटिग्रेशन टेस्ट को लिखने के लिए किया जाता है.

प्रॉबेबिलिस्टिक टेस्ट करना

अगर आपको अगले टूल को सही तरीके से कॉल करने के लिए, मॉडल के आउटपुट की ज़रूरत है, तो आपको इवैल लिखने होंगे.

उपयोगकर्ता, मॉडल को सीधे तौर पर क्वेरी दे सकते हैं. इनमें खास तौर पर यह पूछा जाता है कि टूल क्या करता है. इसके अलावा, ऐसी क्वेरी भी दी जा सकती हैं जिनसे यह पता चलता है कि किसी टूल का इस्तेमाल किया जाना चाहिए. उदाहरण के लिए, "मेरे पिज़्ज़ा में पेपरोनी जोड़ो" एक डायरेक्ट क्वेरी है. "मुझे अपने पिज़्ज़ा में सभी तरह का मीट चाहिए" एक ऐसी क्वेरी है जो साफ़ तौर पर यह नहीं बताती कि किस टूल का इस्तेमाल करना है. इसके लिए, मॉडल को यह समझना होगा कि उसे add_topping टूल की ज़रूरत है. साथ ही, यह भी समझना होगा कि किन टॉपिंग को मीट के तौर पर तय किया जा सकता है.

अपने इवैल के लिए डेटासेट बनाते समय, डायरेक्ट क्वेरी और ओपन-एंडेड क्वेरी, दोनों शामिल करें. डायरेक्ट क्वेरी से, टूल के बुनियादी तौर पर काम करने की जांच की जाती है. वहीं, ओपन-एंडेड क्वेरी से, मॉडल की रीजनिंग और टूल चुनने की लॉजिक की जांच की जाती है.

अगर आपका कॉफ़ी शॉप है, तो आपके पास उन उपयोगकर्ताओं की मदद करने का विकल्प होता है जो अपने एजेंट से, वही कॉफ़ी फिर से ऑर्डर करने के लिए कहते हैं जो उन्होंने पिछले महीने ऑर्डर की थी. पिछले ऑर्डर खोजने के लिए, OrderHistoryService नाम का एक टूल लिखें. साथ ही, कॉफ़ी ऑर्डर करने के लिए एक और टूल लिखें. ऑर्डर इतिहास सेवा को टेस्ट करने के लिए, एक मॉक भेजा जा सकता है. इससे कॉफ़ी प्रॉडक्ट आईडी मिलता है.

इस उदाहरण में, यह आकलन किया जाता है कि मॉडल, क्वेरी के मकसद को समझता है या नहीं. साथ ही, यह भी आकलन किया जाता है कि मॉडल, सही टूल चुनता है या नहीं. इसके अलावा, यह भी आकलन किया जाता है कि वह टूल, कार्रवाई करने के लिए सही जानकारी उपलब्ध कराता है या नहीं. अगर मॉडल, get_order_history को कॉल नहीं करता है, तो उसे यह नहीं पता होगा कि order_product के लिए किस item_id का इस्तेमाल करना है.

एंड-टू-एंड टेस्टिंग

एंड-टू-एंड टेस्ट लिखें, ताकि आपको यह भरोसा हो कि उपयोगकर्ता और उनके एजेंट, अपने सफ़र को सही तरीके से पूरा कर सकते हैं. अलग-अलग टूल को टेस्ट करने के अलावा, यह भी टेस्ट किया जाता है कि मल्टी-स्टेप ऐक्शन सही क्रम में किए जाते हैं या नहीं.

उदाहरण के लिए, आपका कपड़ों का एक ऑनलाइन स्टोर है. कोई उपयोगकर्ता अपने एजेंट से पूछता है: "मुझे एक ब्लैक जैकेट और एक जोड़ी जींस खरीदनी है. क्या आप इस्तेमाल किए गए मटीरियल की जानकारी दे सकते हैं?"

एजेंट के ज़रिए पूरा किया गया सफ़र इस तरह दिख सकता है:

1. कपड़ों की कैटगरी पर जाएं.
2. कपड़ों के लिए किए गए अनुरोध में से कोई एक आइटम ढूंढें. ऑर्डर का क्रम ज़रूरी नहीं है.
3. खास आइटम (search_clothes) ढूंढें.
4. प्रॉडक्ट की जानकारी पाएं. इसमें मटीरियल की सूची (get_product_details) शामिल होती है.
5. अनुरोध किए गए हर आइटम के लिए, दूसरे से चौथे चरण तक की प्रोसेस दोहराएं.

जब एजेंट दूसरे चरण पर पहुंचता है, तो वह पहले ब्लैक जैकेट या जींस खोज सकता है. ऑर्डर का क्रम ज़रूरी नहीं है. हालांकि, बाकी के चरणों को क्रम से पूरा करना होगा.

एंड-टू-एंड इवैल लिखें, ताकि यह पुष्टि की जा सके कि एजेंट, टूल को उम्मीद के मुताबिक क्रम में कॉल करता है या नहीं:

{
  "messages": [
    {
      "role": "user",
      "content": "I am looking to buy a black jacket and a pair of jeans.
        Could you provide a breakdown of the materials used ?"
    }
  ],
  "expectedCall": [
    {
      "functionName": "navigate_to_category",
      "arguments": { "category": "clothes" }
    },
    {
      "unordered": [
        {
          "ordered": [
            {
              "functionName": "search_clothes",
              "arguments": { "query": "black jacket" }
            },
            {
              "functionName": "get_product_details",
              "arguments": { "productId": "JACKET002" }
            }
          ]
        },
        {
          "ordered": [
            {
              "functionName": "search_clothes",
              "arguments": { "query": "jeans" }
            },
            {
              "functionName": "get_product_details",
              "arguments": { "productId": "JEANS001" }
            }
          ]
        }
      ]
    }
  ]
}

चेन के बीच में होने वाली गड़बड़ियों का आकलन करना

ऐसा हो सकता है कि किसी एजेंट को क्रम से कई टूल कॉल करने पड़ें. अगर इस प्रोसेस के बीच में कोई टूल फ़ेल हो जाता है, तो क्या होगा? उदाहरण के लिए, कोई उपयोगकर्ता अपने कूपन कोड से पिज़्ज़ा ऑर्डर करना चाहता है:

"मुझे एक छोटा पेस्टो पिज़्ज़ा चाहिए. मेरा प्रोमो कोड, FreePizza इस्तेमाल करें."

ऐसा हो सकता है कि एजेंट, add_discount_coupon पर फ़ेल हो जाए और पूरी कीमत वाले पिज़्ज़ा के लिए चेकआउट कर दे. add_discount_coupon टूल को टेस्ट करने के लिए, टूल कॉल के इस क्रम को मैन्युअल तरीके से चलाया जा सकता है. इसके लिए, मॉडल के साथ इंटरैक्ट करने की ज़रूरत नहीं होती. इससे इस स्थिति को सिम्युलेट किया जा सकता है. अपने ऐप्लिकेशन को उस स्थिति में लाएं जहां आपको लगता है कि टूल फ़ेल हो जाएगा. इस मामले में, यह स्थिति start_checkout टूल के बाद की है. इसके बाद, add_discount_coupon का आकलन अलग से किया जा सकता है.

WebMCP के साथ एक्सपेरिमेंट करना

टूल के लिए इवैल के साथ एक्सपेरिमेंट करना शुरू करें. साथ ही, WebMCP की सुविधा वाली अपनी साइटों का आकलन, WebMCP के साथ काम करने वाले किसी भी एजेंट की मदद से करें:

• GitHub पर, हमारे एक्सपेरिमेंटल इवैल्युएशन टूल डाउनलोड करें.
• हमारा कोर्स, एआई इवैल्युएशन बनाना देखें.