शासन: Registries, Versions और स्वामित्व

हर 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 को समीक्षा-योग्य और स्वामित्व वाला बनाते हैं।

{
  "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"
}

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

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