Redis के साथ MCP विकास को तेज़ करें: तेज़, लागत-प्रभावी समाधान

मॉडल कॉन्टेक्स्ट प्रोटोकॉल (MCP) AI मॉडल को बाहरी टूल्स और डेटा स्रोतों से जोड़ने का मानक तरीका तेजी से बन रहा है। जैसे-जैसे MCP अपनाना बढ़ता है, डेवलपर्स खोज रहे हैं कि मजबूत, प्रोडक्शन-रेडी MCP कार्यान्वयन बनाने के लिए केवल स्पेक का पालन करने से अधिक की आवश्यकता होती है: इसके लिए सही इंफ्रास्ट्रक्चर की आवश्यकता होती है। इस पोस्ट में, हम पता लगाएंगे कि Redis तीन अलग-अलग MCP उपयोग के मामलों को कैसे शक्ति प्रदान करता है: Vercel के SSE कार्यान्वयन में वितरित सर्वरलेस फ़ंक्शंस का समन्वय, लंबे समय तक चलने वाली स्ट्रीम के लिए इवेंट रिज्यूमेबिलिटी सक्षम करना, और Clerk के साथ सुरक्षित OAuth फ्लो प्रबंधित करना।

MCP ट्रांसपोर्ट को समझना

हमारे उदाहरणों में गोता लगाने से पहले, आइए संक्षेप में कवर करें कि MCP संचार को कैसे संभालता है। MCP दो ट्रांसपोर्ट्स का समर्थन करता है: स्थानीय सर्वर के लिए Stdio और दूरस्थ सर्वर के लिए स्ट्रीमेबल HTTP। अतीत में, दूरस्थ सर्वर के लिए एक SSE (सर्वर-सेंट इवेंट्स) ट्रांसपोर्ट भी था, जो अब डिप्रिकेटेड है।

SSE से स्ट्रीमेबल HTTP में परिवर्तन MCP द्वारा रियल-टाइम संचार को संभालने के तरीके में एक विकास को दर्शाता है, लेकिन कई मौजूदा कार्यान्वयन अभी भी SSE पैटर्न पर भरोसा करते हैं। आइए देखें कि Redis ने उस मॉडल में प्रमुख चुनौतियों में से एक को हल करने में कैसे मदद की।

उपयोग केस 1: Redis Pub/Sub के साथ SSE

जब Vercel CTO Malte ने अपना MCP हैंडलर बनाया, तो उन्हें एक क्लासिक सर्वरलेस चुनौती का सामना करना पड़ा: आप कई एंडपॉइंट्स के बीच कैसे समन्वय करते हैं जब प्रत्येक अनुरोध को एक अलग सर्वरलेस फ़ंक्शन द्वारा नियंत्रित किया जा सकता है?

SSE ट्रांसपोर्ट मॉडल में, दो महत्वपूर्ण एंडपॉइंट्स हैं: कनेक्शन बनाए रखने के लिए /sse और क्लाइंट मैसेजेस प्राप्त करने के लिए /message। यहां समस्या है: Vercel जैसे सर्वरलेस वातावरण में, ये एंडपॉइंट्स पूरी तरह से अलग-थलग हैं। वे मेमोरी साझा नहीं करते, और /message पर एक अनुरोध पूरी तरह से अलग फ़ंक्शन इंस्टेंस द्वारा नियंत्रित किया जा सकता है जो /sse को संभाल रहा है।

समाधान? Redis Pub/Sub। जैसा कि Malte ने X पर समझाया:

कार्यान्वयन एंडपॉइंट्स के बीच समन्वय के लिए Redis चैनलों का उपयोग करता है। जब एक क्लाइंट /message पर एक मैसेज भेजता है, तो वह एंडपॉइंट एक Redis चैनल पर प्रकाशित करता है जिसकी /sse एंडपॉइंट सदस्यता लेता है। /sse एंडपॉइंट अनुरोध को प्रोसेस करता है और प्रतिक्रिया को दूसरे चैनल के माध्यम से वापस प्रकाशित करता है जिसे /message सुन रहा है।

