फ़्रंटएंड इंटरव्यू: आप ब्राउज़र एजेंट्स के सामने WebMCP टूल्स को सुरक्षित रूप से कैसे एक्सपोज़ करेंगे?

सवाल

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

संदर्भ और सीमाएं

WebMCP एक प्रस्तावित वेब मानक है। Chrome दस्तावेज़ डिक्लेरेटिव HTML-फ़ॉर्म टूल्स और इमपेरेटिव JavaScript टूल्स का वर्णन करता है, और Chrome 149 एक ओरिजिन ट्रायल प्रदान करता है। यह प्रश्न एक लूप में मानव (human in the loop) के साथ ब्राउज़र टैब में प्रोग्रेसिव एन्हांसमेंट के बारे में है। WebMCP को एक स्थिर बैकएंड प्रोटोकॉल के रूप में प्रस्तुत नहीं किया गया है जो बिना ब्राउज़र संदर्भ के चलता है, और न ही सर्वर-साइड ऑथराइजेशन के प्रतिस्थापन के रूप में।

पहले स्पष्ट करें: कौन से कार्य केवल खोजते और भरते हैं, और कौन से ऑर्डर देते हैं या पैसे चार्ज करते हैं? क्या टूल्स केवल टॉप-लेवल पेज को दिखाई देने चाहिए या क्रॉस-ओरिजिन iframe को भी? क्या अंतिम सबमिशन से पहले यूज़र को फिर से पुष्टि करनी होगी? क्या होता है जब एजेंट WebMCP का समर्थन नहीं करता है या ओरिजिन ट्रायल समाप्त हो जाता है?

इंटरव्यूअर क्या जांच रहा है

इंटरव्यूअर यह जांच रहा है कि क्या आप एजेंट एक्चुएशन को एक फ़्रंटएंड अनुबंध में बदल सकते हैं: स्पष्ट टूल विवरण और इनपुट स्कीमा, मौजूदा लॉगिन, CSRF, व्यावसायिक ऑथराइजेशन और यूज़र कन्फर्मेशन अभी भी पथ में हैं, कम से कम विशेषाधिकार वाला क्रॉस-ओरिजिन एक्सपोज़र, और टूल चयन, पैरामीटर्स और परिणामों के लिए इवैल्यूएशन।

30-सेकंड का उत्तर

यात्रा को केवल-पठन (read-only), प्रतिवर्ती (reversible) और गैर-प्रतिवर्ती (irreversible) कार्यों में विभाजित करें। खोज और भरने के लिए डिक्लेरेटिव या इमपेरेटिव टूल्स का उपयोग करें, जबकि ऑर्डर सबमिशन सर्वर ऑथराइजेशन और स्पष्ट पुष्टि रखता है। केवल आवश्यक फ़ील्ड्स को एक्सपोज़ करें, वर्तमान पेज और ओरिजिन को डिफ़ॉल्ट बनाएं, और क्रॉस-ओरिजिन iframes के लिए स्पष्ट Permissions Policy की आवश्यकता रखें। रिलीज़ से पहले, टूल चयन, पैरामीटर सत्यापन, त्रुटि प्रबंधन और अस्वीकृति पथों का मूल्यांकन करें, जबकि सामान्य UI को फ़ॉलबैक के रूप में बनाए रखें।

चरण-दर-चरण गहन विश्लेषण

