सगळे MCP ला “AI साठी फक्त एक API कॉलिंग लेयर” म्हणतात. हे चुकीचे आहे — आणि म्हणूनच “आमच्याकडे आधीच Swagger आहे” हा आक्षेप वारंवार येतो. दोन्ही गोष्टींचा उलगडा करणे आवश्यक आहे.
MCP प्रत्यक्षात काय आहे
MCP म्हणजे Model Context Protocol. Anthropic ने नोव्हेंबर 2024 मध्ये याची घोषणा केली [1], आणि डिसेंबर 2025 पर्यंत ते Block आणि OpenAI सह सह-स्थापित Agentic AI Foundation अंतर्गत Linux Foundation ला दान करण्यात आले [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] म्हणतात, आणि हे प्रोटोकॉलचा मुख्य भाग आहे — कोणी जोडलेले ऐच्छिक वैशिष्ट्य नाही.
“Protocol” का, फक्त “API” नाही
API म्हणजे एक पृष्ठभाग — एंडपॉइंट्स किंवा फंक्शन्सचा संच जे तुम्ही कॉल करता. प्रोटोकॉल म्हणजे संवाद कसा होतो याबद्दलचा करार, ज्यात ट्रान्सपोर्ट, संदेश जीवनचक्र, एरर फॉर्मेट, क्षमता वाटाघाटी आणि सत्र व्यवस्थापन समाविष्ट आहे.
HTTP हे एक प्रोटोकॉल आहे. REST हे त्यावर आधारित एक आर्किटेक्चरल शैली आहे. MCP हे एक प्रोटोकॉल आहे.
MCP नेमके काय परिभाषित करते जे त्याला हे लेबल मिळवून देते:
- Transport layer — तीन पर्याय: सबप्रोसेस म्हणून चालणाऱ्या स्थानिक साधनांसाठी STDIO, दूरस्थ साधनांसाठी HTTP+SSE, पूर्ण-द्विदिश संवादासाठी WebSocket [5].
- Session lifecycle — एक हँडशेक जिथे क्लायंट आणि सर्व्हर एकदा क्षमतांची वाटाघाटी करतात, नंतर एक स्टेटफुल सत्र राखतात. प्रत्येक त्यानंतरचे JSON-RPC कॉल जलद असते कारण पुनर्वाटाघाटी नसते [5].
- Capability negotiation — सर्व्हर घोषित करतो की तो कोणती आवृत्ती बोलतो, कोणते प्रिमिटिव्ह उघड करतो, काय समर्थन करतो. क्लायंट अनुकूलित होतो.
- Standardized error format — समान संरचना, नेहमी. कोणतेही कस्टम एरर स्कीमा नाहीत.
हे REST API शी तुलना करा. प्रत्येक एक स्वतःची auth योजना, स्वतःची pagination धोरण, स्वतःचे एरर कोड, स्वतःचे versioning शोधते. एक डेव्हलपर डॉक्स वाचतो आणि adapter कोड लिहितो. MCP हे सर्वांसाठी मानक पॅटर्न अनिवार्य करते [4].
सर्वात जवळचे साधर्म्य LSP — Language Server Protocol [2] आहे. तुमच्या IDE ला “Python language server शी कसे बोलावे” विरुद्ध “TypeScript language server शी कसे बोलावे” साठी वेगळ्या प्लगइनची आवश्यकता नाही. LSP संभाषणाची आकार परिभाषित करते. प्रत्येक language server ते बोलतो. MCP AI साधनांसाठी तेच करते.
या चित्रात OpenAPI कुठे आहे ते लक्षात घ्या — MCP सर्व्हरच्या आत, त्याच्याशी स्पर्धा करत नाही.
“आमच्याकडे आधीच Swagger आहे” हा आक्षेप
हा सर्वात सामान्य प्रतिरोध आहे. युक्तिवाद: OpenAPI आधीच माझ्या सर्व एंडपॉइंट्सचे वर्णन करते. एक AI ती spec वाचू शकते आणि API कॉल करू शकते. मग MCP का जोडायचे?
योग्य प्रश्न. चुकीचा निष्कर्ष.
OpenAPI हे मानवांसाठी लिहिलेले दस्तऐवजीकरण स्वरूप आहे. ते तुमच्या API चे वर्णन करते जेणेकरून एक डेव्हलपर ते वाचू शकेल आणि त्याविरुद्ध कोड लिहू शकेल. वर्णने मानवी संदर्भ गृहीत धरतात. Auth पॅटर्न, pagination, एरर कोड — टीमने जसे ठरवले तसे [6].
कच्च्या OpenAPI spec समोर LLM ठेवा आणि अनेक गोष्टी लगेच तुटतात:
- GitHub API मध्ये 600 पेक्षा जास्त एंडपॉइंट्स आहेत [7]. LLM ला योग्य निवडण्यास सांगा आणि ते गोंधळून जाते — मानवी डेव्हलपर्ससाठी लिहिलेल्या वर्णनांमध्ये खूप जास्त पर्याय, खूप जास्त अस्पष्टता.
- OpenAPI मध्ये कोणतीही मानकीकृत रनटाइम डिस्कव्हरी नाही. तुम्ही LLM ला आगाऊ एक स्थिर spec फाइल देता. MCP चा
ListToolsRequestप्रत्येक सत्रात थेट होतो, सर्व्हर नेमके काय उघड करतो ते नियंत्रित करतो. - प्रत्येक REST API कस्टम auth, कस्टम pagination, कस्टम एरर आकार वापरते. तुमच्या LLM ला प्रत्येकासाठी बेस्पोक adapter कोडची आवश्यकता आहे. MCP मानक पॅटर्न अनिवार्य करते [4].
- एजंट नियमितपणे OpenAPI पॅरामीटर बाधाचा चुकीचा अर्थ लावतात आणि अस्तित्वात नसलेली फील्ड शोधतात [6]. डेव्हलपर्ससाठी लिहिलेली वर्णने एजंट निर्णय घेण्यासाठी लिहिलेल्या वर्णनांसारखी नाहीत.
येथे तुलना स्पष्टपणे दिली आहे:
| पैलू | OpenAPI / Swagger | MCP |
|---|---|---|
| मुख्य प्रेक्षक | मानवी डेव्हलपर | AI एजंट (LLM) |
| डिस्कव्हरी | स्थिर spec फाइल | रनटाइम ListToolsRequest |
| सत्र स्थिती | स्टेटलेस HTTP | स्टेटफुल सत्र |
| ट्रान्सपोर्ट पर्याय | HTTP / REST | STDIO, HTTP+SSE, WebSocket |
| Auth पॅटर्न | प्रत्येक API ठरवते | प्रोटोकॉलमध्ये मानकीकृत |
| वर्णने लिहिलेली | डॉक्स वाचणाऱ्या डेव्हलपरसाठी | साधन निवड करणाऱ्या एजंटसाठी |
| सर्व साधनांमध्ये एकसमान काम करते? | नाही — बेस्पोक adapters | होय — एकल प्रोटोकॉल |
ते शत्रू नाहीत. MCP सर्व्हर अंतर्गत विद्यमान REST API ला गुंडाळू शकतो, आणि अनेकदा करतो. FastMCP सारखी साधने OpenAPI spec मधून थेट MCP सर्व्हर स्वयंचलितपणे तयार करू शकतात [8]. MCP सर्व्हर तुमच्या विद्यमान API वर एक क्युरेटेड, एजंट-अनुकूल दर्शनी भाग बनतो. तुम्ही डेव्हलपर-मुखी दस्तऐवजांसाठी OpenAPI ठेवता. तुम्ही एजंट-मुखी संवादासाठी MCP जोडता.
N×M समस्या
MCP पूर्वी, AI सहाय्यकांना बाह्य साधनांशी जोडणे ही N×M समस्या होती [1]:
- N = AI मॉडेल्स आणि सहाय्यकांची संख्या
- M = साधने आणि डेटा स्रोतांची संख्या
प्रत्येक संयोजनाला स्वतःची integration आवश्यक होती. Claude चा GitHub adapter Cursor सह काम करणार नाही. Cursor चा adapter पुढच्या एजंटसह काम करणार नाही. प्रत्येक टीम स्वतंत्रपणे, शून्यातून glue कोड लिहित असे.
MCP ते N+M मध्ये बदलते. GitHub साठी एक MCP सर्व्हर बनवा — ते कोणत्याही MCP क्लायंटसह काम करते. Claude, Cursor, Windsurf, प्रोटोकॉल बोलणारा कोणताही एजंट. हे प्रत्यक्ष मूल्य प्रस्ताव आहे — “ते API कॉल करते” नाही तर “ते सार्वत्रिक कनेक्टर आकार आहे म्हणून तुम्ही adapter एकदाच लिहिता.”
एक महत्त्वाची गोष्ट
तुम्ही काही मिनिटांत विद्यमान OpenAPI spec मधून MCP सर्व्हर स्वयंचलितपणे तयार करू शकता [8]. छान वाटते. पण याबद्दलचे प्रत्येक गंभीर लेखन एकच गोष्ट सांगते: नंतर आक्रमकपणे छाट [7]. 600-endpoint चा GitHub MCP सर्व्हर LLM साठी आपत्ती आहे. 12-साधनांचा क्युरेटेड एक सुंदरपणे काम करतो. जनरेशन तुम्हाला सुरुवात करवते. curation हे प्रत्यक्ष काम आहे.
आतून, MCP म्हणजे पाईप किंवा HTTP स्ट्रीमवर JSON-RPC कॉल्स — जादू नाही. पण प्रोटोकॉल हाच मुद्दा आहे: सर्वत्र एकच संभाषण आकार, स्टेटफुल सत्रांसह, रनटाइम डिस्कव्हरी आणि मानक एरर हाताळणीसह. यामुळेच AI एजंट साधने आणि प्रदात्यांमध्ये खरोखरच composable बनतात.
समाप्त
स्रोत
- Introducing the Model Context Protocol — Anthropic
- Model Context Protocol — Wikipedia
- Model Context Protocol (MCP) an overview — Phil Schmid
- MCP vs APIs: What’s the Real Difference? — freeCodeCamp
- Architecture overview — Model Context Protocol
- Exposing OpenAPI as MCP Tools — Christian Posta
- Auto-generating MCP Servers from OpenAPI Schemas: Yay or Nay? — Neon
- From OpenAPI (Swagger) to MCP Servers — La Rebelion