MCP سرورز کی وضاحت: AWS EC2 پر ڈیپلوئی کر کے جو میں نے سیکھا

MCP سے متعلق زیادہ تر مواد نظریاتی ہوتا ہے — ایک کلائنٹ کے سرور سے بات کرنے کے ڈایاگرام، USB-C سے تشبیہ، پانچ لائنوں کا “hello world” جو localhost پر چلتا ہے اور کبھی آپ کے لیپ ٹاپ سے باہر نہیں جاتا۔ اس میں سے کچھ بھی آپ کو اصل کام کے لیے تیار نہیں کرتا: ایک ایسا ٹول جسے آپ نے لوکل طور پر بنایا ہو، اسے ایک حقیقی سرور پر لے جانا، ایک حقیقی reverse proxy کے پیچھے رکھنا، اور اسے public internet پر ایک حقیقی کلائنٹ کے لیے قابلِ رسائی بنانا۔ یہ ایک مختلف مسئلہ ہے، اور یہی وہ چیز ہے جس پر کوئی لکھتا نہیں۔

میں نے ایک ایسا سرور ڈیپلوئی کیا۔ ایک local MCP server، جسے EC2 instance پر منتقل کیا گیا، streamable HTTP transport پر serve کیا گیا، اور اس کے سامنے nginx کے ذریعے bearer-token auth لگائی گئی۔ یہ کام کر گیا۔ پھر تقریباً اسی وقت جب میں اس setup پر مطمئن ہوا، پروٹوکول خود اس کے نیچے بدل گیا — MCP specification کی لانچ کے بعد سب سے بڑی revision 28 جولائی 2026 کو release candidate سے final بنی، اور اس نے پروٹوکول کے بنیادی حصے کو stateless بنانے کے لیے دوبارہ لکھ دیا۔ زیادہ تر لوگ “MCP support شامل کریں” کو فہرست میں ایک ہی نشان سمجھتے ہیں۔ ایسا نہیں ہے۔ یہ transport کا فیصلہ ہے، auth کا فیصلہ ہے، اور اب — اس spec update کے ساتھ — scaling کا بھی فیصلہ ہے، اور ان میں سے کسی ایک میں بھی غلطی، ڈیمو میں کام کرنے والے ٹول اور production میں قابلِ اعتماد ٹول کے درمیان فرق پیدا کر دیتی ہے۔

آپ یہ سیکھیں گے:

• MCP دراصل کس چیز کو standardize کرتا ہے، اور کس چیز کو جان بوجھ کر آپ پر چھوڑ دیتا ہے
• streamable HTTP transport کیسے کام کرتی ہے اور کیوں اس نے پرانے SSE-based approach کی جگہ لی
• میں نے EC2 پر ایک local MCP server کو nginx اور bearer-token auth کے ساتھ کیسے expose کیا
• 28 جولائی 2026 کی stateless rewrite پروٹوکول کی سطح پر کیا تبدیل کرتی ہے
• کیوں ایک static bearer token “auth موجود ہے” کی حد تو پوری کرتا ہے مگر “spec-compliant auth” کی نہیں
• update کے ساتھ ہم آہنگ رہنے کے لیے مجھے اپنی deployment میں حقیقتاً کیا تبدیل کرنا پڑا

فہرستِ مضامین

1. بنیادی باتیں
2. مکمل آرکیٹیکچر
3. بنیادی تہوں کی وضاحت
4. ابتدا سے انتہا تک واک تھرو
5. خصوصی صورتیں
6. Scaling اور Production چیلنجز
7. کوڈ مثالیں
8. عام غلطیاں
9. Production کی بہترین عملی تدابیر

بنیادی باتیں

MCP دراصل کس چیز کا احاطہ کرتا ہے