यह पैटर्न Redis को एक मैसेज बस में प्रभावी ढंग से बदल देता है जो अलग-थलग सर्वरलेस फ़ंक्शंस के बीच की खाई को पाटता है, जिससे वे ऐसा काम कर सकते हैं जैसे वे एक ही प्रक्रिया का हिस्सा हों। जबकि SSE अब स्ट्रीमेबल HTTP के पक्ष में डिप्रिकेटेड है (जिसका अर्थ है कि नए MCP कार्यान्वयन को आधुनिक ट्रांसपोर्ट का उपयोग करना चाहिए), यह अलग-थलग सर्वरलेस फ़ंक्शंस के बीच समन्वय के लिए Redis का उपयोग करने का एक उत्कृष्ट उदाहरण बना हुआ है।

उपयोग केस 2: रिज्यूमेबिलिटी के लिए इवेंट स्टोर

MCP के स्ट्रीमेबल HTTP ट्रांसपोर्ट की सबसे शक्तिशाली विशेषताओं में से एक इसका रिज्यूमेबिलिटी के लिए समर्थन है। यह सुविधा क्लाइंट्स को नेटवर्क रुकावटों के मामले में, जहां वे छोड़े गए थे, वहां से एक स्ट्रीम जारी रखने की अनुमति देती है। यह प्रोडक्शन एप्लिकेशन के लिए महत्वपूर्ण है जहां नेटवर्क रुकावटें अपरिहार्य हैं।

MCP स्ट्रीम को समझना

यह समझने के लिए कि रिज्यूमेबिलिटी क्यों मायने रखती है, हमें यह समझने की आवश्यकता है कि MCP स्ट्रीम में क्या होता है। कुछ ऑपरेशन, जैसे एक सरल टूल को कॉल करना, एकल प्रतिक्रिया लौटाते हैं। लेकिन टूल्स server.sendLoggingMessage जैसे मेथड्स का उपयोग करके निष्पादन के दौरान कई इवेंट्स भी लौटा सकते हैं। ये मल्टी-इवेंट स्ट्रीम हैं जहां रिज्यूमेबिलिटी महत्वपूर्ण हो जाती है। यदि एक क्लाइंट बीच में डिस्कनेक्ट हो जाता है, तो उसे शुरू से शुरू करने के बजाय वहीं से जारी रखने में सक्षम होना चाहिए जहां उसने छोड़ा था।

Redis के साथ EventStore लागू करना

MCP SDK एक EventStore इंटरफ़ेस को परिभाषित करता है जिसके लिए दो मेथड्स की आवश्यकता होती है: इवेंट्स जोड़ने के लिए storeEvent और एक विशिष्ट इवेंट ID से शुरू होने वाले इवेंट्स को पुनः प्राप्त करने के लिए replayEventsAfter। SDK में एक इन-मेमोरी कार्यान्वयन शामिल है, लेकिन प्रोडक्शन उपयोग के लिए, आपको लगातार स्टोरेज की आवश्यकता होती है।

यहां EventStore का एक Redis-आधारित कार्यान्वयन है:

import { Redis } from '@upstash/redis';
import { JSONRPCMessage } from '@modelcontextprotocol/sdk/types.js';
import { EventStore } from '@modelcontextprotocol/sdk/server/streamableHttp.js';

export class RedisEventStore implements EventStore {
  private redis: Redis;

  constructor(params: ConstructorParameters[0]) {
    this.redis = new Redis(params);
  }

  async storeEvent(streamId: string, message: JSONRPCMessage): Promise {
    const eventId = await this.redis.xadd(`stream:${streamId}`, '*', {
      message: JSON.stringify(message),
    });
    return eventId;
  }

