MCP केवल AI के लिए एक API लेयर नहीं है

सभी लोग MCP को “AI के लिए बस एक API कॉलिंग लेयर” कहते हैं। यह धारणा गलत है — और यही कारण है कि “हमारे पास पहले से Swagger है” वाली आपत्ति बार-बार उठती है। दोनों बातों को समझना जरूरी है।

MCP वास्तव में क्या है

MCP का मतलब है Model Context Protocol। Anthropic ने इसे नवंबर 2024 में घोषित किया [1], और दिसंबर 2025 तक इसे Linux Foundation को Agentic AI Foundation के तहत दान कर दिया गया, जिसे Block और OpenAI के साथ मिलकर स्थापित किया गया था [2]। अकेले यह अपनाने की गति ध्यान देने योग्य है।

एक वाक्य में: MCP एक मानक है जो बताता है कि AI मॉडल रनटाइम पर बाहरी टूल्स को कैसे खोजते और उपयोग करते हैं।

यह JSON-RPC 2.0 पर बना है [2]। एक AI और उसके टूल्स के बीच हर संदेश एक संरचित रिमोट प्रोसीजर कॉल है — न कोई REST एंडपॉइंट, न कोई वेबहुक। वायर फॉर्मेट हमेशा एक जैसा रहता है, चाहे टूल कुछ भी करे या किसने बनाया हो।

एक MCP सर्वर एक मॉडल को ठीक तीन प्रकार की चीजें प्रदान करता है [3]:

• Tools — कॉल करने योग्य फंक्शन। जैसे get_weather(city) या create_github_issue(title, body)।
• Resources — संरचित डेटा जिसे मॉडल पढ़ सकता है। कोई फाइल, डेटाबेस रो, या कॉन्फिग ऑब्जेक्ट।
• Prompts — पूर्व-निर्मित टेम्पलेट जो बताते हैं कि मॉडल को सर्वर के साथ कैसे इंटरैक्ट करना चाहिए।

मॉडल रनटाइम पर सर्वर से पूछ सकता है: आप क्या कर सकते हैं? सर्वर क्षमताओं की एक सूची के साथ जवाब देता है। मॉडल उस सूची से चुनता है। इसे ListToolsRequest [4] कहा जाता है, और यह प्रोटोकॉल का एक मुख्य हिस्सा है — कोई वैकल्पिक फीचर नहीं जिसे किसी ने बाद में जोड़ा हो।

“प्रोटोकॉल” क्यों, न कि सिर्फ “API”

एक API एक सतह है — एंडपॉइंट्स या फंक्शन का एक सेट जिसे आप कॉल करते हैं। एक प्रोटोकॉल एक अनुबंध है जो बताता है कि संचार कैसे होता है, जिसमें ट्रांसपोर्ट, मैसेज लाइफसाइकिल, एरर फॉर्मेट, क्षमता वार्ता और सेशन प्रबंधन शामिल हैं।

HTTP एक प्रोटोकॉल है। REST एक आर्किटेक्चरल स्टाइल है जो उसके ऊपर परतदार है। MCP एक प्रोटोकॉल है।

यहां विशेष रूप से वह है जो MCP परिभाषित करता है और जो इसे यह लेबल दिलाता है:

• ट्रांसपोर्ट लेयर — तीन विकल्प: सबप्रोसेस के रूप में चलने वाले स्थानीय टूल्स के लिए STDIO, रिमोट टूल्स के लिए HTTP+SSE, और पूर्ण-डुप्लेक्स इंटरएक्टिविटी के लिए WebSocket [5]।
• सेशन लाइफसाइकिल — एक हैंडशेक जहां क्लाइंट और सर्वर एक बार क्षमताओं पर बातचीत करते हैं, फिर एक स्टेटफुल सेशन बनाए रखते हैं। हर बाद का JSON-RPC कॉल तेज होता है क्योंकि कोई पुनः-वार्ता नहीं होती [5]।
• क्षमता वार्ता — सर्वर घोषित करता है कि वह कौन सा वर्शन बोलता है, कौन से प्रिमिटिव्स प्रदान करता है, और क्या सपोर्ट करता है। क्लाइंट अनुकूलन करता है।
• मानकीकृत एरर फॉर्मेट — हमेशा एक ही संरचना। कोई कस्टम एरर स्कीमा नहीं।

इसकी तुलना एक REST API से करें। हर एक अपनी खुद की ऑथ स्कीम, अपनी पेजिनेशन रणनीति, अपने एरर कोड, अपना वर्शनिंग बनाता है। एक डेवलपर डॉक्स पढ़ता है और एडेप्टर कोड लिखता है। MCP इन सभी के लिए मानक पैटर्न अनिवार्य करता है [4]।

सबसे करीबी उपमा LSP — Language Server Protocol है [2]। आपके IDE को “Python भाषा सर्वर से कैसे बात करें” बनाम “TypeScript भाषा सर्वर से कैसे बात करें” के लिए अलग-अलग प्लगइन की जरूरत नहीं है। LSP बातचीत का आकार परिभाषित करता है। हर भाषा सर्वर इसे बोलता है। MCP AI टूल्स के लिए वही काम करता है।

ध्यान दें कि इस चित्र में OpenAPI कहां है — MCP सर्वर के अंदर, इससे प्रतिस्पर्धा में नहीं।

“हमारे पास पहले से Swagger है” की आपत्ति

यह सबसे आम पुशबैक है। तर्क यह है: OpenAPI पहले से ही मेरे सभी एंडपॉइंट्स का वर्णन करता है। एक AI उस स्पेक को पढ़ सकता है और API को कॉल कर सकता है। MCP को ऊपर क्यों जोड़ें?