Model Context Protocol ایک مخصوص چیز کو standardize کرتا ہے: ایک AI application کس طرح ٹولز کو دریافت کرتی ہے اور انہیں کال کرتی ہے، اور ایک الگ server process کے ذریعے expose کیے گئے resources کو پڑھتی ہے — ایک متعین message format (JSON-RPC) کو ایک متعین transport کے اوپر استعمال کرتے ہوئے۔ یہ آپ کو نہیں بتاتا کہ اپنی tool logic کیسے لکھنی ہے، اپنا agent کیسے design کرنا ہے، یا کسی چیز کو کیسے deploy کرنا ہے۔ یہ ایک connection standard ہے، framework نہیں۔ اس کے آنے سے پہلے، ہر AI application جو مثلاً آپ کے internal API سے بات کرنا چاہتی تھی، اسے ایک custom، one-off integration درکار ہوتی تھی۔ MCP کا مطلب ہے کہ آپ server ایک بار بناتے ہیں اور پھر کوئی بھی compliant client اس سے بات کر سکتا ہے۔

یہ تناظر اس لیے اہم ہے کیونکہ یہی وجہ ہے کہ deployment مشکل حصہ بنتا ہے۔ پروٹوکول آپ کو صرف یہ معاہدہ دیتا ہے کہ messages کی ساخت کیسی ہوگی — یہ کچھ نہیں کہتا کہ آپ کا server صرف آپ کے لیپ ٹاپ سے قابلِ رسائی ہے یا internet سے، یہ کسی تحفظ کے پیچھے ہے یا نہیں، یا یہ ایک وقت میں ایک سے زیادہ clients کو سنبھال بھی سکتا ہے یا نہیں۔ یہ سب آپ کی ذمہ داری ہے۔

Deployment کی تفصیلات اتنا اہم مسئلہ کیوں ہیں

• لوکل طور پر چلنے والے MCP server کی کوئی حقیقی attack surface نہیں ہوتی۔ عوامی طور پر ڈیپلوئی شدہ سرور کی ہوتی ہے۔ جیسے ہی آپ کے server کے پاس public URL آتا ہے، وہ کسی بھی دوسرے authenticated API کی طرح بن جاتا ہے، اور اس کے ساتھ token handling اور input validation کے تمام تقاضے بھی آ جاتے ہیں۔
• پرانے spec کے تحت session اور scaling کا رویہ واضح نہیں تھا۔ یہاں غلطی کا مطلب یا تو ایسا server تھا جو concurrent load میں خاموشی سے ٹوٹ جاتا، یا ایسا حد سے زیادہ پیچیدہ نظام جس میں sticky sessions شامل کر دی جاتیں حالانکہ ان کی ضرورت نہ ہوتی۔
• پروٹوکول خود اب بھی بدل رہا ہے۔ چھ ماہ پرانی assumptions پر بنی deployment بظاہر بغیر کسی error کے quietly spec-compliant رہنا چھوڑ سکتی ہے — پھر clients سیدھا fail ہونے کے بجائے کسی پرانے protocol version پر negotiate کرنا شروع کر دیتے ہیں۔

مکمل آرکیٹیکچر

AI Client ── HTTPS POST ──▶ nginx (TLS termination, auth check, reverse proxy)
                                    │
                                    ▼
                          MCP Server Process
                          (Streamable HTTP transport)
                                    │
                       ┌────────────┴────────────┐
                    Tools                    Resources

بنیادی اصول یہ ہے: جیسے ہی آپ کے MCP server کے پاس public URL آ جائے، اسے بالکل اسی طرح treat کریں جیسے آپ EC2 سے expose کیے گئے کسی بھی authenticated API کو کرتے ہیں — کیونکہ ساختی طور پر یہی حقیقت ہے۔ “MCP” والا حصہ صرف اوپر چلنے والا message format ہے؛ اس کے نیچے security اور scaling کے تقاضے وہی ہیں جو آپ کسی بھی backend service پر لاگو کرتے ہیں۔

بنیادی تہوں کی وضاحت

1. Transport: Streamable HTTP