  async replayEventsAfter(
    lastEventId: string,
    { send }: { send: (eventId: string, message: JSONRPCMessage) => Promise }
  ): Promise {
    if (!lastEventId) {
      return '';
    }
    const streamId = lastEventId.split('-')[0];
    if (!streamId) {
      return '';
    }
    let nextId = lastEventId;
    while (true) {
      const events = await this.redis.xrange(`stream:${streamId}`, `(${nextId}`, '+', 10);
      const eventEntries = Object.entries(events);
      if (eventEntries.length === 0) {
        break;
      }
      for (const [eventId, fields] of eventEntries) {
        if (fields && typeof fields === 'object' && 'message' in fields && typeof fields.message === 'string') {
          const message = JSON.parse(fields.message) as JSONRPCMessage;
          await send(eventId, message);
          nextId = eventId;
        }
      }
    }
    return streamId;
  }
}

यह कार्यान्वयन Redis Streams का उपयोग करता है, जो इस उपयोग के मामले के लिए एकदम सही हैं।

एक सीमा

एक महत्वपूर्ण चेतावनी के बारे में पता होना चाहिए: जब एक टूल कई इवेंट्स भेजता है, तो streamId को _GET_stream पर सेट किया जाता है, और यह स्थिर विभिन्न स्ट्रीम्स और उपयोगकर्ताओं में समान रहता है। इसका मतलब है कि यदि दो उपयोगकर्ता एक साथ एक ही टूल का उपयोग कर रहे हैं जो कई इवेंट्स भेजता है, तो उनके इवेंट्स एक ही स्ट्रीम में मिश्रित हो सकते हैं।

मैंने आधिकारिक रिपॉजिटरी पर इस बारे में एक इश्यू खोला है। संकल्प के आधार पर, हमें कार्यान्वयन को समायोजित करने की आवश्यकता हो सकती है, और यदि आवश्यक हो तो मैं इस पोस्ट को तदनुसार अपडेट करूंगा।

उपयोग केस 3: Clerk का MCP OAuth कार्यान्वयन

MCP स्पेसिफिकेशन में प्रमाणीकरण और प्राधिकरण के लिए समर्थन शामिल है, जिससे MCP सर्वर सुरक्षित रूप से क्लाइंट्स को प्रमाणित कर सकते हैं और संसाधनों तक पहुंच को नियंत्रित कर सकते हैं। स्पेक कई प्रमाणीकरण योजनाओं का समर्थन करता है, जिसमें OAuth 2.0 शामिल है, जो मौजूदा पहचान प्रदाताओं के साथ एकीकरण और टूल्स और डेटा के लिए उपयोगकर्ता-स्कोप्ड एक्सेस को सक्षम करने के लिए विशेष रूप से उपयोगी है।

Clerk ने MCP SDK से OAuthClientProvider इंटरफ़ेस को लागू करके MCP के लिए एक व्यापक OAuth क्लाइंट बनाया है। उनका कार्यान्वयन MCP एप्लिकेशन में Redis के लिए एक और महत्वपूर्ण उपयोग केस प्रदर्शित करता है। यदि आप उनके MCP टूल्स के साथ शुरुआत करना चाहते हैं, तो उनके डेमो रिपॉजिटरी को देखें जो एक बेहतरीन शुरुआती बिंदु प्रदान करता है।

OAuth के लिए स्टोरेज क्यों मायने रखता है

जैसा कि Clerk अपने mcp-tools रिपॉजिटरी में बताते हैं, लगातार स्टोरेज MCP OAuth कार्यान्वयन के लिए दो प्रमुख कारणों से आवश्यक है:

1. OAuth फ्लो कई एंडपॉइंट्स तक फैला हुआ है - इनिशियलाइज़ेशन, OAuth कॉलबैक, और MCP अनुरोध सभी अलग-अलग सर्वरलेस फ़ंक्शंस द्वारा बिना साझा मेमोरी के संभाले जा सकते हैं
2. MCP कनेक्शन लंबे समय तक चलने वाले हैं - इन-मेमोरी स्टोरेज पर भरोसा करने से एप्लिकेशन के स्केल के रूप में मेमोरी आवश्यकताएं बढ़ जाएंगी, और कोई भी सर्वर रीस्टार्ट सभी सत्रों को अमान्य कर देगा

