एक MCP सर्वर को AWS Lambda, Azure और Cloud Run पर साथ-साथ डिप्लॉय करें

आपका MCP सर्वर आपके लैपटॉप पर stdio के ज़रिए ठीक चलता है। फिर कोई साथी एक URL माँगता है, जिसे वह क्लाइंट में पेस्ट कर सके, और असली काम शुरू हो जाता है। रिमोट सर्वर को HTTPS, ऑथेंटिकेशन, ऐसा ट्रांसपोर्ट चाहिए जो लोड बैलेंसर के पार भी चले, और ऐसा होस्ट जो तब बिल न करे जब कोई उसे कॉल न कर रहा हो। यह लेख एक छोटे TypeScript सर्वर को तीन प्लेटफ़ॉर्म पर चलाता है: AWS Lambda, Azure Functions और Google Cloud Run। आपको हर प्लेटफ़ॉर्म पर ज़रूरी कॉन्फ़िग मिलेगा, वह एक्सेस कंट्रोल मिलेगा जो अजनबियों को दूर रखता है, और एक सीधी तुलना मिलेगी ताकि आप एक हफ़्ते की जगह दस मिनट में होस्ट चुन सकें।

💡 स्कोप: नीचे के सभी स्निपेट Streamable HTTP ट्रांसपोर्ट मानकर चलते हैं। Stdio स्थानीय चाइल्ड प्रोसेस के लिए है, इसलिए जो सर्वर केवल stdio बोलता है, उसे इनमें से किसी भी होस्ट पर चलाने से पहले HTTP फ़्रंट एंड चाहिए।

क्लाउड से पहले ट्रांसपोर्ट चुनें

सर्वरलेस पर स्टेटलेस क्यों जीतता है

सर्वरलेस प्लेटफ़ॉर्म इंस्टेंस को जब चाहें शुरू और बंद करते रहते हैं। पहला रिक्वेस्ट इंस्टेंस A पर पहुँचता है, दूसरा इंस्टेंस B पर, और तीसरा इंस्टेंस C पर कोल्ड स्टार्ट ट्रिगर करता है। अगर आपका सर्वर सेशन को मेमोरी में रखता है, तो यह क्रम उसे तोड़ देगा।

इसका हल स्टेटलेस Streamable HTTP सर्वर है: एक /mcp एंडपॉइंट जो POST स्वीकार करता है, जवाब देता है और सब भूल जाता है। तीनों प्लेटफ़ॉर्म इसी ढाँचे पर बने हैं। Azure का सेल्फ-होस्टेड प्रीव्यू केवल streamable-http ट्रांसपोर्ट वाले स्टेटलेस सर्वर स्वीकार करता है। Cloud Run अपने दो रिमोट विकल्पों के रूप में SSE और Streamable HTTP का दस्तावेज़ीकरण करता है, और उसमें बिल्ट-इन HTTP रिस्पॉन्स स्ट्रीमिंग है। Lambda के सामने वेब एडॉप्टर लगाने पर वह भी यही व्यवहार करता है।

जुलाई 2026 स्पेक में क्या बदला

MCP स्पेसिफ़िकेशन के 2026-07-28 संशोधन ने भी इसी दिशा में कदम बढ़ाया:

• कोई प्रोटोकॉल-स्तर सेशन नहीं। Streamable HTTP से Mcp-Session-Id हेडर हटा दिया गया है।
• कोई हैंडशेक नहीं। initialize एक्सचेंज हटा दिया गया, और अब हर रिक्वेस्ट अपना प्रोटोकॉल वर्ज़न और क्लाइंट क्षमताएँ _meta में भेजती है।
• हैंडल के ज़रिए स्टेट। जिस सर्वर को कॉल्स के बीच मेमोरी चाहिए, वह एक स्पष्ट हैंडल बनाता है और उसे एक सामान्य टूल आर्गुमेंट के रूप में आगे भेजता है।
• स्ट्रीम रिज़्यूमेबिलिटी नहीं। टूटे हुए रिस्पॉन्स स्ट्रीम में चल रही रिक्वेस्ट खो जाती है, और क्लाइंट को उसे नई रिक्वेस्ट ID के साथ फिर से भेजना पड़ता है।
• HTTP+SSE अब डिप्रीकेटेड है। नए काम के लिए Streamable HTTP इस्तेमाल करना चाहिए।

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