یہ کیا ہے: ایک واحد HTTP endpoint جو JSON-RPC messages لے کر آنے والی POST requests قبول کرتا ہے۔ اس نے پہلے والے HTTP+SSE transport کی جگہ لی، جو باقاعدہ HTTP calls کے ساتھ ایک persistent server-sent-events stream پر انحصار کرتا تھا۔

یہ کیوں اہم ہے: ایک واحد POST endpoint ایسی چیز ہے جسے ہر reverse proxy، load balancer، اور API gateway پہلے ہی سنبھالنا جانتا ہے۔ آپ کو nginx یا ALB کے ذریعے ایک long-lived stream کو زندہ رکھنے کے لیے اپنے infrastructure سے لڑنا نہیں پڑتا — یہ ایک عام HTTP API کی طرح برتاؤ کرتی ہے۔

location /mcp {
    proxy_pass http://127.0.0.1:8000;
    proxy_set_header Host $host;
    proxy_set_header Authorization $http_authorization;
    proxy_http_version 1.1;
    proxy_read_timeout 300s;
}

Production tip: ایک single-endpoint transport ہونے کے باوجود، اپنے proxy read timeout کو فراخ رکھیں۔ انفرادی tool calls واقعی ایک عام API request سے زیادہ وقت لے سکتی ہیں، اور بہت سخت timeout صرف hung connections ہی نہیں بلکہ جائز long-running calls کو بھی ختم کر دے گی۔

2. Authentication: Bearer Tokens (ابتدائی نقطہ، منزل نہیں)

یہ کیا ہے: Authorization header میں ایک static token، جسے اس سے پہلے check کیا جاتا ہے کہ request کو MCP server process تک پہنچنے دیا جائے — چاہے nginx layer پر یا application middleware میں۔

یہ کیوں اہم ہے: public URL رکھنے والی کسی بھی چیز کے لیے یہ کم از کم قابلِ عمل security ہے، اور میں نے بھی اسی سے آغاز کیا۔ لیکن static bearer token میں expiry semantics نہیں ہوتیں، یہ کسی مخصوص server سے bound نہیں ہوتا، اور اگر کہیں log میں leak ہو جائے تو اس کے لیے کوئی تحفظ نہیں ہوتا۔ یہ صرف اس سوال کا جواب دیتا ہے کہ “کیا یہ request سرے سے authenticated ہے؟"، اس سے زیادہ نہیں۔

from fastapi import Request, HTTPException

VALID_TOKEN = "your-rotated-secret-token"

async def verify_bearer(request: Request):
    auth = request.headers.get("authorization", "")
    if auth != f"Bearer {VALID_TOKEN}":
        raise HTTPException(status_code=401, detail="Unauthorized")

Production tip: raw Authorization header کو کبھی بھی اپنے access logs تک نہ پہنچنے دیں۔ default nginx یا app log format میں اسے miss کرنا بہت آسان ہے، اور پھر ایک log file credentials leak میں بدل جاتی ہے۔

3. Statelessness — جولائی 2026 کی Rewrite کا بنیادی نکتہ

یہ کیا ہے: 2026-07-28 specification پروٹوکول کی سطح پر sessions کو مکمل طور پر ختم کر دیتی ہے۔ اب Mcp-Session-Id header نہیں رہا، اور transport اس پرانے GET stream endpoint کو بھی چھوڑ دیتی ہے جسے پہلے کے versions client اور server کو گفتگو کے دوران sync میں رکھنے کے لیے استعمال کرتے تھے۔ اب ہر request خود میں مکمل ہے۔

یہ کیوں اہم ہے: پرانے ماڈل میں server کو اکثر calls کے درمیان client کے بارے میں کچھ نہ کچھ یاد رکھنا پڑتا تھا، اور یہی وہ state ہے جو جیسے ہی آپ کے پاس load balancer کے پیچھے ایک سے زیادہ server instances آتے ہیں، آپ کو sticky sessions پر مجبور کر دیتی ہے۔ پروٹوکول کی سطح پر statelessness کا مطلب ہے کہ کوئی بھی instance درست طور پر کوئی بھی request handle کر سکتا ہے — یعنی حقیقی horizontal scaling، بغیر client کو کسی ایک مخصوص box سے باندھے۔