उचित प्रश्न। गलत निष्कर्ष।

OpenAPI मनुष्यों के लिए लिखा गया एक दस्तावेज़ीकरण फॉर्मेट है। यह आपके API का वर्णन करता है ताकि एक डेवलपर इसे पढ़ सके और इसके खिलाफ कोड लिख सके। विवरण मानवीय संदर्भ मान लेते हैं। ऑथ पैटर्न, पेजिनेशन, एरर कोड — जैसा टीम को ठीक लगा [6]।

एक कच्चे OpenAPI स्पेक के सामने LLM रखें और कई चीजें तुरंत टूट जाती हैं:

• GitHub API में 600 से अधिक एंडपॉइंट हैं [7]। LLM से सही एंडपॉइंट चुनने को कहें और वह भ्रमित हो जाता है — बहुत अधिक विकल्प, मानव डेवलपर्स के लिए लिखे गए विवरणों में बहुत अधिक अस्पष्टता।
• OpenAPI में कोई मानकीकृत रनटाइम डिस्कवरी नहीं है। आप LLM को पहले से एक स्टैटिक स्पेक फाइल देते हैं। MCP का ListToolsRequest हर सेशन में लाइव होता है, सर्वर के साथ जो यह नियंत्रित करता है कि वह क्या प्रदर्शित करता है।
• हर REST API कस्टम ऑथ, कस्टम पेजिनेशन, कस्टम एरर शेप्स का उपयोग करता है। आपके LLM को हर एक के लिए कस्टम एडेप्टर कोड चाहिए। MCP मानक पैटर्न अनिवार्य करता है [4]।
• एजेंट नियमित रूप से OpenAPI पैरामीटर कॉन्स्ट्रेंट्स को गलत समझते हैं और ऐसे फील्ड बनाते हैं जो मौजूद नहीं हैं [6]। डेवलपर्स के लिए लिखे गए विवरण, एजेंट निर्णय लेने के लिए लिखे गए विवरणों के समान नहीं हैं।

यहां तुलना सीधे रखी है:

वे दुश्मन नहीं हैं। एक MCP सर्वर एक मौजूदा REST API को आंतरिक रूप से लपेट सकता है, और अक्सर लपेटता है। FastMCP जैसे टूल्स एक OpenAPI स्पेक से सीधे MCP सर्वर ऑटो-जेनरेट कर सकते हैं [8]। MCP सर्वर आपके मौजूदा API के ऊपर एक क्यूरेटेड, एजेंट-फ्रेंडली फेसाड बन जाता है। आप डेवलपर-फेसिंग डॉक्स के लिए OpenAPI रखते हैं। आप एजेंट-फेसिंग इंटरैक्शन के लिए MCP जोड़ते हैं।

N×M समस्या

MCP से पहले, AI असिस्टेंट को बाहरी टूल्स से जोड़ना N×M समस्या थी [1]:

• N = AI मॉडल और असिस्टेंट की संख्या
• M = टूल्स और डेटा स्रोतों की संख्या

हर संयोजन को अपनी खुद की इंटीग्रेशन की जरूरत थी। Claude का GitHub एडेप्टर Cursor के साथ काम नहीं करता था। Cursor का एडेप्टर अगले एजेंट के साथ काम नहीं करता था। हर टीम ने शुरुआत से अलग-अलग ग्लू कोड लिखा।

MCP इसे N+M में बदल देता है। GitHub के लिए एक MCP सर्वर बनाएं — यह किसी भी MCP क्लाइंट के साथ काम करता है। Claude, Cursor, Windsurf, कोई भी एजेंट जो प्रोटोकॉल बोलता है। यह वास्तविक मूल्य प्रस्ताव है — “यह APIs को कॉल करता है” नहीं, बल्कि “यह यूनिवर्सल कनेक्टर शेप है ताकि आप एडेप्टर एक बार लिखें।”

एक बात जो जाननी चाहिए

आप कुछ ही मिनटों में एक मौजूदा OpenAPI स्पेक से MCP सर्वर ऑटो-जेनरेट कर सकते हैं [8]। बढ़िया लगता है। लेकिन इस पर हर गंभीर लेख एक ही बात की चेतावनी देता है: बाद में आक्रामक तरीके से छांटें [7]। 600-एंडपॉइंट वाला GitHub MCP सर्वर LLM के लिए एक आपदा है। 12-टूल वाला क्यूरेटेड सर्वर खूबसूरती से काम करता है। जेनरेशन आपको शुरू करता है। क्यूरेशन असली काम है।

हुड के नीचे, MCP एक पाइप या HTTP स्ट्रीम पर JSON-RPC कॉल है — कोई जादू नहीं। लेकिन प्रोटोकॉल ही बात है: हर जगह बातचीत का एक ही आकार, स्टेटफुल सेशन, रनटाइम डिस्कवरी और मानक एरर हैंडलिंग के साथ। यही AI एजेंट को टूल्स और प्रोवाइडर्स के पार वास्तव में कंपोज़ेबल बनाता है।

समाप्त

स्रोत

1. Introducing the Model Context Protocol — Anthropic
2. Model Context Protocol — Wikipedia
3. Model Context Protocol (MCP) an overview — Phil Schmid
4. MCP vs APIs: What’s the Real Difference? — freeCodeCamp
5. Architecture overview — Model Context Protocol
6. Exposing OpenAPI as MCP Tools — Christian Posta
7. Auto-generating MCP Servers from OpenAPI Schemas: Yay or Nay? — Neon
8. From OpenAPI (Swagger) to MCP Servers — La Rebelion