एक सर्वर, तीन लक्ष्य

वह हैंडलर जो हर होस्ट साझा करता है

डेमो सर्वर दो टूल देता है जो PicassoIA डेवलपर API के सामने खड़े होते हैं: एक इमेज जॉब शुरू करता है, दूसरा उसकी स्थिति जाँचता है। यह API Replicate-style और एसिंक्रोनस है, इसका बेस URL https://api.picassoia.com/v1 है, यह Bearer ऑथेंटिकेशन इस्तेमाल करता है, जॉब शुरू करने के लिए POST /models/{owner}/{name}/predictions और उसे पढ़ने के लिए GET /predictions/{id} है। काम को शुरू करने और जाँचने में बाँटने से हर रिक्वेस्ट छोटी रहती है, और यह उन प्लेटफ़ॉर्म के लिए ठीक है जो मिलीसेकंड के हिसाब से बिल करते हैं। नीचे का जॉब PicassoIA Image को उसके picassoia/picassoia-image स्लग के ज़रिए निशाना बनाता है।

import express from "express";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
import { z } from "zod";

const API = "https://api.picassoia.com/v1";
const auth = { Authorization: `Bearer ${process.env.PICASSOIA_API_TOKEN}` };

function buildServer() {
  const server = new McpServer({ name: "image-tools", version: "1.0.0" });

  server.registerTool(
    "start_image",
    { description: "Start an image generation", inputSchema: { prompt: z.string().max(4000) } },
    async ({ prompt }) => {
      const res = await fetch(`${API}/models/picassoia/picassoia-image/predictions`, {
        method: "POST",
        headers: { ...auth, "Content-Type": "application/json" },
        body: JSON.stringify({ input: { prompt, aspect_ratio: "16:9" } }),
      });
      const job = await res.json();
      return { content: [{ type: "text", text: JSON.stringify({ id: job.id, status: job.status }) }] };
    }
  );

  server.registerTool(
    "get_image",
    { description: "Check a generation by id", inputSchema: { id: z.string() } },
    async ({ id }) => {
      const res = await fetch(`${API}/predictions/${id}`, { headers: auth });
      return { content: [{ type: "text", text: await res.text() }] };
    }
  );
  return server;
}

const app = express();
app.use(express.json());

app.post("/mcp", async (req, res) => {
  const server = buildServer();
  const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined });
  res.on("close", () => { transport.close(); server.close(); });
  await server.connect(transport);
  await transport.handleRequest(req, res, req.body);
});

app.get("/health", (_req, res) => res.send("ok"));
app.listen(Number(process.env.PORT ?? 8080), "0.0.0.0");

प्रॉम्प्ट कॉपी करें

हर रिक्वेस्ट के लिए नया सर्वर और नया ट्रांसपोर्ट बनाना SDK उदाहरणों वाला स्टेटलेस पैटर्न है, और इसकी लागत लगभग कुछ नहीं होती क्योंकि दो टूल रजिस्टर करना सस्ता है। मेथड के नाम SDK रिलीज़ के साथ बदलते हैं, इसलिए स्निपेट को अपने इंस्टॉल किए गए वर्ज़न से मिलाएँ, और रिक्वेस्ट व रिस्पॉन्स के फ़ील्ड PicassoIA API डॉक्स से मिलाकर जाँचें।

सीक्रेट्स इमेज के बाहर रहें

कंटेनर में कुछ भी संवेदनशील न डालें। PICASSOIA_API_TOKEN को प्लेटफ़ॉर्म के सीक्रेट स्टोर से पढ़ें: Lambda पर AWS Secrets Manager या SSM Parameter Store, Azure पर किसी मैनेज्ड वॉल्ट की ओर इशारा करने वाली ऐप सेटिंग, और Cloud Run पर Google Secret Manager।