Redis में क्या स्टोर किया जाता है

Clerk का Redis स्टोर तीन प्रकार के डेटा का प्रबंधन करता है, प्रत्येक का OAuth फ्लो में एक विशिष्ट उद्देश्य:

PKCE वेरिफायर्स (pkce_verifier_<...>) ये OAuth फ्लो शुरू करते समय स्टोर किए जाते हैं और उपयोगकर्ता द्वारा एक्सेस देने के बाद फिर से पढ़े जाते हैं। ये PKCE (प्रूफ की फॉर कोड एक्सचेंज) फ्लो का हिस्सा हैं, जो यह सुनिश्चित करके OAuth में सार्वजनिक क्लाइंट्स के लिए अतिरिक्त सुरक्षा प्रदान करता है कि फ्लो शुरू करने वाला एप्लिकेशन वही है जो इसे पूरा कर रहा है (RFC 7636 में परिभाषित)।

{ "value": "XoYQ...", "created_at": "2025-10-03T06:27:06.928Z", "updated_at": "2025-10-03T06:27:06.928Z" }

सत्र डेटा (session_<...>) यह एक MCP सत्र के लिए सभी कॉन्फ़िगरेशन और स्थिति को संग्रहीत करता है। प्रारंभ में, इसमें MCP एंडपॉइंट, OAuth कॉन्फ़िगरेशन, और क्लाइंट क्रेडेंशियल्स होते हैं। उपयोगकर्ता द्वारा एक्सेस देने के बाद, इसे एक्सेस और रिफ्रेश टोकन के साथ अपडेट किया जाता है। अंत में, फ्लो समाप्त होने पर एक authComplete फ्लैग जोड़ा जाता है।

{ "value": { "mcpEndpoint": "https://localhost:3001/mcp", "oauthRedirectUrl": "https://localhost:3000/oauth_callback", "oauthScopes": "openid profile email", "mcpClientName": "Clerk MCP Demo", "mcpClientVersion": "0.0.1", "oauthClientUri": "https://example.com", "oauthPublicClient": false, "clientId": "8Yb2...", "clientSecret": "64YG..." }, "created_at": "2025-10-03T06:27:06.882Z", "updated_at": "2025-10-03T06:27:06.882Z" }

स्टेट पैरामीटर्स (state_<...>) ये OAuth स्टेट पैरामीटर्स को सत्र IDs पर मैप करते हैं, जिससे स्टेट ID का उपयोग करके सत्र डेटा प्राप्त करना संभव होता है:

{ "value": "dX61...", "created_at": "2025-10-03T06:27:03.585Z", "updated_at": "2025-10-03T06:27:03.585Z" }

यह आर्किटेक्चर OAuth फ्लो को वितरित सर्वरलेस फ़ंक्शंस में निर्बाध रूप से काम करने की अनुमति देता है जबकि सुरक्षा और सत्र अखंडता को बनाए रखता है।

Redis MCP के लिए एकदम सही क्यों है

सभी तीन उदाहरणों में, हम सामान्य पैटर्न देखते हैं जो Redis को MCP इंफ्रास्ट्रक्चर के लिए एक आदर्श विकल्प बनाते हैं:

कम विलंबता: MCP ऑपरेशंस को अक्सर तेज होने की आवश्यकता होती है। Redis की इन-मेमोरी आर्किटेक्चर रियल-टाइम AI इंटरैक्शन के लिए आवश्यक प्रतिक्रिया समय प्रदान करती है।

Pub/Sub क्षमताएं: जैसा कि हमने Vercel के कार्यान्वयन के साथ देखा, Redis Pub/Sub एक पूर्ण मैसेज क्यू की जटिलता के बिना वितरित घटकों के बीच सुंदर समन्वय को सक्षम करता है।