1. जोखिम स्तर: search, filter, और fill कम जोखिम वाले या प्रतिवर्ती हैं; place-order, pay, और पते के परिवर्तन हाई-इम्पैक्ट हैं और केवल इसलिए स्वचालित रूप से नहीं चलने चाहिए क्योंकि एजेंट के पास एक टूल है।
2. अनुबंध: प्रत्येक टूल को एक स्थिर नाम, एजेंट-फेसिंग विवरण, JSON इनपुट स्कीमा और संरचित परिणाम मिलता है। इन्यूमरेशन, रेंज, मुद्रा और इन्वेंट्री संस्करणों को क्लाइंट और सर्वर दोनों पर मान्य किया जाता है।
3. व्यावसायिक तर्क का पुन: उपयोग करें: कॉलबैक एक अनुरोध पथ की प्रतिलिपि बनाने के बजाय मौजूदा फ़ॉर्म स्थिति और डोमेन फ़ंक्शन को कॉल करता है जो UI को बायपास करता है। निष्पादन से पहले, लॉगिन, CSRF, कार्ट संस्करण, मूल्य और इन्वेंट्री की जांच करें।
4. परमिशन सीमा: डिफ़ॉल्ट रूप से केवल टॉप-लेवल विंडो और समान-ओरिजिन संदर्भों के लिए एक्सपोज़ करें। क्रॉस-ओरिजिन iframe के साथ केवल तभी साझा करें जब Permissions-Policy और iframe allow विशेषता स्पष्ट रूप से इसकी अनुमति देती है, और अनावश्यक व्यक्तिगत डेटा वापस न करें।
5. यूज़र नियंत्रण: खोज और भरने को एक दृश्यमान परिवर्तन दिखाने दें। ऑर्डर, भुगतान या हटाने के लिए इन-पेज पुष्टि और सारांश की आवश्यकता होती है; टूल का परिणाम बताता है कि कार्रवाई पूरी हुई, पुष्टि की प्रतीक्षा कर रही है, या अस्वीकार कर दी गई थी।
6. प्रोग्रेसिव रोलआउट: पहले एक स्थानीय फ़्लैग या ओरिजिन ट्रायल के पीछे आंतरिक खातों को सक्षम करें। जब WebMCP अनुपलब्ध हो, तो क्षमता का पता लगाने (capability detection), सामान्य UI और DOM-ऑटोमेशन फ़ॉलबैक प्रदान करें; टूल संस्करण, परिणाम और अस्वीकृति कारण को लॉग करें।
7. मूल्यांकन और निगरानी: टूल-चॉइस सटीकता, मान्य-पैरामीटर दर, पूर्णता, गलत आह्वान (false invocation), अस्वीकृति शुद्धता और पुष्टि कवरेज के लिए एक कार्य सेट बनाएं। हाई-इम्पैक्ट टूल्स के लिए शून्य-गलत-आह्वान गेट सेट करें और विसंगतियों पर पंजीकरण रद्द करें।

आदर्श उत्तर

मैं चेकआउट को खोज, भरने और सबमिट करने में विभाजित करूँगा। खोज और भरना प्रतिवर्ती हैं, इसलिए WebMCP एजेंट लक्ष्यीकरण में सुधार कर सकता है। ऑर्डर और भुगतान मौजूदा सर्वर ऑथराइजेशन, मूल्य और इन्वेंट्री जांच, और पेज पुष्टि के अधीन रहते हैं। WebMCP प्रयोगात्मक है; Chrome 149 ओरिजिन ट्रायल नियंत्रित सत्यापन के लिए उपयुक्त है, बैकएंड परमिशन के प्रतिस्थापन के लिए नहीं।

टूल्स केवल वर्तमान यात्रा के लिए आवश्यक फ़ील्ड्स को एक्सपोज़ करते हैं और अपने कॉलबैक में मौजूदा फ़ॉर्म और डोमेन तर्क का पुन: उपयोग करते हैं। इनपुट स्कीमा आइटम आईडी, मात्रा और पते के प्रारूपों को बाधित करता है; सर्वर लॉगिन, CSRF, इन्वेंट्री, मूल्य और ऑर्डर आइडेम्पोटेंसी की दोबारा जांच करता है। डिफ़ॉल्ट रूप से मैं टूल्स को टॉप-लेवल पेज और समान-ओरिजिन एजेंट के सामने एक्सपोज़ करता हूँ। यदि क्रॉस-ओरिजिन iframe की आवश्यकता है, तो मैं परमिशन नीति और iframe allow दोनों को कॉन्फ़िगर करता हूँ, और कभी भी संपूर्ण खाता प्रोफ़ाइल वापस नहीं करता हूँ।

const controller = new AbortController();

document.modelContext?.registerTool({
  name: "cart_set_quantity",
  description: "Set the quantity of one visible cart item; never submits an order.",
  inputSchema: {
    type: "object",
    properties: {
      itemId: { type: "string", minLength: 1 },
      quantity: { type: "integer", minimum: 1, maximum: 10 }
    },
    required: ["itemId", "quantity"]
  },
  async execute({ itemId, quantity }) {
    const result = await setVisibleCartQuantity(itemId, quantity);
    return { content: [{ type: "text", text: result.summary }] };
  }
}, { signal: controller.signal });