💡 PicassoIA अकाउंट एक साथ 5 प्रेडिक्शन की अनुमति देते हैं, जो टोकन और MCP कनेक्शन में साझा होते हैं। अपने होस्ट का फ़ैन-आउट सीमित करें: Lambda पर reserved concurrency, Cloud Run पर --max-instances और --concurrency, या Azure पर अधिकतम इंस्टेंस संख्या। ऐसा करें ताकि सीमा प्रोडक्शन में पता न चले, बल्कि पहले से तय हो।

AWS Lambda पर डिप्लॉय करें

Lambda Web Adapter सेटअप

सबसे कम दखल वाला रास्ता आपके Express ऐप को Lambda Web Adapter के ज़रिए बिना बदले चलाता है। कंटेनर इमेज के लिए इसमें सिर्फ़ एक अतिरिक्त लाइन लगती है:

FROM public.ecr.aws/docker/library/node:22-slim
COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:1.1.0 /lambda-adapter /opt/extensions/lambda-adapter
ENV PORT=8080 AWS_LWA_INVOKE_MODE=response_stream AWS_LWA_READINESS_CHECK_PATH=/health
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY dist ./dist
CMD ["node", "dist/server.js"]

प्रॉम्प्ट कॉपी करें

ज़िप पैकेज पसंद हैं? एडॉप्टर लेयर जोड़ें, AWS_LAMBDA_EXEC_WRAPPER को /opt/bootstrap पर सेट करें और हैंडलर को एक स्टार्टअप स्क्रिप्ट की ओर इंगित करें। एडॉप्टर AWS_LWA_PORT से पोर्ट पढ़ता है (न मिलने पर PORT पर चला जाता है, डिफ़ॉल्ट 8080) और ट्रैफ़िक फ़ॉरवर्ड करने से पहले रेडीनेस पाथ की जाँच करता है।

Function URL और रिस्पॉन्स स्ट्रीमिंग

सामने एक Function URL लगाएँ और उसका invoke mode RESPONSE_STREAM पर सेट करें, जो ऊपर के एडॉप्टर वेरिएबल से मेल खाता है। डिफ़ॉल्ट बफ़र्ड मोड पूरा रिस्पॉन्स तब तक रोके रखता है जब तक टूल खत्म न हो, और इससे स्ट्रीमिंग बेकार हो जाती है। Lambda हर इनवोकेशन के लिए 15 मिनट तक और 10 GB तक मेमोरी देता है, जो शुरू-और-जाँच वाले टूल की ज़रूरत से कहीं ज़्यादा है।

एक्सेस के दो रास्ते हैं:

• AWS_IAM Function URL। कॉलर्स रिक्वेस्ट SigV4 से साइन करते हैं। सर्विस-टू-सर्विस ट्रैफ़िक के लिए अच्छा है, डेस्कटॉप MCP क्लाइंट्स के लिए अजीब।
• NONE और अपनी खुद की जाँच। सर्वर के अंदर OAuth चलाएँ या सामने authorizer लगाएँ। API Gateway के ज़रिए Cognito या Lambda authorizer आम चुनाव है, लेकिन उसका डिफ़ॉल्ट इंटीग्रेशन टाइमआउट लगभग 30 सेकंड है, इसलिए लंबे टूल कॉल के लिए Function URL बेहतर है।

Serverless Framework v4 इन सबको YAML की कुछ पंक्तियों से जोड़ सकता है:

mcp:
  servers:
    images:
      server: index.ts

प्रॉम्प्ट कॉपी करें

💡 उस पोस्ट में दो सावधानियाँ बताई गई हैं: इंटरैक्टिव OAuth लॉगिन के लिए रूट पर कस्टम डोमेन चाहिए, डिफ़ॉल्ट execute-api URL नहीं, और Cognito में डायनामिक क्लाइंट रजिस्ट्रेशन नहीं है।

Azure Functions पर डिप्लॉय करें

वह host.json जो मायने रखती है

Azure SDK से बने सर्वरों को custom handlers के रूप में चलाता है: Functions होस्ट रिक्वेस्ट लेता है और उसे आपकी प्रोसेस तक प्रॉक्सी करता है। Microsoft का सेल्फ-होस्टेड MCP दस्तावेज़ TypeScript सर्वर के लिए यह न्यूनतम फ़ाइल देता है, और Node quickstart इसे एक काम करने वाले प्रोजेक्ट में दिखाता है:

