# शासन: Registries, Versions और स्वामित्व — MCP और Agent-to-Agent Protocols

Source: https://www.geekswithgeeks.com/hi/mcp-a2a/t-govern

> Servers और agents की सूची ज़िम्मेदारी से चलाएँ।

## हर endpoint का कोई स्वामी होना चाहिए

जैसे-जैसे servers और agents बढ़ते हैं, फैलाव और जोखिम बढ़ते हैं। अनुमोदित MCP servers और Agent Cards की **registry** रखें जिसमें **स्वामी**, उद्देश्य, डेटा वर्गीकरण, आवश्यक scopes, संस्करण और समीक्षा तिथि हों। प्रविष्टियाँ जोड़ने से पहले **सुरक्षा समीक्षा** अनिवार्य करें, **संस्करण pin और समीक्षा** करें, और **deprecation प्रक्रिया** तय करें: बदलावों की घोषणा, पुराने contract का कुछ अवधि तक समर्थन, फिर उसे हटाना। Tool नाम/schemas और Agent Card skills को semantic versioning वाली **सार्वजनिक APIs** मानें। साझा servers और agents के लिए **SLOs** तय करें, on-call स्वामित्व दें, और audit logs की समय-समय पर समीक्षा करें। अनुमोदित कम-जोखिम servers के लिए **तेज़ रास्ता** दें ताकि टीमें shadow integrations से शासन को टालें नहीं।

## Registry प्रविष्टि

वे fields जो server या agent को समीक्षा-योग्य और स्वामित्व वाला बनाते हैं।

```json
{
  "name": "orders-mcp",
  "kind": "mcp-server",
  "owner": "orders-platform-team",
  "purpose": "Read order status for support agents",
  "data_class": "customer-internal",
  "scopes": ["orders:read"],
  "version": "1.4.2 (pinned, hash recorded)",
  "tools": ["get_order_status"],
  "review": { "security": "2026-09-14", "next": "2027-03-14" },
  "deprecation_policy": "90 days notice for breaking changes"
}
```

**Quiz:** Tool schemas और Agent Card skills को सार्वजनिक APIs क्यों मानें?

- [ ] वे गुप्त हैं
- [x] अन्य systems और prompts उन पर निर्भर हैं, इसलिए बदलाव callers तोड़ सकते हैं
- [ ] वे कभी नहीं बदलते
- [ ] वे tests की जगह लेते हैं

*Answer:* अन्य systems और prompts उन पर निर्भर हैं, इसलिए बदलाव callers तोड़ सकते हैं. उन्हें किसी भी API जितनी सावधानी से version और deprecate करें।