MCP వెర్షన్ 2, జూలై 28, 2026న అందుబాటులోకి వస్తుంది. ఇది ప్రతి handshake, session-ID header మరియు Model Context Protocol (MCP)ని sticky-session సర్వర్‌లతో అనుసంధానించిన మూడు legacy subsystemsలను తొలగిస్తుంది. ఈ ప్రోటోకాల్ పూర్తిగా stateless అవుతుంది, కాబట్టి క్లయింట్ స్టేట్‌ను భద్రపరచాల్సిన అవసరం లేకుండా, ఏ autoscaled లేదా serverless instance అయినా ఏ రిక్వెస్ట్‌నైనా హ్యాండిల్ చేయగలదు.

ఈ మార్పు ఎందుకు ముఖ్యం

MCP v1లో, క్లయింట్ తప్పనిసరిగా initialize handshakeతో సెషన్‌ను ప్రారంభించాల్సి వచ్చేది; ఆ తర్వాత సర్వర్ Mcp-Session-Idని కేటాయించేది. తదుపరి ప్రతి కాల్‌లో ఆ header ఉండాలి, దీనివల్ల యూజర్ ఒకే బ్యాకెండ్ నోడ్‌కు పరిమితం అయ్యేవారు. Load balancers సెషన్ అఫినిటీని (session affinity) అమలు చేయాల్సి వచ్చేది, ఇది లేటెన్సీని మరియు ఆపరేషనల్ ఇబ్బందులను పెంచేది.

Statelessness ఆ ఇబ్బందులను తొలగిస్తుంది. ఇప్పుడు మొత్తం కాంటెక్స్ట్ (context) ప్రతి HTTP కాల్‌తో పాటు ప్రయాణించే ప్రత్యేకమైన meta fieldsలలో ఉంటుంది. ఒక రిక్వెస్ట్ ఏ instance మీదకైనా వెళ్లవచ్చు, ప్రాసెస్ చేయబడవచ్చు మరియు రెస్పాన్స్ పంపిన వెంటనే ఆ instanceను తొలగించవచ్చు. Serverless platforms, container-orchestrated clusters లేదా అవసరానికి అనుగుణంగా podsలను సృష్టించే (spin up/down) ఏ వాతావరణంలోనైనా పనిచేసే టీమ్‌లు, ఇప్పుడు ఈ ప్రోటోకాల్‌ను తమ ఇన్‌ఫ్రాస్ట్రక్చర్‌కు అనుగుణంగా మార్చుకోవచ్చు.

ఏవి తొలగించబడుతున్నాయి (Retired)

పర్సిస్టెంట్ కనెక్షన్లపై ఆధారపడిన మూడు సబ్‌సిస్టమ్స్ (subsystems) అధికారికంగా డిప్రికేట్ (deprecated) చేయబడ్డాయి:

  • Sampling – v1లో, సర్వర్ క్లయింట్‌ను టెక్స్ట్‌ను జనరేట్ చేయమని అడగవచ్చు, దీనికి ఓపెన్ సెషన్ అవసరమయ్యేది. v2లో, సర్వర్ నేరుగా large-language-model ప్రొవైడర్‌ను కాల్ చేయాలని లేదా InputRequiredResult ప్యాటర్న్‌ను ఉపయోగించాలని ఆశిస్తుంది, ఇక్కడ క్లయింట్ తదుపరి రిక్వెస్ట్‌లో మిస్ అయిన ఇన్‌పుట్‌ను అందిస్తుంది.
  • Roots – గతంలో, క్లయింట్లు ఎక్స్‌టర్నల్ రిసోర్సెస్‌పై సర్వర్ యొక్క వీక్షణను పరిమితం చేసే URIsని పంపేవారు. కొత్త విధానంలో, ఆ URIsలను tool parametersగా పంపడం లేదా రిక్వెస్ట్ యొక్క resource fieldsలలో పొందుపరచడం జరుగుతుంది, దీనివల్ల ప్రత్యేకమైన “roots” నెగోషియేషన్ స్టెప్ అవసరం ఉండదు.
  • Logging – ప్రోటోకాల్-లెవల్ లాగింగ్ హెడర్లు తొలగించబడతాయి. లోకల్ డీబగ్గింగ్ కోసం stderrకి రైట్ చేయండి లేదా ప్రొడక్షన్ అబ్జర్వబిలిటీ (observability) కోసం OpenTelemetryని ఉపయోగించండి.

ఈ డిప్రికేషన్ విండో ఒక సంవత్సరం పాటు ఉంటుంది. డిప్రికేట్ చేయబడిన ఫీచర్లు ఆ కాలం వరకు పనిచేస్తూనే ఉంటాయి, తద్వారా ప్రోటోకాల్ వాటిని తిరస్కరించేలోపు టీమ్‌లు వాటిని రీఫ్యాక్టర్ (refactor) చేసుకోవడానికి సమయం దొరుకుతుంది.

Statelessness కాకుండా కొత్తగా ఏముంది?