{
  "version": "2.0",
  "configurationProfile": "mcp-custom-handler",
  "customHandler": {
    "description": {
      "defaultExecutablePath": "npm",
      "arguments": ["run", "start"]
    },
    "port": "8080"
  }
}

प्रॉम्प्ट कॉपी करें

mcp-custom-handler प्रोफ़ाइल HTTP प्रॉक्सी चालू करती है, हर पाथ ({*route}) को आपके सर्वर तक रूट करती है और रूट प्रीफ़िक्स हटा देती है, ताकि /mcp बिना छेड़े पहुँचे। port वैल्यू को उस पोर्ट से मिलाएँ जिस पर आपका सर्वर सुनता है। F5 डीबगर अभी समर्थित नहीं है, इसलिए लोकली func start से टेस्ट करें, और फिर func azure functionapp publish <APP_NAME> से पब्लिश करें।

प्रीव्यू की सीमाएँ और Entra साइन-इन

फ़ैसला लेने से पहले बारीक शर्तें पढ़ लें: यह फ़ीचर पब्लिक प्रीव्यू में है। यह केवल स्टेटलेस streamable-http सर्वर सपोर्ट करता है, जो Python, TypeScript, C# या Java SDK से लिखे गए हों, और ऐप को Flex Consumption प्लान पर चलना होगा। अगर आपको स्टेट चाहिए, तो Microsoft आपको इसके बजाय Functions MCP एक्सटेंशन की ओर भेजता है। Flex Consumption कोल्ड स्टार्ट कम करने के लिए हमेशा तैयार रहने वाले इंस्टेंस रख सकता है, पर उसकी कीमत है खाली पड़ी क्षमता का भुगतान।

ऑथेंटिकेशन में Azure चमकता है। प्लेटफ़ॉर्म का बिल्ट-इन सर्वर ऑथेंटिकेशन आपके लिए MCP ऑथोराइज़ेशन आवश्यकताएँ लागू करता है: यह 401 चैलेंज जारी करता है, Protected Resource Metadata दस्तावेज़ प्रकाशित करता है और क्लाइंट्स को साइन-इन के लिए Microsoft Entra ID पर भेजता है। दस्तावेज़ों का विस्तारित host.json defaultAuthorizationLevel को anonymous पर सेट करता है और साइन-इन उस प्लेटफ़ॉर्म लेयर पर छोड़ देता है, इसलिए URL को कहीं सार्वजनिक करने से पहले इसे चालू करें।

Cloud Run पर डिप्लॉय करें

सोर्स से एक कमांड

Cloud Run को सबसे कम तामझाम चाहिए। फ़ोल्डर में Dockerfile या Node प्रोजेक्ट हो, तो:

gcloud run deploy mcp-images --source . --region us-central1 \
  --set-secrets PICASSOIA_API_TOKEN=picassoia-token:latest \
  --max-instances 3

प्रॉम्प्ट कॉपी करें

इमेज पहले से है? gcloud run deploy --image IMAGE_URL --port PORT काम कर देगा। Cloud Run PORT इंजेक्ट करता है, और सर्वर को 0.0.0.0 से बाइंड होना चाहिए, जो साझा हैंडलर पहले से करता है। Lambda सेक्शन के Dockerfile की एडॉप्टर लाइन यहाँ बस एक निष्क्रिय फ़ाइल है, इसलिए एक ही इमेज दोनों प्लेटफ़ॉर्म पर चल सकती है।

डिफ़ॉल्ट रूप से निजी

नए Cloud Run URL के हर रिक्वेस्ट पर Cloud Run Invoker (roles/run.invoker) IAM रोल चाहिए। लोकल क्लाइंट के लिए Google के दस्तावेज़ एक प्रॉक्सी की सलाह देते हैं जो आपकी पहचान इंजेक्ट करे:

gcloud run services proxy mcp-images --region us-central1 --port=3000