Production tip: اگر آپ کا server calls کے درمیان client کے بارے میں کچھ بھی یاد رکھنے کے لیے in-memory state پر انحصار کر رہا تھا، تو یہ pattern نئے spec کے تحت ٹوٹ جائے گا۔ جو بھی state اہم ہو، اسے خود request payload میں ڈالیں یا Redis جیسے external store میں منتقل کریں جسے ہر instance پڑھ سکے۔

4. Multi Round-Trip Requests (کال کے دوران صارف سے کچھ پوچھنا)

یہ کیا ہے: ایک stateless protocol کو پھر بھی ایسا طریقہ چاہیے ہوتا ہے جس سے server tool call کے درمیان client سے input مانگ سکے — مثلاً confirmation یا کوئی missing parameter۔ نیا spec اس کے لیے Multi Round-Trip Requests استعمال کرتا ہے: stream کھلی رکھنے کے بجائے، server ایک InputRequiredResult واپس کرتا ہے جس میں سوالات اور ایک opaque requestState blob شامل ہوتا ہے۔ پھر client جوابات جمع کرتا ہے اور اصل call کو دوبارہ جاری کرتا ہے، اس بار جوابات اور وہی echoed state ساتھ لگا کر۔

یہ کیوں اہم ہے: یہی وہ حصہ ہے جو حقیقی statelessness کو قابلِ عمل بناتا ہے۔ چونکہ server کو resume کرنے کے لیے درکار تمام چیزیں اس payload میں موجود ہوتی ہیں جو client واپس بھیجتا ہے، اس لیے کوئی بھی server instance — ضروری نہیں کہ وہی جس نے call شروع کی تھی — retry اٹھا کر مکمل کر سکتا ہے۔

Production tip: client side پر requestState کو opaque ہی سمجھیں۔ اسے inspect یا modify نہ کریں — بس اسے store کریں اور بالکل ویسا ہی واپس echo کر دیں جیسا ملا تھا، ورنہ آپ ایسے resume کو توڑ سکتے ہیں جو اسی کی سالمیت پر منحصر ہو۔

5. Authorization Hardening: OAuth 2.1, PKCE, اور Resource Indicators

یہ کیا ہے: updated spec remote MCP servers کو authorization کے لیے OAuth 2.1 with PKCE کی طرف لے جاتی ہے، اور resource indicators (RFC 8707 کے مطابق) لازمی کرتی ہے جو جاری کردہ token کو اس مخصوص server سے bind کرتے ہیں جس کے لیے وہ جاری کیا گیا تھا۔

یہ کیوں اہم ہے: اگر static bearer token کبھی leak ہو جائے تو اسے کسی بھی ایسے server کے خلاف replay کیا جا سکتا ہے جو اسے قبول کر لے۔ token کو ایک مخصوص resource سے bind کرنا عین اسی خلا کو بند کرتا ہے — ایک MCP server کے لیے جاری کیا گیا token اب کسی دوسرے سرور کے خلاف قابلِ استعمال نہیں رہتا، چاہے دونوں ایک ہی identity provider پر trust کرتے ہوں۔

Production tip: ایک bearer-token setup، جیسے کہ ہم میں سے اکثر نے ابتدا میں استعمال کیا، “اس endpoint پر authentication درکار ہے” کی شرط تو پوری کرتا ہے۔ لیکن یہ interoperability اور replay-protection کی اس سطح کو پورا نہیں کرتا جو نیا spec ایک درست compliant remote server کے لیے طے کرتا ہے، اور یہ خلا اس سے پہلے پُر کرنا بہتر ہے کہ آپ URL اپنی ٹیم سے باہر کسی کو دیں۔

6. Deprecation Policy اور Extensions Framework