MCP v2 రెండు అధికారిక ఎక్స్‌టెన్షన్లను (extensions) జోడిస్తుంది:

  • MCP Apps – ప్రోటోకాల్ ద్వారా పిలవబడే (invoke) సర్వర్-రెండర్డ్ యూజర్ ఇంటర్‌ఫేస్‌లను వివరించడానికి ఒక తేలికపాటి మార్గం.
  • Tasks – బహుళ రిక్వెస్ట్-రెస్పాన్స్ సైకిల్‌ల వరకు సాగే దీర్ఘకాలిక ఆపరేషన్లను హ్యాండిల్ చేయడానికి ఒక ప్యాటర్న్.

ఈ రెండు ఎక్స్‌టెన్షన్లు stateless రిక్వెస్ట్ మోడల్‌ను అనుసరిస్తాయి మరియు హిడెన్ సెషన్ స్టేట్‌ను నివారించడమే కాకుండా పనిచేస్తాయి.

రిస్క్‌లు మరియు ప్రతిపాదనలు

ఈ మార్పు అనేది కేవలం ప్లగ్-అండ్-ప్లే అప్‌గ్రేడ్ కాదు. v2 SDKలు ఇంకా బీటా (beta) దశలోనే ఉన్నాయి మరియు వాటి పబ్లిక్ APIలు స్టేబుల్ రిలీజ్ రాకముందే మారవచ్చు. బ్రేకింగ్ చేంజ్స్‌ను (breaking changes) తట్టుకోలేని ప్రొడక్షన్ వర్క్‌లోడ్‌ల కోసం, v2 SDK స్టేబుల్ అయ్యే వరకు స్టేబుల్ v1 SDKని ఉపయోగించండి.

డెవలపర్లు డిప్రికేట్ చేయబడిన మూడు సబ్‌సిస్టమ్స్‌లో ఏవైనా ఉన్నాయా అని ప్రస్తుతం ఉన్న కోడ్‌ను ఆడిట్ చేయాల్సి ఉంటుంది.

ఒక ప్రాగ్మాటిక్ మైగ్రేషన్ రోడ్‌మ్యాప్

  1. ఈరోజే ఆడిట్ చేయండి – మీ సర్వీసులలో handshake, Mcp-Session-Id, sampling calls, roots URIs మరియు ప్రోటోకాల్-లెవల్ లాగింగ్ వినియోగాన్ని స్కాన్ చేయండి. స్టేట్‌లెస్ మోడల్ కింద ఏ కోడ్ విఫలమవుతుందో గుర్తించండి.
  2. నాన్-క్రిటికల్ నోడ్‌పై పరీక్షించండి – స్టేబుల్ v2 SDK విడుదలైనప్పుడు, ఒక సాండ్‌బాక్స్ (sandbox) సర్వర్‌ను ప్రారంభించి, దానిని టెస్ట్ క్లయింట్‌కు అనుసంధానించండి మరియు అవసరమైన అన్ని meta fields ఉన్నాయో లేదో మరియు అవి సరిగ్గా ఇంటర్‌ప్రెట్ చేయబడుతున్నాయో లేదో తనిఖీ చేయండి.
  3. గడువులోపు పూర్తి మైగ్రేషన్ – రన్‌టైమ్ రిజెక్షన్లను (runtime rejections) నివారించడానికి, ఒక సంవత్సరం గ్రేస్ పీరియడ్ ముగియకముందే అన్ని ప్రొడక్షన్ నోడ్‌లలో మార్పును పూర్తి చేయండి.

తదుపరి ఏం గమనించాలి?

  • స్టేబుల్ SDK విడుదల – బీటా SDKలను ఫ్రీజ్ చేసి, వెర్షన్ చేయబడిన స్టేబుల్ ప్యాకేజీని ప్రచురిస్తారు. ఏదైనా క్రిటికల్ డిప్లాయ్‌మెంట్ కోసం ఆ వెర్షన్ సురక్షితమైన లక్ష్యం అవుతుంది.

ఈ పరివర్తనకు కోడ్ మార్పులు మరియు బీటా-SDK ప్రయోగాత్మక కాలం అవసరమవుతుంది, కానీ దీని వల్ల LLM-ఆధారిత ఏ అప్లికేషన్‌కైనా మరింత క్లీన్ మరియు స్కేలబుల్ ఇంటిగ్రేషన్ పాయింట్ లభిస్తుంది.

ముఖ్య గమనిక (Takeaway): మీ స్టాక్ ఇంకా MCP handshakes లేదా డిప్రికేట్ చేయబడిన మూడు సబ్‌సిస్టమ్స్‌పై ఆధారపడి ఉంటే, ఇప్పుడే ఆడిట్‌ను ప్రారంభించండి; ఒక సంవత్సరం గ్రేస్ పీరియడ్ అనేది చాలా సమయం అయినప్పటికీ, అసలైన ఖర్చు డెడ్‌లైన్ కాదు, కోడ్‌ను రీఫ్యాక్టర్ చేసే ప్రయత్నం.