प्रॉम्प्ट कॉपी करें

फिर क्लाइंट को http://localhost:3000/mcp की ओर इंगित करें। ऑटोमेटेड कॉलर Authorization: Bearer <token> के रूप में OIDC ID टोकन भेज सकते हैं, जिसका audience सर्विस के run.app URL पर सेट हो। Cloud Run पर चलने वाले कॉलर्स के पास और विकल्प हैं, जिनमें sidecar, मानक सर्विस-टू-सर्विस ऑथेंटिकेशन या Cloud Service Mesh शामिल हैं। सार्वजनिक, उपभोक्ता-सामने वाले सर्वर को --allow-unauthenticated और अपने ऐप के अंदर OAuth चाहिए, और यह फ़ैसला जान-बूझकर लेना है, अपने आप नहीं।

वार्म इंस्टेंस और टाइमआउट

Cloud Run डिफ़ॉल्ट रूप से शून्य तक स्केल होता है। अगर कोल्ड स्टार्ट परेशान करे तो --min-instances 1 जोड़ें, और खाली इंस्टेंस के खर्च का बजट बनाएँ। --timeout के साथ रिक्वेस्ट 60 मिनट तक चल सकती हैं (डिफ़ॉल्ट 5 मिनट है), जो तीनों में सबसे लंबी सीमा है, और HTTP रिस्पॉन्स स्ट्रीमिंग के लिए किसी अतिरिक्त स्विच की ज़रूरत नहीं।

साथ-साथ तुलना

कौन सा होस्ट किस टीम के लिए ठीक है?

• पहले से AWS पर, और ट्रैफ़िक अचानक बढ़ता-घटता है: Lambda। आप हर रिक्वेस्ट का भुगतान करते हैं और निष्क्रिय रहने पर कुछ नहीं।
• Entra ID वाली Microsoft शॉप: Azure Functions। बिल्ट-इन ऑथेंटिकेशन आपको OAuth लेयर लिखने से बचाता है, बशर्ते एक प्रीव्यू फ़ीचर स्वीकार्य हो।
• लंबे टूल कॉल वाली छोटी टीम: Cloud Run। सबसे कम तामझाम और सबसे लंबा टाइमआउट।

अगर तय न कर पाएँ, तो पहले एक कंटेनर इमेज बनाएँ। वह Cloud Run पर जैसी है वैसी चलेगी, Adapter के ज़रिए Lambda पर चलेगी, और वही कोड Azure custom handler के पीछे भी चलेगा।

क्लाइंट्स से पहले एंडपॉइंट टेस्ट करें

npx @modelcontextprotocol/inspector के साथ MCP Inspector चलाएँ, Streamable HTTP चुनें, अपना /mcp URL पेस्ट करें और टूल्स की सूची देखें। फिर वह टेस्ट करें जिसे लोग छोड़ देते हैं: URL को बिना क्रेडेंशियल्स के कॉल करें।

curl -i -X POST "$URL/mcp" -H "Content-Type: application/json" -d '{}'

प्रॉम्प्ट कॉपी करें

401 या 403 का मतलब है कि सामने का दरवाज़ा टिका हुआ है। कोई भी दूसरा जवाब बताता है कि रिक्वेस्ट आपकी ऑथ जाँच पार कर गई, और उस कॉलर के अगले हर कदम का खर्च आपके अपस्ट्रीम अकाउंट पर पड़ेगा।

3 आम गलतियाँ

1. localhost पर बाइंड करना। 127.0.0.1 लैपटॉप पर चलता है, पर इनमें से हर प्लेटफ़ॉर्म के पीछे विफल हो जाता है। 0.0.0.0 पर बाइंड करें।
2. स्टेट को मेमोरी में रखना। प्रोसेस के भीतर रहने वाला काउंटर या कैश अगले कोल्ड स्टार्ट पर गायब हो जाता है। स्पष्ट हैंडल या बाहरी स्टोर इस्तेमाल करें।
3. स्ट्रीम को बफ़र करना। Lambda का डिफ़ॉल्ट invoke mode बफ़र्ड है, और बीच का कोई प्रॉक्सी भी यही कर सकता है। अगर प्रोग्रेस संदेश एक साथ ढेर में आएँ, तो बफ़र की तलाश करें।