समृद्ध डेटा संरचनाएं: इवेंट स्ट्रीम के लिए Streams, सत्र डेटा के लिए Hashes, और स्टेट के लिए सरल की-वैल्यू पेयर्स। Redis प्रत्येक उपयोग के मामले के लिए सही डेटा संरचना प्रदान करता है।

अंतर्निहित समाप्ति: TTLs के माध्यम से स्वचालित सफाई। OAuth टोकन, इवेंट स्ट्रीम, और सत्र डेटा सभी मैन्युअल गार्बेज कलेक्शन के बिना स्वचालित रूप से समाप्त हो सकते हैं।

सर्वरलेस-अनुकूल: Upstash Redis जैसे समाधानों के साथ, आपको एक पूरी तरह से प्रबंधित, सर्वरलेस Redis मिलता है जो उपयोग में न होने पर शून्य तक स्केल करता है। परिवर्तनीय वर्कलोड वाले MCP कार्यान्वयन के लिए बिल्कुल सही।

MCP स्पेक फीचर्स से परे: व्यापक AI पारिस्थितिकी तंत्र में Redis

जबकि हमने MCP स्पेसिफिकेशन में स्पष्ट रूप से परिभाषित फीचर्स पर ध्यान केंद्रित किया है, Redis की उपयोगिता AI को शक्ति देने के मामले में उन पैटर्न से कहीं आगे तक फैली हुई है जिनका हमने पता लगाया है। हमारे हालिया ब्लॉग पोस्ट इनमें से कई पैटर्न दिखाते हैं:

• AI SDK एकीकरण - Redis का उपयोग करके Vercel AI SDK को बढ़ाना
• चैट इतिहास - मैसेजिंग इतिहास को स्थायी करना

हमारे अपने उदाहरणों से परे, समुदाय ने AI एप्लिकेशन के लिए प्रभावशाली Redis-संचालित टूल्स बनाए हैं। Midday का ai-sdk-tools सूट एक टूल परिणाम कैशिंग पैकेज शामिल करता है जो AI SDK टूल परिणामों को कैश करने के लिए Redis का उपयोग करता है, जैसा कि इस उदाहरण में दिखाया गया है, नाटकीय रूप से प्रदर्शन में सुधार और लागत कम करता है:

चाहे आप MCP सर्वर, AI एजेंट, या पूर्ण AI एप्लिकेशन बना रहे हों, Redis वह इंफ्रास्ट्रक्चर लेयर प्रदान करता है जो आपके सिस्टम को प्रोडक्शन-रेडी, स्केलेबल, और प्रदर्शनकारी बनाता है।

निष्कर्ष

मॉडल कॉन्टेक्स्ट प्रोटोकॉल अभी युवा है, लेकिन यह AI एप्लिकेशन के लिए आवश्यक इंफ्रास्ट्रक्चर तेजी से बन रहा है। जैसा कि हमने इन तीन उदाहरणों के माध्यम से देखा है, Redis MCP कार्यान्वयन को मजबूत और प्रोडक्शन-रेडी बनाने में महत्वपूर्ण भूमिका निभाता है:

• गति और लचीलापन: इसकी गति, लचीलेपन, और सर्वरलेस-अनुकूल आर्किटेक्चर का संयोजन
• लागत में कमी: कैशिंग क्षमताएं जो महंगे API कॉल और गणनाओं को कम करती हैं

यदि आप MCP के साथ निर्माण कर रहे हैं, चाहे सर्वर या क्लाइंट साइड पर, Redis को अपने टूलकिट में MCP-संचालित AI एप्लिकेशन के लिए सही साथी के रूप में होना चाहिए। Upstash Redis के साथ, आप आज विश्व स्तर पर उपलब्ध, सर्वरलेस Redis के साथ सेकंड में शुरू कर सकते हैं जो उपयोग में न होने पर शून्य तक स्केल करता है।