یہ کیا ہے: اب spec capabilities کو ایک باضابطہ Active → Deprecated → Removed lifecycle کے ذریعے آگے بڑھاتی ہے، جس میں deprecation اور removal کے درمیان کم از کم بارہ ماہ کا وقفہ ہوتا ہے۔ نئی capabilities — جیسے server-rendered UI یا long-running task support — پروٹوکول کے core میں براہِ راست شامل ہونے کے بجائے پہلے opt-in Extensions کے طور پر آتی ہیں۔ چند پرانی capabilities، جن میں roots، sampling، اور logging اپنی اصل شکل میں شامل ہیں، اب اپنی replacements کے حق میں اسی deprecation راستے سے گزر رہی ہیں۔

یہ کیوں اہم ہے: اس کا مطلب ہے کہ ایک کام کرتی ہوئی integration کسی آئندہ revision سے راتوں رات نہیں ٹوٹے گی، اور آپ نئی capabilities کو سوچ سمجھ کر اپنا سکتے ہیں بجائے اس کے کہ spec جو کچھ بھی شامل کرے اس کے ساتھ فوراً pace ملانا پڑے۔

ابتدا سے انتہا تک واک تھرو

ایک local prototype سے spec-current EC2 deployment تک اصل راستے کو trace کریں:

1. Local testing۔ MCP server ایک local client کے ساتھ stdio پر چلتا ہے — نہ network، نہ auth، اور iteration تیز۔
2. streamable HTTP پر منتقلی۔ server کو stdio کے بجائے streamable HTTP transport serve کرنے کے لیے reconfigure کیا جاتا ہے، اور پھر EC2 instance پر deploy کر دیا جاتا ہے۔
3. سامنے nginx۔ TLS termination nginx پر ہوتی ہے، جو MCP process تک کچھ بھی پہنچنے سے پہلے bearer token بھی check کرتا ہے، پھر request کو reverse-proxy کر کے آگے بھیج دیتا ہے۔
4. ایک عام tool call۔ client ایک JSON-RPC request کو ایک واحد POST کے طور پر بھیجتا ہے؛ server اسے process کرتا ہے اور اسی request-response cycle میں result واپس کرتا ہے۔
5. Protocol version negotiation۔ اب جبکہ 2026-07-28 spec final ہو چکی ہے، client اور server باہم طے کرتے ہیں کہ کون سی protocol revision استعمال کرنی ہے۔ جو client ابھی upgrade نہیں ہوا، وہ سیدھا fail ہونے کے بجائے خودکار طور پر 2025-11-25 پر negotiate down کر جاتا ہے۔
6. ایک tool کو مزید input چاہیے۔ connection کھلی رکھنے کے بجائے، server ایک InputRequiredResult واپس کرتا ہے جس میں وہ سوالات ہوتے ہیں جن کے جواب اسے درکار ہیں۔
7. client resume کرتا ہے۔ وہ call کو دوبارہ جاری کرتا ہے، اس بار جوابات اور echoed requestState کے ساتھ۔ چونکہ یہ resume اسی server instance پر واپس جانے کا محتاج نہیں، اس لیے یہ nginx کے پیچھے کسی بھی box پر جا سکتی ہے۔
8. Auth failure path۔ missing یا invalid token nginx layer پر ہی reject کر دیا جاتا ہے، اس سے پہلے کہ وہ MCP process تک پہنچے — application code malformed یا unauthenticated request کو دیکھتی ہی نہیں۔

خصوصی صورتیں

Long-running tools۔ جو چیزیں پہلے کسی سست operation کے لیے held-open stream پر انحصار کرتی تھیں، انہیں اب Tasks extension pattern کی طرف جانا چاہیے، بجائے اس کے کہ وہ ایسے transport کے اوپر دوبارہ persistent connection بنانے کی کوشش کریں جو اب اسے support ہی نہیں کرتی۔

وہ tools جنہیں remote جانے کا کوئی ارادہ نہیں۔ اگر کسی server کو صرف اپنے client کے ساتھ لوکل طور پر ہی چلنا ہے، تو stdio transport اب بھی سب سے آسان option ہے، اور یہاں بیان کی گئی deployment concerns میں سے تقریباً کوئی بھی اس پر لاگو نہیں ہوتی۔