PicassoIA के साथ ड्राफ़्ट बनाएँ और चित्र बनाएँ

वही प्लेटफ़ॉर्म जो आपके सर्वर को कुछ कॉल करने के लिए देता है, वह उसके आसपास का कोड भी लिख सकता है और उसके डॉक्स के लिए इमेज भी बना सकता है।

PicassoIA पर Claude Sonnet 5 इस्तेमाल करें

एक कोडिंग मॉडल आपको ऊपर के स्निपेट से ऐसे सर्वर तक ले जाता है जो आपके अपने टूल्स से मेल खाए। Claude Sonnet 5 मल्टी-स्टेप कोडिंग और टूल-यूज़ के काम सँभालता है और इमेज पढ़ता है, इसलिए किसी असफल डिप्लॉय का स्क्रीनशॉट सीधे रिक्वेस्ट में डाला जा सकता है।

1. PicassoIA पर Claude Sonnet 5 खोलें।
2. एक प्रॉम्प्ट पेस्ट करें जो ट्रांसपोर्ट, टूल्स और होस्ट का नाम ले, जैसे: "TypeScript में एक स्टेटलेस Streamable HTTP MCP सर्वर लिखें, जिसमें दो टूल हों, start_job और get_job, और जो Cloud Run के लिए तैयार हो।"
3. सिस्टम प्रॉम्प्ट एक बार भरें ताकि हर जवाब आपके नियमों का पालन करे: स्टेटलेस, 0.0.0.0 पर बाइंड, PORT पढ़ें, कोई इन-मेमोरी सेशन नहीं।
4. नीचे की तालिका देखकर ऐसा एफ़र्ट स्तर चुनें जो काम से मेल खाए।
5. max_tokens को एकल-फ़ाइल जवाबों के लिए डिफ़ॉल्ट 8,192 पर रखें, और अगर जवाब कट जाए तो एक बार में एक फ़ाइल माँगें।
6. लॉग स्क्रीनशॉट हो तो एक इमेज संलग्न करें। max_image_resolution सेटिंग डिफ़ॉल्ट रूप से 0.5 मेगापिक्सेल पर है और भेजने से पहले उसे छोटा कर देती है।

किसी मुश्किल ऑथ बग पर दूसरी राय के लिए वही प्रॉम्प्ट GPT 5.6 Sol पर चलाएँ और दोनों जवाब मिलाकर देखें।

अपनी इमेज बनाएँ

सर्वर लाइव होने के बाद उसे README हेडर, डायग्राम बैकग्राउंड और सोशल कार्ड चाहिए। PicassoIA Image एक सादे प्रॉम्प्ट को सेकंडों में तैयार तस्वीर में बदल देता है, इसमें 1:1 से 16:9 तक सात आस्पेक्ट रेशियो हैं, रिप्रोड्यूसिबल नतीजों के लिए लॉक करने योग्य सीड है, JPG, PNG या WebP आउटपुट है और हर रन में अधिकतम दो वेरिएशन। इसे अनलिमिटेड बताया गया है, हर इमेज पर कोई सीमा नहीं, इसलिए आप खुलकर दोहराव कर सकते हैं। जब कोई स्थिर तस्वीर गति माँगे, तो PicassoIA Video उसे एक छोटे क्लिप में बदल देता है।

यह प्रॉम्प्ट आज़माएँ: सूर्यास्त के समय एक शांत लॉफ़्ट ऑफ़िस, ओक डेस्क पर खुला लैपटॉप, नरम खिड़की की रोशनी, 35mm फ़ोटो, फ़िल्म ग्रेन। एक विवरण बदलें, सीड लॉक करें, फिर दोबारा बनाएँ और दोनों की तुलना करें। Picasso IA खोलें, अपना पहला प्रॉम्प्ट चलाएँ और देखें कि आपकी अगली इमेज कैसी दिखती है। हर मॉडल picassoia.com/en/all-models पर मौजूद है, इसलिए प्रयोग के लिए बहुत कुछ है।