तुमने अपने AI agent को पंद्रह MCP servers से जोड़ा — Slack, GitHub, Jira, एक database — और सब कुछ टेस्ट करके परफेक्ट बनाया। MCP (Model Context Protocol) वो universal plug standard है जो AI agents को बाहरी tools से बात करने देता है, जैसे USB लेकिन data के लिए। तुम्हारा demo शानदार था। बॉस ने सिर हिलाया। तुमने production में शिप कर दिया।

अब वो बात जो किसी ने नहीं बताई: MCP servers तुम्हारी disk पर पड़ी हुई static packages नहीं हैं। ये live processes और remote endpoints हैं। और 25 अप्रैल 2026 तक, कोई भी agent platform तुम्हें नहीं बताएगा जब इनमें से कोई down हो जाए, घोंघे की स्पीड पर आ जाए, या कचरा return करने लगे।

तुम्हारे आधे tools शायद पहले से ही मरे पड़े हैं

20 अप्रैल को, RapidClaw ने सात registries में 1,847 public MCP servers का audit किया। नतीजा: 52% dead या abandoned हैं। सिर्फ 17% — 315 servers — production-ready निकले। एक average MCP server की ज़िंदगी में छह commits हैं, एक maintainer, zero tests, और 142 दिनों से कोई update नहीं।

यही वो ecosystem है जिस पर तुम्हारा agent निर्भर है। सिक्का उछालो — तब पता चलेगा कि जो tool वो call कर रहा है, वो अभी भी काम करता है या नहीं।

और MCP protocol खुद कोई मदद नहीं करता। कोई built-in health check endpoint नहीं — कोई standardized तरीका नहीं जिससे server बोल सके "मैं ज़िंदा हूँ और सही काम कर रहा हूँ।" SDKs में एक basic ping है, लेकिन कोई /health, कोई /ready, कोई liveness probe नहीं। हर टीम अपना बनाती है, या — ज़्यादातर — कुछ नहीं बनाती।

Protocol में छेद

ये gap सिर्फ platforms में नहीं — spec में है। HTTP के पास status codes हैं। gRPC के पास health checking services हैं। Kubernetes के पास liveness और readiness probes हैं। MCP के पास... एक ping method है जो confirm करता है कि transport layer ज़िंदा है, ये नहीं कि server अपना काम कर भी सकता है।

एक database MCP server ping का जवाब दे सकता है जबकि उसका connection pool खत्म हो चुका हो। एक GitHub MCP server pong भेज सकता है जबकि उसका auth token तीन हफ्ते पहले expire हो चुका हो। Protocol "transport चल रहा है" और "tool काम कर रहा है" में कोई फर्क नहीं करता। ये फर्क तब मायने रखता है जब तुम्हारा agent उस tool पर tokens जला रहा है जो technically जवाब देता है लेकिन functionally झूठ बोलता है।

Google का Agent Observability, 22 अप्रैल को Gemini Enterprise Agent Platform के हिस्से के रूप में शिप हुआ, MCP servers के लिए request count और p95 latency track करता है। दो metrics। बस दो। हमने पहले ही platform की बड़ी कमियों को cover किया था — छोटी बात ये है कि Google ने agent-level tracing बनाई, tool-level monitoring नहीं। AWS ने 17 अप्रैल को Agent Registry का preview दिखाया — agents की phone book, health monitor नहीं। दोनों मानते हैं कि tools को infrastructure treatment चाहिए। दोनों में से कोई actually check नहीं करता कि तुम्हारे tools ज़िंदा हैं या नहीं।

तुलना के लिए — कोई भी ठीक-ठाक microservice — तुम्हारे backend का एक छोटा, independent हिस्सा — उसे health checks मिलते हैं, error rates मिलती हैं, response quality analysis होता है, automated alerts आते हैं। तुम्हारे MCP server को? एक request counter और एक stopwatch।

जब tool टूटता है तो क्या टूटता है

जब MCP server चुपचाप degrade होता है, तुम्हारे agent को पता नहीं चलता। वो या तो जवाब hallucinate कर लेता है (यानी बना लेता है), चुपचाप retry करके tokens जलाता है — वो word-chunks जो AI पढ़ता है, हर एक पैसे खर्च होते हैं — या fail हो जाता है बिना बताए कि कौन सा tool टूटा। Agent observability traces दिखाते हैं कि agent ने क्या decide किया। ये नहीं दिखाते कि tool healthy था जब उसने जवाब दिया। तुम्हें symptom दिखता है। Cause diagnose नहीं कर सकते।

ये ऐसा है जैसे तुम अपनी web app monitor कर रहे हो लेकिन उसका database नहीं। Dashboard हरा रहता है जब तक सब कुछ आग में नहीं होता।

अभी क्या करो

अगर तुम production में agents चला रहे हो, तो हर MCP server को एक microservice dependency की तरह treat करो:

  • Timeouts सेट करो। MCP protocol तुम्हारे लिए ये नहीं करेगा।
  • Fallbacks define करो। अगर tool down है, तुम्हारे agent को Plan B चाहिए, improvised hallucination नहीं।
  • Response quality monitor करो। एक 200 OK जो बकवास return करे, clean failure से भी बुरा है।
  • Connections को circuit breakers में wrap करो — एक pattern जो failing service को बाकी सब कुछ नीचे खींचने से पहले काट देता है।
  • Ceiling accept करो। तुम्हारा agent उतना ही reliable है जितना उसका सबसे unreliable tool।

ज़्यादातर teams ने इस plumbing के लिए budget नहीं रखा। ज़्यादातर teams को जल्दी पता चलेगा कि क्यों रखना चाहिए था।

वो layer जो गायब है

अप्रैल 2026 का agent stack — smarter models हैं, बड़ी registries हैं, fancy gateways हैं। जो नहीं है वो tool SRE — Site Reliability Engineering जो agents के tools पर apply हो। इस channel के पिछले articles में argue किया गया कि agent reliability engineering अभी exist नहीं करती। RapidClaw का audit prove करता है कि problem एक level और गहरी है: तुम्हारे पास reliable agents हो ही नहीं सकते जब जिस protocol में वो बात करते हैं, उसने ये define ही नहीं किया कि tool के लिए "healthy" का मतलब क्या है।

जो पहला platform tool-level health monitoring शिप करेगा — /health और /ready endpoints MCP spec में baked in, हर vendor द्वारा ऊपर से चिपकाए नहीं — वो उस reliability layer को capture कर लेगा जो पूरे ecosystem में गायब है।

तुमने पंद्रह MCP servers से शुरू किया था जो dev में बिल्कुल सही चल रहे थे। Production में, उनमें से करीब आठ सिक्के उछालने जितने भरोसेमंद हैं। कोई देख नहीं रहा। शायद वहीं से शुरू करो।