Transition کے دوران mixed-version clients۔ چونکہ پرانے clients خودکار طور پر 2025-11-25 پر fallback کر جاتے ہیں، اس لیے کچھ عرصے تک ایسی ایک ہی deployment چلانا حقیقت پسندانہ ہے جو دونوں protocol revisions کو درست طور پر serve کرے، بجائے اس کے کہ ہر client کو server کے ساتھ lockstep میں upgrade کرنا پڑے۔

Scaling اور Production چیلنجز

Load balancer کے پیچھے متعدد instances۔ پرانے session-based model میں اس کا مطلب sticky sessions یا shared session storage تھا تاکہ client اسی instance سے بندھا رہے جسے اس کے بارے میں علم ہو۔ Statelessness اس ضرورت کو مکمل طور پر ختم کر دیتی ہے — کوئی بھی instance کوئی بھی request serve کر سکتی ہے، اور ایک سے زیادہ box چلانے والوں کے لیے اس rewrite کا اصل unlock یہی ہے۔

جب instance count بڑھے تو TLS اور certificate management۔ ہر EC2 instance کے لیے الگ certificate manage کرنا اچھی طرح scale نہیں کرتا؛ instances کے ایک fleet کے سامنے ACM-backed certificate کے ساتھ managed load balancer رکھنا، per-instance nginx TLS configs کے مقابلے میں بہت کم operational overhead رکھتا ہے۔

Scale پر token issuance اور rotation۔ Static bearer tokens کی صرف security ceiling ہی نہیں ہوتی — جیسے ہی آپ کے پاس چند سے زیادہ clients ہو جائیں، یہ operational headache بھی بن جاتی ہیں، کیونکہ ہر rotation ایک manual coordination problem بن جاتی ہے۔ OAuth 2.1-based issuance کی طرف جانا security gap اور rotation headache، دونوں مسائل ایک ہی قدم میں حل کر دیتا ہے۔

Server-side session state کے بغیر multi-call interactions کی tracing۔ جب server پر calls کے سلسلے کو باندھنے کے لیے کوئی session نہ ہو، تو request payload کے ذریعے گزرنے والے correlation IDs ہی وہ واحد قابلِ اعتماد ذریعہ رہ جاتے ہیں جن سے دوبارہ جوڑا جا سکے کہ ایک واحد agent interaction نے متعدد calls کے دوران اصل میں کیا کیا۔

کوڈ مثالیں

اوپر دی گئی nginx config اور bearer-check middleware، transport اور baseline auth layers کا احاطہ کرتی ہیں۔ یہاں client side پر Multi Round-Trip Request کے resume حصے کو handle کرنے کا ایک minimal pattern ہے:

async def call_tool_with_resume(client, tool_name, params):
    result = await client.call_tool(tool_name, params)
    if result.get("type") == "InputRequiredResult":
        answers = collect_answers(result["questions"])
        return await client.call_tool(
            tool_name,
            {**params, "answers": answers, "requestState": result["requestState"]},
        )
    return result

اہم تفصیل آخری لائن ہے: requestState کو بغیر کسی تبدیلی کے، بالکل ویسا ہی آگے pass کیا جاتا ہے جیسا server نے بھیجا تھا۔

عام غلطیاں

غلطی: “یہ deploy ہو گیا ہے” کو “یہ production-ready ہے” سمجھ لینا۔ nginx اور bearer token کو MCP server کے سامنے رکھ دینا کم از کم حد تو پوری کرتا ہے، پوری نہیں۔ حل: اپنے MCP endpoint کو وہی معیار دیں جو آپ کسی بھی public API کو دیتے ہیں — مناسب auth، logging discipline، اور rate limiting، اس سے پہلے کہ آپ URL بڑے پیمانے پر شیئر کریں۔

