# केस स्टडी: टीमों के पार Refund सहायक — MCP और Agent-to-Agent Protocols

Source: https://www.geekswithgeeks.com/hi/mcp-a2a/z-case

> ऐसा सहायक डिज़ाइन करें जो MCP tools उपयोग करे और दूसरी टीम के agent को काम सौंपे।

## डिज़ाइन

लक्ष्य: support स्टाफ़ सहायक से refund अनुरोध सँभालने को कहें। **Front-door agent** (support टीम): तीन servers वाला MCP host, सभी जाँचे, pin किए और sandboxed: `orders-mcp` (केवल-पढ़ने वाला `get_order_status`), `docs-mcp` (resources के रूप में नीतियाँ) और `ticketing-mcp` (नोट बनाना)। Tool परिभाषाओं के snapshot tests हैं। **सौंपना**: refund गणना के लिए वह registry में Agent Card (skill `propose-refund`) से मिले **Billing agent** (finance के स्वामित्व) को **A2A task** भेजता है, सिर्फ़ invoice id और कारण देकर। Billing agent `input-required` ("कौन-सी पंक्ति क्षतिग्रस्त है?") उत्तर दे सकता है, जिसे front door स्टाफ़ सदस्य तक पहुँचाता है। **नीति** (host कोड में): allow-list tools, राशि सीमा जाँच, कुछ भी भुगतान होने से पहले **मानव अनुमोदन**, अंतिम user की पहचान प्रत्यायोजित करने वाले scoped, अल्पकालिक tokens, कभी आगे भेजे नहीं। **सुरक्षा**: सभी tool और agent आउटपुट डेटा के रूप में लपेटे और scan किए; कोई tool निजी डेटा, अविश्वसनीय सामग्री और बाहर भेजना नहीं जोड़ता। **गुणवत्ता**: servers के contract tests, routing व state tests के लिए stub Billing agent, 100-मामलों का मूल्यांकन (परिणाम, trajectory, सुरक्षा), hops के पार trace id, redacted audit logs, लागत और अनुमोदन backlog पर alerts।

## जुड़ा, शासित, सुरक्षित

मानक protocols, कड़ी नीति और अच्छे tests कई agents और tools को एक भरोसेमंद system बनाते हैं।

![चार आदतें: मानकीकरण, सीमा, परीक्षण, निगरानी।](assets/figures/mcp-a2a/section-8-map.svg) — चित्र 8.1 — मानकीकरण, सीमा, परीक्षण और निगरानी।

## एक पन्ने पर डिज़ाइन

हर पंक्ति इस कोर्स के एक खंड से जुड़ती है।

```text
Tools      orders-mcp (read-only), docs-mcp (resources), ticketing-mcp; vetted, pinned, sandboxed  (Sec 3, 5)
Delegate   A2A task to Billing agent found via registry + Agent Card skill "propose-refund"          (Sec 6)
Dialogue   input-required relayed to the staff member; terminal states final                         (Sec 6)
Policy     allow-list + amount range + human approval before payment; scoped short-lived tokens      (Sec 4, 5)
Safety     tool/agent output = untrusted data; no private+untrusted+outbound combination             (Sec 5)
Quality    contract tests, stub remote agent, 100-case eval, trace id, redacted audit logs            (Sec 3, 7)
Change     pinned SDK/protocol versions, adapter layer, deprecation policy                            (Sec 7)
```

**Quiz:** Front door Billing agent को सिर्फ़ invoice id और कारण क्यों देता है?

- [ ] Tasks से बचने के लिए
- [ ] IDs टाइप करने में तेज़ हैं
- [ ] A2A अन्य fields मना करता है
- [x] Remote agent भरोसे की सीमा के बाहर है और उसे न्यूनतम डेटा मिलना चाहिए

*Answer:* Remote agent भरोसे की सीमा के बाहर है और उसे न्यूनतम डेटा मिलना चाहिए. Remote पक्ष compromised या ग़लत व्यवहार करे तो डेटा न्यूनतम रखना जोखिम सीमित करता है।