भले ही कोई ऑर्डर टूल मौजूद हो, यह "यूज़र पुष्टि आवश्यक है" लौटाता है और स्वयं पैसे चार्ज नहीं कर सकता है। प्रत्येक कॉल टूल संस्करण, पैरामीटर-सत्यापन परिणाम और पेज स्थिति को रिकॉर्ड करता है। मूल्यांकन सेट में गलत आइटम, अत्यधिक मात्रा, पुराना मूल्य, अस्वीकृत पुष्टि और WebMCP अनुपलब्धता शामिल है। इसलिए WebMCP प्रतिसंहरणीय (revocable) प्रोग्रेसिव एन्हांसमेंट है; व्यावसायिक ऑथराइजेशन और यूज़र का इरादा मौजूदा पथ में बना रहता है।

सामान्य गलतियाँ

• प्रारंभिक-परीक्षण WebMCP सुविधा को एक स्थिर बैकएंड API के रूप में वर्णित करना।
• एक सार्वभौमिक टूल को एक्सपोज़ करना जो सीधे भुगतान कर सकता है, खाता हटा सकता है, या किसी भी पते को बदल सकता है।
• स्कीमा को केवल ब्राउज़र में मान्य करना और लॉगिन, इन्वेंट्री, मूल्य और आइडेम्पोटेंसी के लिए सर्वर जांच को छोड़ना।
• डिफ़ॉल्ट रूप से क्रॉस-ओरिजिन iframes के साथ टूल्स साझा करना या टूल परिणाम के रूप में पूर्ण यूज़र प्रोफ़ाइल वापस करना।
• कोई सामान्य UI, क्षमता का पता लगाने, निरसन पथ (revocation path), या एजेंट मूल्यांकन सेट प्रदान न करना।

एक मजबूत उत्तर टूल अनुबंध, सर्वर ऑथराइजेशन, ओरिजिन अलगाव, यूज़र पुष्टि, फ़ॉलबैक और मात्रात्मक मूल्यांकन को कवर करता है। "बटन में विवरण जोड़ें" सुरक्षित एक्चुएशन प्रदर्शित नहीं करता है।

फ़ॉलो-अप सवाल और जवाब

ऑर्डर प्लेसमेंट को भी WebMCP टूल के रूप में पंजीकृत क्यों नहीं किया जाता है?

आप एक ऐसा टूल पंजीकृत कर सकते हैं जो ऑर्डर सारांश तैयार करता है, लेकिन अंतिम सबमिशन के लिए पेज पुष्टि और सर्वर ऑथराइजेशन की आवश्यकता होनी चाहिए। एक टूल कॉल यह साबित नहीं करता है कि यूज़र भुगतान करने के लिए सहमत हुआ है और मूल्य, इन्वेंट्री या धोखाधड़ी जांच को बायपास नहीं कर सकता है।

आप क्रॉस-ओरिजिन iframe में टूल एक्सपोज़र को कैसे प्रतिबंधित करते हैं?

डिफ़ॉल्ट रूप से इसे क्रॉस-ओरिजिन संदर्भों के लिए एक्सपोज़ न करें। यदि आवश्यक हो, तो एक स्पष्ट Permissions-Policy और iframe allow कॉन्फ़िगरेशन का उपयोग करें, फिर टूल परत पर पठनीय और लिखने योग्य डेटा को सीमित करें। ओरिजिन, पेज जीवनचक्र और निरसन को लॉग करें।

क्या होगा यदि एजेंट स्कीमा-मान्य लेकिन व्यवसाय-अमान्य पैरामीटर भेजता है?

क्लाइंट में अदृश्य आइटम, पुरानी स्थिति और वर्तमान यूज़र के दायरे से बाहर के मानों को अस्वीकार करें, फिर सर्वर पर व्यावसायिक सत्यापन दोहराएं और एक संरचित अस्वीकृति लौटाएं। स्ट्रिंग्स को मनमाने कार्यों में न बदलें या पैरामीटर्स को चुपचाप फिर से न लिखें।

आप कैसे साबित करते हैं कि एजेंट टूल्स को समझता है?

टूल चयन, मान्य-पैरामीटर दर, पूर्णता, गलत आह्वान और अस्वीकृति शुद्धता को मापने के लिए एक निश्चित कार्य सेट और वास्तविक पेजों का उपयोग करें। भुगतान और हटाने के लिए एक शून्य-गलत-आह्वान गेट सेट करें, और API परिवर्तनों के बाद मूल्यांकन फिर से चलाएं।