غلطی: calls کے درمیان server memory پر انحصار کرنا۔ کچھ ابتدائی deployments خاموشی سے اس بات پر منحصر تھیں کہ server کو پچھلی request سے client کے بارے میں کچھ یاد رہے۔ حل: ہر request کو ایسے سمجھیں جیسے یہ پچھلی بار سے مختلف instance پر جا سکتی ہے، کیونکہ موجودہ spec کے تحت ایسا ہو سکتا ہے۔

غلطی: client میں ایک ہی protocol version hardcode کر دینا۔ ایسا client جو ایک ہی exact revision سے بندھا ہو، server کے upgrade ہوتے ہی ٹوٹ جاتا ہے۔ حل: ایک مناسب fallback کے ساتھ version negotiation نافذ کریں، تاکہ ایک طرف کی upgrade دوسری طرف کو بند نہ کر دے۔

غلطی: “صرف internal” tool کے لیے auth کی حد کو کم سمجھنا۔ آج جو چیز internal-only ہے، وہ کل partner team کے ساتھ shared بھی ہو سکتی ہے، اور اس وقت static token ناکافی ہو جاتی ہے۔ حل: اگر معمولی سا بھی امکان ہو کہ server آپ کے لیپ ٹاپ یا VPC سے باہر جائے گا، تو آغاز ہی سے OAuth 2.1 اور resource indicators کی سمت بنائیں۔

Production کی بہترین عملی تدابیر

• ایسی state مت رکھیں جسے آپ کا infrastructure scale نہ کر سکے۔ اگر client کو calls کے درمیان کچھ یاد رکھنا ضروری ہو، تو اسے payload یا external store میں رکھیں — server memory میں نہیں۔
• Tokens کو اسی resource سے bind کریں جس کے لیے وہ ہیں۔ ایسا token جو آپ کے trust کیے گئے کسی بھی server کے خلاف کام کرے، بالآخر کہیں نہ کہیں وہاں استعمال ہوگا جہاں آپ نے ارادہ نہیں کیا ہوگا۔
• Protocol versions پر negotiation کریں، کسی ایک کو فرض نہ کریں۔ آپ کے clients اور server ہمیشہ ایک ہی دن upgrade نہیں ہوں گے — اس خلا کے لیے جان بوجھ کر تیاری کریں۔
• Auth checks کو edge پر رکھیں۔ nginx پر ہی خراب request reject کر دینا، اس سے پہلے کہ وہ آپ کے application code تک پہنچے، آپ کے MCP process کو سادہ اور آپ کی attack surface کو چھوٹا رکھتا ہے۔
• ہر opaque protocol field کو opaque ہی سمجھیں۔ requestState اور ایسی ملتی جلتی fields اس لیے موجود ہیں کہ server واپس آنے والی چیز پر trust کر سکے — client side پر انہیں inspect یا mutate نہ کریں۔

اختتامیہ

MCP کے گرد موجود theory آسان ہے؛ اصل فیصلے deployment میں ہوتے ہیں، اور 28 جولائی 2026 کی spec update نے وہ فیصلے سب کے لیے بدل دیے ہیں۔ Streamable HTTP کو معیاری infrastructure کے پیچھے چلانا آسان ہو گیا، statelessness نے “ایک اور EC2 instance شامل کریں” کو session-management project کے بجائے ایک حقیقی option بنا دیا، اور authorization model آخرکار اس سطح تک پہنچا جس کی ایک public-facing server کو ضرورت ہوتی ہے۔ جب آپ اسے دیکھ لیتے ہیں تو ان میں سے کچھ بھی پیچیدہ نہیں لگتا — بس مسئلہ یہ ہے کہ نظریاتی مضامین میں یہی حصہ شامل نہیں ہوتا۔

اگر آپ نے localhost کے علاوہ کہیں بھی MCP server deploy کیا ہے، تو جب حقیقی clients اور حقیقی load سامنے آیا تو آپ کو کیا تبدیل کرنا پڑا؟