MCP सर्वर AI एप्लिकेशन और उन सिस्टम्स के बीच बैठता है जिन तक उसे पहुँचना होता है। यह लेख पूरे रास्ते को डायग्राम में दिखाता है: होस्ट, क्लाइंट, सर्वर, ट्रांसपोर्ट, JSON-RPC हैंडशेक, टूल कॉल, एरर हैंडलिंग और सिक्योरिटी। उदाहरण के तौर पर एक असली इमेज और वीडियो कनेक्टर लिया गया है।
आपका AI असिस्टेंट सेकंडों में कॉन्ट्रैक्ट का ड्राफ़्ट बना सकता है, फिर भी वह अपने आप आपका कैलेंडर नहीं पढ़ सकता, आपके डेटाबेस से क्वेरी नहीं कर सकता या कोई फ़ोटो रीसाइज़ नहीं कर सकता। Model Context Protocol, जिसे छोटे रूप में MCP कहते हैं, AI एप्लिकेशन और उनके आसपास के सिस्टम्स के बीच एक साझा कॉन्ट्रैक्ट से यह दूरी पाटता है। MCP सर्वर उस कॉन्ट्रैक्ट के दूसरे सिरे पर बैठा छोटा प्रोग्राम है: यह बताता है कि वह क्या कर सकता है, रिक्वेस्ट का इंतज़ार करता है और नतीजे एक तय ढाँचे में लौटाता है। यह लेख इस आर्किटेक्चर को एक-एक हिस्से में डायग्राम के साथ समझाता है। हर डायग्राम सादा टेक्स्ट है, इसलिए इसे README, डिज़ाइन डॉक या पुल रिक्वेस्ट में कॉपी-पेस्ट करना आसान रहता है।
MCP से पहले, जो भी AI एप्लिकेशन डेटाबेस, कैलेंडर या फ़ाइल सिस्टम तक पहुँचना चाहता था, उसे अपना अलग कस्टम कनेक्टर बनाना पड़ता था। हर कनेक्टर में अपना ऑथेंटिकेशन, अपना एरर फ़ॉर्मेट और अपने बग होते थे। तीन ऐप्स और तीन टूल्स का मतलब ही नौ इंटीग्रेशन थे, और दोनों तरफ़ हर नए प्रोडक्ट के साथ यह ग्रिड बढ़ता जाता है। MCP इस ग्रिड की जगह एक साझा प्रोटोकॉल लाता है, इसलिए गणित ऐप्स गुणा टूल्स से बदलकर ऐप्स जोड़ टूल्स हो जाता है।
Before MCP: one custom connector for every pair
App A ──► Database App B ──► Database App C ──► Database
App A ──► Calendar App B ──► Calendar App C ──► Calendar
App A ──► Files App B ──► Files App C ──► Files
3 apps x 3 tools = 9 connectors to build and maintain
With MCP: one shared protocol in the middle
App A ──┐ ┌── Database server
App B ──┼──── MCP (JSON-RPC) ─────┼── Calendar server
App C ──┘ └── Files server
3 clients + 3 servers = 6 pieces
शब्द सर्वर लोगों को भ्रमित करता है। MCP सर्वर कोई लैंग्वेज मॉडल नहीं है और वह सोचता नहीं है। यह एक साधारण प्रोग्राम है, जो TypeScript, Python या किसी भी ऐसी भाषा में लिखा जा सकता है जिसमें JSON लाइब्रेरी हो। यह एक असली क्षमता को रैप करता है और उसे ऐसे फ़ॉर्मेट में बताता है जिसे हर कम्पैटिबल क्लाइंट पढ़ सकता है। मॉडल को यह जानने की ज़रूरत नहीं कि आपका डेटाबेस ड्राइवर कैसे काम करता है। उसे बस इतना जानना होता है कि run_query नाम का टूल मौजूद है और वह कौन-से आर्गुमेंट लेता है।
MCP तीन भूमिकाएँ तय करता है, और ज़्यादातर भ्रम इन्हें आपस में मिलाने से होता है। विवरण से पहले यहाँ पूरी तस्वीर है।
┌──────────── HOST (the AI application) ────────────┐
│ The LLM picks a tool, the host routes the call │
│ │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ client 1 │ │ client 2 │ │ client 3 │ │
│ └─────┬──────┘ └─────┬──────┘ └─────┬──────┘ │
└────────┬───────────────┬───────────────┬──────────┘
│ session │ session │ session
┌─────┴──────┐ ┌─────┴──────┐ ┌─────┴──────┐
│ Server A │ │ Server B │ │ Server C │
│ files │ │ GitHub │ │ image tool │
└────────────┘ └────────────┘ └────────────┘
होस्ट वह एप्लिकेशन है जिसे व्यक्ति असल में इस्तेमाल करता है: डेस्कटॉप चैट ऐप, IDE असिस्टेंट या कोई कस्टम एजेंट। यह लैंग्वेज मॉडल चलाता है, तय करता है कि किन सर्वरों से जुड़ना है और उपयोगकर्ता को दिखाता है कि आगे क्या होने वाला है। Claude Sonnet 5, GPT 5.6 Sol और Gemini 3.1 Pro जैसे रीज़निंग मॉडल होस्ट के अंदर बैठते हैं, लेकिन वे खुद MCP नहीं बोलते। होस्ट मॉडल के टूल-कॉलिंग फ़ॉर्मेट और प्रोटोकॉल के बीच अनुवाद करता है, इसीलिए एक ही सर्वर कई अलग-अलग मॉडलों के साथ काम कर सकता है।
होस्ट के अंदर हर सर्वर के लिए एक MCP क्लाइंट बनाया जाता है। हर क्लाइंट ठीक एक सर्वर के साथ एक स्टेटफ़ुल, वन-टू-वन सेशन रखता है, दोनों पक्षों की सहमत क्षमताएँ याद रखता है और हर मैसेज को सही जगह भेजता है। जैसा डायग्राम दिखाता है, तीन सर्वरों से जुड़ा होस्ट तीन क्लाइंट चलाता है। अगर एक सेशन टूट जाए, तो बाकी दो काम करते रहते हैं।
MCP सर्वर एक असली सिस्टम को रैप करता है: एक Postgres डेटाबेस, एक GitHub अकाउंट, दस्तावेज़ों का फ़ोल्डर या कोई इमेज API। वह जानबूझकर छोटा रहता है। वह बताता है कि वह क्या देता है, इनपुट वैलिडेट करता है, कार्रवाई करता है और स्ट्रक्चर्ड आउटपुट लौटाता है। उसे पूरी बातचीत नहीं दिखती, सिर्फ़ वे रिक्वेस्ट दिखती हैं जो उसे भेजी जाती हैं। यह डिज़ाइन प्राइवेसी की रक्षा करता है और सर्वरों को दोबारा इस्तेमाल लायक रखता है।
एक त्वरित सार, जिसे आप अपनी डेस्क के ऊपर चिपका सकते हैं:
सर्वर तीन बिल्डिंग ब्लॉक देता है, जिन्हें प्रिमिटिव्स कहते हैं। इनमें एक अंतर पूरे डिज़ाइन को आकार देता है: कौन तय करता है कि हर एक का इस्तेमाल कब होगा।
| प्रिमिटिव | किसके नियंत्रण में | सामान्य उपयोग | उदाहरण मेथड्स |
|---|---|---|---|
| Tools | मॉडल | कोई कार्रवाई चलाना या कोई नतीजा कैलकुलेट करना | tools/list, tools/call |
| Resources | एप्लिकेशन | फ़ाइलों या रिकॉर्ड जैसा सिर्फ़-पढ़ने वाला संदर्भ देना | resources/list, resources/read |
| Prompts | यूज़र | दोबारा इस्तेमाल होने वाले टेम्पलेट, अक्सर स्लैश कमांड के रूप में दिखाए जाते हैं | prompts/list, prompts/get |
एक टूल का नाम होता है, एक सादी भाषा में विवरण होता है और JSON Schema में लिखा inputSchema होता है। मॉडल विवरण पढ़कर तय करता है कि टूल अनुरोध के लिए सही है या नहीं, और स्कीमा आर्गुमेंट्स को वैध रखता है। विवरण पर वाकई मेहनत करनी चाहिए, क्योंकि धुंधला विवरण मॉडल को अंदाज़ा लगाने पर मजबूर करता है। टूल्स के नाम क्रिया-पद जैसे रखें, हर टूल को संकीर्ण रखें और सिर्फ़ वही फ़ील्ड लौटाएँ जो मॉडल को चाहिए। तीन टाइप्ड आर्गुमेंट्स वाला search_orders टूल, एक ही फ़्री-टेक्स्ट फ़ील्ड वाले एक do_anything टूल से बेहतर है। टूल के नतीजे सिर्फ़ टेक्स्ट तक सीमित नहीं हैं: उनमें इमेज, ऑडियो या लिंक भी हो सकते हैं, और इसी वजह से मीडिया जेनरेटर इस प्रोटोकॉल में इतनी सहजता से फ़िट होते हैं। एक इमेज टूल Flux 2 Pro या Seedream 4.5 को रैप कर सकता है, और एक वीडियो टूल Veo 3.1 या Kling v3 Video को।
Resources URI से पहचाने जाने वाले सिर्फ़-पढ़ने वाले डेटा हैं, जैसे file:///reports/q3.md या postgres://db/customers/schema। किन्हें मॉडल के संदर्भ में जोड़ना है, यह होस्ट चुनता है, इसलिए resources दस्तावेज़ों, स्कीमा और लॉग के लिए सही हैं। क्लाइंट सब्सक्राइब करने के बाद सर्वर notifications/resources/updated के ज़रिए बदलावों की सूचना दे सकता है।
Prompts पैरामीटराइज़्ड मैसेज टेम्पलेट हैं, जिन्हें यूज़र जानबूझकर चुनता है, आमतौर पर स्लैश-कमांड मेनू से। review this pull request जैसा prompt तैयार मैसेजों की सूची लौटाता है, ताकि हर टीममेट एक ही शब्दों और एक ही चेकलिस्ट से शुरू करे।
ट्रैफ़िक दूसरी दिशा में भी बहता है। सर्वर sampling (होस्ट के मॉडल से कम्पलीशन माँगना), roots (पूछना कि कौन-सी डायरेक्टरी दायरे में हैं) और elicitation (यूज़र से छूटी हुई जानकारी माँगना) के ज़रिए क्लाइंट से मदद माँग सकते हैं। हर एक की अनुमति होस्ट तय करता है।
💡 मोटा नियम: अगर कार्रवाई दुनिया में कुछ बदलती है, तो tool बनाएँ। अगर वह सिर्फ़ जानकारी देती है, तो resource से शुरू करें।
ट्रांसपोर्ट तय करता है कि बाइट्स क्लाइंट और सर्वर के बीच कैसे जाएँ। मैसेज दोनों हालात में एक जैसे रहते हैं: JSON-RPC 2.0 रिक्वेस्ट, रिस्पॉन्स और नोटिफ़िकेशन। दो ट्रांसपोर्ट मानक हैं।
stdio: the host starts the server as a child process
┌────────┐ stdin: requests ┌───────────┐
│ Client │ ─────────────────────► │ Server │
│ │ ◄───────────────────── │ process │
└────────┘ stdout: responses └───────────┘
stderr: logs only
stdio में होस्ट सर्वर को चाइल्ड प्रोसेस के रूप में चलाता है और स्टैंडर्ड इनपुट और आउटपुट के ज़रिए न्यूलाइन-सेपरेटेड JSON-RPC मैसेज का आदान-प्रदान करता है। सेटअप बस एक कमांड-लाइन का है, लेटेंसी बहुत कम है और क्रेडेंशियल एनवायरनमेंट वेरिएबल्स से आते हैं। एक नियम कई पहली बार लिखने वालों को उलझा देता है: सर्वर को stdout पर प्रोटोकॉल मैसेज के अलावा कुछ भी प्रिंट नहीं करना चाहिए। लॉग stderr पर जाने चाहिए, नहीं तो स्ट्रीम बिगड़ जाती है और सेशन खत्म हो जाता है।
Streamable HTTP: one URL, many clients
┌──────────┐ POST /mcp ┌────────────┐
│ Client A │ ───────────────────► │ │
└──────────┘ ◄─────────────────── │ Server │
┌──────────┐ JSON or SSE reply │ (web app) │
│ Client B │ ───────────────────► │ │
└──────────┘ ◄─────────────────── └────────────┘
Streamable HTTP एक ही एंडपॉइंट से कई क्लाइंट्स को सेवा देता है। क्लाइंट हर मैसेज HTTP POST से भेजता है, और सर्वर या तो सादा JSON लौटाता है या कई मैसेज भेजने की ज़रूरत पड़ने पर Server-Sent Events स्ट्रीम खोलता है। सेशन आइडेंटिफ़ायर Mcp-Session-Id हेडर में जाता है। यह ट्रांसपोर्ट स्पेसिफ़िकेशन के 2025-03-26 रिवीज़न में पुराने HTTP plus SSE डिज़ाइन की जगह आया, और होस्टेड सर्वरों, मल्टी-यूज़र प्रोडक्ट्स और लोड बैलेंसर के पीछे चलने वाली किसी भी चीज़ के लिए यही सही चुनाव है। ऑथराइज़ेशन OAuth पर बना है, इसलिए सर्वर 401 लौटाकर क्लाइंट को अपने authorization server की ओर भेज सकता है। जो सर्वर अभी भी पुराना डिज़ाइन चलाते हैं, वे माइग्रेशन के दौरान दोनों एंडपॉइंट चलाकर कम्पैटिबल रह सकते हैं, लेकिन नया प्रोजेक्ट Streamable HTTP से ही शुरू होना चाहिए।
| सवाल | stdio | Streamable HTTP |
|---|---|---|
| सर्वर कहाँ चलता है? | उसी मशीन पर जहाँ होस्ट है | URL से पहुँचने वाली कहीं भी जगह |
| हर सर्वर पर यूज़र | एक | कई |
| क्रेडेंशियल | एनवायरनमेंट वेरिएबल्स | OAuth या HTTP हेडर |
| सबसे अच्छा किसके लिए | डेवलपर टूल्स, लोकल फ़ाइलें | होस्टेड प्रोडक्ट्स, साझा सेवाएँ |
| मुख्य दिक्कत | stdout पर भटका हुआ आउटपुट | प्रॉक्सी के पीछे सेशन हैंडलिंग |
एक व्यावहारिक बँटवारा: डेवलपर्स के लिए stdio बिल्ड दें, जो एक मिनट में सर्वर आज़माना चाहते हैं, और बाकी सबके लिए Streamable HTTP बिल्ड। टूल का कोड वही रहता है। सिर्फ़ एंट्री पॉइंट बदलता है।
यहाँ एक ही रिक्वेस्ट है, उस पल से लेकर जब यूज़र टाइप करता है, उस पल तक जब जवाब दिखता है।
User Host + LLM MCP client MCP server
│ │ │ │
├─ asks for image ───► │ │
│ │ picks a tool │ │
│ ├─ tool request ────► │
│ │ ├─ tools/call ──────►
│ │ │ │ does the work
│ │ ◄─ text, isError ───┤
│ ◄─ result ──────────┤ │
◄─ answer + URL ─────┤ │ │
│ │ │ │
हर सेशन initialize से शुरू होता है। क्लाइंट वह प्रोटोकॉल वर्ज़न भेजता है जिसे वह सपोर्ट करता है, साथ में अपनी क्षमताएँ। सर्वर वह वर्ज़न लौटाता है जो उसने चुना और जो क्षमताएँ वह देता है। फिर क्लाइंट notifications/initialized मैसेज भेजता है और सामान्य ट्रैफ़िक शुरू हो जाता है। अगर वर्ज़न मेल नहीं खाते, तो क्लाइंट अंदाज़ा लगाने के बजाय डिस्कनेक्ट हो जाता है।
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-06-18",
"capabilities": { "sampling": {} },
"clientInfo": { "name": "example-host", "version": "1.0.0" }
}
}
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"protocolVersion": "2025-06-18",
"capabilities": { "tools": { "listChanged": true } },
"serverInfo": { "name": "image-server", "version": "0.3.0" }
}
}
क्लाइंट tools/list भेजता है, होस्ट स्कीमा मॉडल को देता है, और मॉडल तय करता है कि किसी एक को कॉल करना है या नहीं। जब सर्वर की टूल लिस्ट रनटाइम पर बदलती है, तो वह क्लाइंट के रिफ़्रेश करने के लिए notifications/tools/list_changed भेजता है। कॉल कुछ ऐसी दिखती है:
{
"jsonrpc": "2.0",
"id": 7,
"method": "tools/call",
"params": {
"name": "generate_image",
"arguments": { "prompt": "A walnut desk with printed diagrams", "aspect_ratio": "16:9" }
}
}
जवाब में एक content ऐरे और एक isError फ़्लैग आता है:
{
"jsonrpc": "2.0",
"id": 7,
"result": {
"content": [{ "type": "text", "text": "Job accepted, check status in 5 seconds" }],
"isError": false
}
}
MCP दो तरह की विफलताओं को अलग करता है। प्रोटोकॉल एरर एक JSON-RPC एरर ऑब्जेक्ट है, जैसे अमान्य पैरामीटर या अज्ञात टूल नाम के लिए कोड -32602। टूल एक्ज़िक्यूशन एरर एक सामान्य नतीजा है, जिसमें isError: true और एक ऐसा मैसेज होता है जिसे मॉडल पढ़ सकता है। दूसरी तरह की विफलता सबसे ज़्यादा मायने रखती है। जब कोई टूल prompt too long लौटाता है, तो मॉडल prompt छोटा करके दोबारा कोशिश कर सकता है, लेकिन तभी जब एरर उस तक क्रैश हुए सेशन के बजाय टेक्स्ट के रूप में पहुँचे। कोई भी पक्ष धीमी रिक्वेस्ट छोड़ने के लिए notifications/cancelled भी भेज सकता है।
मॉडल के छूने से पहले सर्वर को MCP Inspector (npx @modelcontextprotocol/inspector) के तहत चलाएँ। Inspector टूल्स की लिस्ट दिखाता है, आपको हाथ से कॉल चलाने देता है और कच्चा JSON-RPC ट्रैफ़िक दिखाता है, ताकि आप प्रोटोकॉल के बग और प्रॉम्प्ट के बग अलग कर सकें।
प्रोडक्शन की ज़्यादातर परेशानियाँ इन्हीं तीन चुनावों तक जाती हैं:
do_anything नाम का टूल मॉडल को अंदाज़ा लगाने पर मजबूर करता है। इसे search_orders और refund_order जैसे संकीर्ण क्रिया-पदों में बाँटें, हर एक के टाइप्ड आर्गुमेंट्स के साथ।एक ठोस उदाहरण दिखाता है कि आर्किटेक्चर के चुनाव क्यों मायने रखते हैं। PicassoIA एक MCP कनेक्टर देता है, जिसके टूल्स अपने GPUs पर इमेज और वीडियो जनरेट और एडिट करते हैं। इमेज और वीडियो जॉब्स में सेकंड से लेकर मिनट लगते हैं, और इससे टूल कॉल करो, जवाब का इंतज़ार करो वाली सीधी तस्वीर टूट जाती है। होस्ट और SDK आमतौर पर रिक्वेस्ट टाइमआउट लागू करते हैं, इसलिए जो सर्वर रेंडर पूरा होने तक रुका रहता है, वह ठीक तब फ़ेल होगा जब काम लगभग पूरा हो चुका हो।
कनेक्टर generate_image, edit_image, generate_video_picassoia, generate_video_seedance, get_generation, cancel_generation, list_models, list_generations और get_account नाम के टूल्स दिखाता है। जनरेट कॉल तुरंत एक प्रेडिक्शन ID और अनुमानित समय लौटाती है। फिर मॉडल सुझाए गए इंतज़ार के बाद get_generation कॉल करता है, और हर नए संकेत के बाद फिर से, जब तक स्टेटस succeeded या failed न पढ़े। टूल कॉल छोटी रहती है, जबकि भारी काम GPU वर्कर पर बैकग्राउंड जॉब के रूप में चलता है।
Model MCP server GPU worker
│ │ │
├─ generate_image ─────► │
│ ├─ submit job ──────────►
◄─ id + wait hint ─────┤ │
│ │ │ rendering
├─ get_generation ─────► │
◄─ status: processing ─┤ │
├─ get_generation ─────► │
◄─ succeeded + URL ────┤ │
│ │ │
कनेक्टर के पीछे के मॉडल स्टिल्स के लिए PicassoIA Image और PicassoIA Image Editor Pro हैं, और ऑडियो वाले क्लिप्स के लिए PicassoIA Video और Seedance 2.5 Lite। नतीजे सादे URLs के रूप में लौटते हैं, इसलिए कोई भी होस्ट उन्हें दिखा सकता है।
GPU queue के सामने बैठा सर्वर उसकी रक्षा करने के लिए बना होना चाहिए। PicassoIA हर अकाउंट के लिए पाँच एक साथ चलने वाली प्रेडिक्शन की सीमा बताता है, जो API क्रेडेंशियल्स और MCP कनेक्शनों में साझा होती है। एक अच्छी तरह बना सर्वर ऐसी सीमा को साफ़ टूल नतीजे में बदल देता है, जैसे पाँच जॉब चल रहे हैं, 30 सेकंड बाद दोबारा कोशिश करें, बजाय इसके कि रिक्वेस्ट उसके पीछे जमा होती रहें। मॉडल यह मैसेज पढ़कर इंतज़ार कर सकता है, और यह टाइमआउट से कहीं बेहतर है।
एजेंट से एसिंक्रोनस सर्वर को आरामदेह तरीके से इस्तेमाल करने की चार आदतें:
MCP क्षमता को एक सिस्टम से दूसरे तक पहुँचाता है, इसलिए वह जोखिम भी साथ ले जाता है। प्रोटोकॉल बातचीत का ढाँचा तय करता है, लेकिन ज़िम्मेदारी होस्ट और सर्वर पर होती है। लॉन्च से पहले ये छह जाँचें ज़्यादातर समस्याएँ पकड़ लेती हैं:
डिप्लॉयमेंट भी इसी तर्क को मानता है। अपने टेस्ट में प्रोटोकॉल वर्ज़न पिन करें, CI में सर्वर को Inspector के तहत चलाएँ, और रिमोट सर्वरों को एक गेटवे के पीछे रखें जो TLS, रेट लिमिट और OAuth सँभाले, ताकि टूल का कोड टूल्स पर केंद्रित रहे।
डायग्राम ज़्यादा अच्छी तरह दिमाग में बैठते हैं, जब आप टूल कॉल को कुछ असली बनाते देख सकें। PicassoIA खोलें, अपनी डेस्क, सर्वर रूम या व्हाइटबोर्ड स्केच की फ़ोटो के लिए प्रॉम्प्ट लिखें, और उसे Seedream 4.5 या GPT Image 2 से जनरेट करें। फिर अपने पसंदीदा फ़्रेम को Veo 3.1 या Kling v3 Video से एनिमेट करें। अगर आपका होस्ट MCP कनेक्शन सपोर्ट करता है, तो PicassoIA कनेक्टर जोड़ें और अपने असिस्टेंट को जॉब चलाने दें, जबकि आप ऊपर डायग्राम के पोलिंग चरणों को देखते रहें।
तीन प्रॉम्प्ट आज़माएँ और हर बार एक चीज़ बदलें: कैमरे का कोण, रोशनी की दिशा या लेंस। फ़र्क दिखाता है कि सटीक प्रॉम्प्ट कितना मायने रखता है, उसी तरह जैसे सटीक टूल विवरण मॉडल के लिए मायने रखता है। सभी उपलब्ध मॉडल picassoia.com/en/all-models पर देखें और आज ही अपनी पहली जनरेशन शुरू करें।
अपनी भाषा चुनें
