MCP JSON-RPC के ऊपर एक client-server architecture पर काम करता है। एक MCP server एक छोटा program है जो एक standardized interface के माध्यम से tools, resources, और prompts का एक set expose करता है। एक MCP client — आम तौर पर Claude Desktop, Cursor, या Windsurf जैसा एक AI application — खोजता है कि server क्या प्रदान करता है और उन क्षमताओं को मॉडल के लिए उपलब्ध बनाता है। जब मॉडल एक tool का उपयोग करने का निर्णय लेता है, client server को एक JSON-RPC request भेजता है, परिणाम प्राप्त करता है, और इसे बातचीत में वापस feed करता है। transport layer flexible है: servers stdio (स्थानीय processes के लिए), server-sent events के साथ HTTP (remote services के लिए), या streamable HTTP (नवीनतम transport, request-response और streaming को एक एकल connection में combining) पर communicate कर सकते हैं।
एक MCP server बनाना deliberately सरल है। Python में, आप official mcp SDK का उपयोग कर सकते हैं और लगभग 20 lines code में एक working server प्राप्त कर सकते हैं — आप एक function को @server.tool() के साथ decorate करते हैं, इसे एक description और typed parameters देते हैं, और SDK JSON-RPC, schema generation, और transport handle करता है। TypeScript में, @modelcontextprotocol/sdk package उसी तरह काम करता है। server initialization पर अपनी क्षमताओं को declare करता है (इसके पास कौन से tools हैं, क्या यह resources या prompts का समर्थन करता है), और client negotiate करता है कि यह क्या उपयोग करना चाहता है। इसका अर्थ है कि आप छोटे शुरू कर सकते हैं — एक server जो बस आपकी कंपनी के आंतरिक API को wrap करता है — और incrementally क्षमताएँ जोड़ सकते हैं।
bespoke tool integrations पर MCP की वास्तविक शक्ति तब स्पष्ट हो जाती है जब आप उस combinatorial समस्या पर विचार करते हैं जिसे यह हल करता है। MCP से पहले, यदि आपके पास 10 AI applications और 10 tools थे, आपको 100 custom integrations की आवश्यकता थी। MCP के साथ, आपको 10 servers और 10 clients की आवश्यकता है — हर एक एक बार बनाया गया। यह बिल्कुल वही pattern है जिसने USB को सफल बनाया: interface को standardize करें, और ecosystem scales। व्यवहार में, इसका अर्थ है कि एक developer द्वारा बनाया गया एक Postgres MCP server Claude, Cursor, Zed, और किसी भी अन्य MCP-compatible client के साथ संशोधन के बिना काम करता है। MCP server ecosystem में पहले से ही databases, APIs, dev tools, और cloud services के लिए सैकड़ों community-built servers शामिल हैं।
कुछ महत्वपूर्ण nuances हैं जिन्हें practitioners को जानना चाहिए। पहला, MCP servers दो स्वादों में आते हैं: स्थानीय servers जो आपके machine पर चलते हैं (file access, स्थानीय databases, dev tools के लिए महान) और remote servers जो hosted services के रूप में चलते हैं (shared infrastructure, SaaS integrations के लिए बेहतर)। दूसरा, security एक real consideration है — एक MCP server के पास जो भी permissions इसे चलाने वाली process के पास हैं, इसलिए एक poorly scoped server संवेदनशील डेटा expose कर सकता है। प्रोटोकॉल में एक capability negotiation step शामिल है, लेकिन remote servers के लिए access control और authentication अभी भी विकसित हो रहे हैं। तीसरा, MCP tool use के समान नहीं है — यह एक transport और discovery layer है जो tool use के नीचे बैठती है। एक मॉडल जो tool calling का समर्थन करता है MCP के साथ काम कर सकता है, लेकिन MCP resource subscriptions (live-updating context) और prompt templates जैसी चीज़ों को भी handle करता है जो सरल function calls से परे जाती हैं।
Anthropic ने 2024 के अंत में MCP को open-source किया, और adoption remarkably तेज़ रहा है। 2025 की शुरुआत तक, यह Claude, Cursor, Windsurf, Zed, Sourcegraph, और कई अन्य द्वारा समर्थित था। specification विकसित होती रहती है — streamable HTTP transport का जोड़, remote servers के लिए OAuth-आधारित auth, और elicitation (servers को mid-flow उपयोगकर्ता से input माँगने देना) सभी 2025 में landed हुए। यदि आप एक custom tool integration बनाने और एक MCP server बनाने के बीच चुन रहे हैं, MCP route लगभग हमेशा जीतता है: आपको हर MCP client के साथ compatibility free मिलती है, और प्रोटोकॉल पर्याप्त सरल है कि migration लागत near zero है।