Stateless MCP server అంటే ఏమిటి? మార్పులు ఏమిటి?

Stateless MCP server అంటే ఏమిటి

Stateless MCP server అభ్యర్థనల (requests) మధ్య క్లయింట్-నిర్దిష్ట సమాచారాన్ని (per-client state) నిల్వ చేయదు. ప్రతి అభ్యర్థనలో ప్రోటోకాల్ వెర్షన్, క్లయింట్ సామర్థ్యాలు మరియు సర్వర్ సమాధానం ఇవ్వడానికి అవసరమైన ఆధారాలు (credentials) ఉంటాయి. కాబట్టి, ఏ యంత్రంపై ఉన్న ఏ ప్రాసెస్ అయినా ఏ అభ్యర్థనకైనా సమాధానం ఇవ్వగలదు. MCP (Model Context Protocol, ఏజెంట్లు టూల్స్‌ను చేరుకోవడానికి ఉపయోగించే వైర్ ఫార్మాట్) దీనిని 2026-07-28 రివిజన్‌లో ఒక నియమంగా మార్చింది. ఇది initialize హ్యాండ్‌షేక్‌ను మరియు దాని కింద ఉన్న HTTP సెషన్‌ను తొలగించింది.

ఇదే దీని మొత్తం కార్యాచరణ ఉద్దేశ్యం. క్లయింట్ వారీగా ఏ సమాచారాన్ని నిల్వ చేయని సర్వర్, సెషన్ అఫినిటీ (session affinity) అవసరం లేని సాధారణ load balancer వెనుక ఉండగలదు. ఇది డిప్లాయ్‌మెంట్ సమయంలో క్లయింట్‌లకు అంతరాయం కలగకుండా రీస్టార్ట్ చేయగలదు మరియు ఒకదానికి బదులుగా నాలుగు ఒకే విధమైన ప్రాసెస్‌లుగా రన్ అవ్వగలదు. సెషన్-ఆధారిత సర్వర్ అదనపు యంత్రాంగం లేకుండా వీటిలో ఏదీ చేయలేదు.

Model Context Protocol అనేది ఒక stateless ప్రోటోకాల్: ఒక అభ్యర్థనను ప్రాసెస్ చేయడానికి అవసరమైన మొత్తం సమాచారం ఆ అభ్యర్థనలోనే ఉంటుంది. సర్వర్ ప్రతి అభ్యర్థనను స్వతంత్రంగా ప్రాసెస్ చేస్తుంది; ఒకే కనెక్షన్ లేదా స్ట్రీమ్‌లో ఉన్నప్పటికీ, మునుపటి అభ్యర్థనల నుండి ఎటువంటి సమాచారాన్ని (state) ఊహించకూడదు.

Stateless అంటే మీ సర్వర్ ఏదీ నిల్వ చేయదని అర్థం కాదు. మీ database, queue మరియు cache అన్నీ యథావిధిగా ఉంటాయి. దీని అర్థం ప్రోటోకాల్ కనెక్షన్‌పై ఎటువంటి సమాచారాన్ని మోసుకెళ్లదు. కాబట్టి, సర్వర్ ఒక కనెక్షన్‌ను, ప్రాసెస్‌ను లేదా ఓపెన్ సాకెట్‌ను "ఈ క్లయింట్, సంభాషణ మధ్యలో ఉంది" అని సూచించేదిగా పరిగణించకూడదు.

2026-07-28 వెర్షన్‌లో తొలగించబడిన అంశాలు

2026-07-28 అనేది 2026 ఆగస్టు నాటికి ఉన్న స్పెసిఫికేషన్ యొక్క ప్రస్తుత వెర్షన్. 2025-11-25 తో పోలిస్తే, ఇది సెషన్లకు మద్దతు ఇచ్చే ఐదు అంశాలను తొలగించింది.

• initialize అభ్యర్థన మరియు notifications/initialized నోటిఫికేషన్. ఇందులో ఎటువంటి హ్యాండ్‌షేక్ (handshake) లేదు (SEP-2575).
• Mcp-Session-Id హెడర్, మరియు HTTP DELETE తో సెషన్ ముగింపు (SEP-2567).
• సర్వర్లు నోటిఫికేషన్లను పంపే స్వతంత్ర HTTP GET స్ట్రీమ్. దీని స్థానంలో subscriptions/listen వచ్చింది, ఇది ఒక సాధారణ POST అభ్యర్థన, దీని ప్రతిస్పందన సుదీర్ఘకాలం ఉండే స్ట్రీమ్.
• SSE (server-sent events) స్ట్రీమ్ పునఃప్రారంభ సామర్థ్యం. Last-Event-ID హెడర్ మరియు ఈవెంట్-వారీ IDలు తొలగించబడ్డాయి, కాబట్టి స్ట్రీమ్ విచ్ఛిన్నమైతే అప్పటికే జరుగుతున్న అభ్యర్థన ఆగిపోతుంది మరియు క్లయింట్ దానిని కొత్త అభ్యర్థన IDతో కొత్త అభ్యర్థనగా మళ్ళీ పంపాలి.
• ping, logging/setLevel మరియు notifications/roots/list_changed. లాగ్ స్థాయి ఇప్పుడు ప్రతి అభ్యర్థనకు ఒక ఫీల్డ్‌గా ఉంటుంది, ఇది _meta లోని io.modelcontextprotocol/logLevel.

ఒక పద్ధతిని కొత్తగా చేర్చారు, ప్రతి సర్వర్ దీనిని అమలు చేయాలి. server/discover సర్వర్ మద్దతు ఇచ్చే ప్రోటోకాల్ వెర్షన్లు, సామర్థ్యాలు మరియు గుర్తింపును ఒకే కాల్‌లో తెలియజేస్తుంది. ఇది మిగిలి ఉన్న హ్యాండ్‌షేక్‌కు అత్యంత దగ్గరగా ఉంటుంది, మరియు క్లయింట్లు దీనిని పిలవడం ఐచ్ఛికం.

ప్రొడక్షన్‌లో సెషన్ ట్రాన్స్‌పోర్ట్‌ను నిర్వహించడం ఎందుకు కష్టంగా ఉండేది

2025-11-25 మరియు అంతకు ముందు వెర్షన్లలో, ఒక సర్వర్ ప్రారంభ సమయంలోనే సెషన్ IDని సృష్టించి, దానిని InitializeResult లోని Mcp-Session-Id హెడర్ ద్వారా పంపేది. ఆ తర్వాత క్లయింట్ ప్రతి అభ్యర్థనలోనూ ఆ హెడర్‌ను పంపాల్సి ఉండేది. చర్చించుకున్న ప్రోటోకాల్ వెర్షన్ మరియు క్లయింట్ యొక్క సామర్థ్యాలు ఆ ID ఆధారంగా సర్వర్ మెమరీలో నిక్షిప్తమై ఉండేవి. ఈ పద్ధతిలోని ప్రతి అంశం నిర్వహణ పరంగా కొన్ని ఇబ్బందులను కలిగిస్తుంది.

• సర్వర్ రీస్టార్ట్ అయినప్పుడు సెషన్ టేబుల్ మొత్తం తొలగిపోయేది. చెల్లని సెషన్ IDతో వచ్చే అభ్యర్థనలకు 404 Not Found తో సమాధానం ఇవ్వాలని, ఆపై క్లయింట్ కొత్త InitializeRequest తో మళ్ళీ ప్రారంభించాలని స్పెసిఫికేషన్ నిర్దేశించింది. దీనివల్ల ప్రతి డిప్లాయ్‌మెంట్, కనెక్ట్ అయి ఉన్న ప్రతి క్లయింట్‌కు ఒక రీకనెక్ట్ ఈవెంట్‌గా మారేది.
• ఒక రెప్లికాకు మరొక రెప్లికాలోని సెషన్ల గురించి తెలిసేది కాదు. దీనివల్ల స్కేలింగ్ చేసేటప్పుడు లోడ్ బ్యాలెన్సర్‌ వద్ద స్టిక్కీ రూటింగ్ (sticky routing) అవసరమయ్యేది, లేదా ప్రతి రెప్లికా ప్రతి అభ్యర్థనలోనూ చదివేలా ఒక షేర్డ్ సెషన్ స్టోర్ ఉండాల్సి వచ్చేది.
• సెషన్ టేబుల్ మెమరీలో ఉండేది, ఇది ఖాళీగా ఉన్న (idle) క్లయింట్ల సంఖ్య పెరిగేకొద్దీ పెరిగిపోయేది. DELETE అనేది ఐచ్ఛికం, కాబట్టి దానిని పంపకుండానే కనెక్షన్ ముగించే క్లయింట్ల డేటా సర్వర్‌లో అలాగే ఉండిపోయేది.
• కనెక్షన్‌ను బట్టి ఫలితాలు మారే అవకాశం ఉన్నందున, సర్వర్‌కు ముందు క్యాచింగ్ (caching) చేయడం సురక్షితం కాదు.

సెషన్లను తొలగించడం ద్వారా ఈ నాలుగు సమస్యలు ఒకేసారి పరిష్కారమవుతాయి. మీరు ఏదైనా కాన్ఫిగరేషన్‌ను మార్చే ముందు ఈ మార్పును అర్థం చేసుకోవడం చాలా ముఖ్యం.

ప్రతి అభ్యర్థనలో ఇప్పుడు ఉండే అంశాలు

MCP endpoint కు పంపే ప్రతి POST అభ్యర్థన స్వతంత్రమైనది. ప్రోటోకాల్ వెర్షన్ మరియు క్లయింట్ సామర్థ్యాలు (client capabilities) అభ్యర్థన బాడీలో _meta కింద ఉంటాయి. అలాగే, మధ్యవర్తి (intermediary) JSON ను పార్స్ చేయకుండానే అభ్యర్థనను సరైన మార్గంలో పంపేందుకు, ఎంపిక చేసిన ఫీల్డ్‌లను HTTP హెడర్‌లలో కూడా ప్రతిబింబిస్తారు.

POST /mcp HTTP/1.1
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather
Authorization: Bearer <access token>

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {"location": "Seattle, WA"},
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {"name": "ExampleClient", "version": "1.0.0"},
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

ప్రతి అభ్యర్థనలో io.modelcontextprotocol/protocolVersion మరియు io.modelcontextprotocol/clientCapabilities తప్పనిసరి. clientInfo తప్పనిసరి కాకపోయినప్పటికీ, క్లయింట్లు దీనిని పంపడం మంచిది. అవసరమైన ఫీల్డ్ లేని అభ్యర్థన తప్పుగా ఉన్నట్లు (malformed) పరిగణించబడుతుంది. కాబట్టి, సర్వర్ దానిని JSON-RPC ఎర్రర్ -32602 మరియు HTTP 400 Bad Request తో తిరస్కరించాలి.

ప్రతి అభ్యర్థనలో Mcp-Method హెడర్ తప్పనిసరి. tools/call, resources/read మరియు prompts/get అభ్యర్థనలకు Mcp-Name అవసరం. హెడర్ విలువ బాడీలోని విలువతో సరిపోలాలి. బాడీని ప్రాసెస్ చేసే సర్వర్, ఈ రెండింటి మధ్య వ్యత్యాసం ఉంటే 400 Bad Request మరియు ఎర్రర్ కోడ్ -32020, HeaderMismatch తో తిరస్కరించాలి. హెడర్ ఆధారంగా రూటింగ్ చేసే లోడ్ బ్యాలెన్సర్ మరియు బాడీని ఎగ్జిక్యూట్ చేసే సర్వర్ వేర్వేరు మూలాల నుండి సమాచారాన్ని పొందుతాయి కాబట్టి ఈ నియమం అవసరం. మీరు ఈ హెడర్‌ల ఆధారంగా రూటింగ్ లేదా రేట్-లిమిటింగ్ చేస్తుంటే, ముందుగా MCP-Protocol-Version ని తనిఖీ చేయండి: పాత వెర్షన్లలో హెడర్‌ను బాడీతో సరిచూసేవారు కాదు, కాబట్టి ఆ వెర్షన్లలో హెడర్ విలువ నమ్మదగినది కాదు.

వెర్షన్ సరిపోలకపోవడం అనేది ఇప్పుడు హ్యాండ్‌షేక్ విఫలం కావడం కాకుండా, సాధారణ అభ్యర్థన స్థాయి ఎర్రర్‌గా పరిగణించబడుతుంది. అభ్యర్థించిన వెర్షన్‌ను అమలు చేయని సర్వర్ 400 Bad Request తో స్పందించి, ఎర్రర్ -32022, UnsupportedProtocolVersion ను చూపిస్తుంది మరియు అది ఏ వెర్షన్లకు మద్దతు ఇస్తుందో data.supported లో తెలియజేస్తుంది. క్లయింట్ ఆ జాబితా నుండి ఒకదానిని ఎంచుకుని మళ్ళీ ప్రయత్నిస్తుంది.

స్టేట్ ఎక్కడికి వెళ్ళింది: టోకెన్లు, కర్సర్లు, సబ్‌స్క్రిప్షన్లు

స్టేట్ మాయం కాలేదు. అది మీరు చూడగలిగే మరియు లాగ్ చేయగలిగే ప్రదేశాలకు మారింది.

క్రెడెన్షియల్స్ ప్రతి అభ్యర్థనలోకి మారుతాయి. గుర్తింపును జత చేయడానికి సెషన్ ఏదీ ఉండదు, కాబట్టి యాక్సెస్ టోకెన్ ప్రతి HTTP కాల్‌తో పాటు వెళ్తుంది మరియు ప్రతిసారీ ధృవీకరించబడుతుంది. వివరాలు క్రింద ఉన్న అథెంటికేషన్ విభాగంలో ఉన్నాయి.

కర్సర్లు వాటి స్థానాన్ని అవే మోసుకెళ్లాలి. tools/list, resources/list, prompts/list మరియు resources/templates/list లపై పేజినేషన్ ఒక అస్పష్టమైన (opaque) కర్సర్ స్ట్రింగ్‌ను ఉపయోగిస్తుంది, క్లయింట్లు దీనిని పార్స్ చేయకూడదు లేదా మార్చకూడదు. సింగిల్-ప్రాసెస్ సర్వర్‌లో ఆఫ్‌సెట్‌ను మెమరీలో ఉంచి, సెషన్ ద్వారా కీ చేయడం సాధారణం. సెషన్ లేనప్పుడు, ఏదైనా రెప్లికా లిస్టింగ్‌ను కొనసాగించడానికి కర్సర్ సరిపోవాలి, కాబట్టి స్థానాన్ని కర్సర్ లోపల ఎన్‌కోడ్ చేసి సైన్ చేయండి, లేదా అన్ని రెప్లికాలు షేర్ చేసుకునే స్టోరేజ్‌లో ఉంచండి. చెల్లని కర్సర్ -32602ని రిటర్న్ చేయాలి. దీనిని సైన్ చేయండి, ఎందుకంటే అస్పష్టమైన కర్సర్ అనేది క్లయింట్ అందించిన ఇన్‌పుట్, దీనిని మీ కోడ్ డీకోడ్ చేసి నమ్ముతుంది.

సబ్‌స్క్రిప్షన్లు కనెక్షన్‌కు కాకుండా అభ్యర్థనకు చెందుతాయి. మార్పు నోటిఫికేషన్లు కోరుకునే క్లయింట్, తనకు కావలసిన రకాలను పేర్కొంటూ subscriptions/listenని పంపుతుంది: toolsListChanged, promptsListChanged, resourcesListChanged మరియు resourceSubscriptions. సర్వర్ notifications/subscriptions/acknowledgedతో సమాధానమిస్తుంది మరియు ఆ రెస్పాన్స్ స్ట్రీమ్‌ను ఓపెన్‌గా ఉంచుతుంది. స్ట్రీమ్ డ్రాప్ అయితే, సర్వర్ ఏదీ దాచుకోదు, మరియు క్లయింట్ దానిని తిరిగి పొందడానికి subscriptions/listenని మళ్ళీ పంపుతుంది.

క్రాస్-కాల్ అప్లికేషన్ స్టేట్ ఒక స్పష్టమైన హ్యాండిల్‌గా మారుతుంది. కాల్‌ల మధ్య సర్వర్ ఏదైనా గుర్తుంచుకోవాల్సి వచ్చినప్పుడు, స్పెసిఫికేషన్ ఇచ్చే సమాధానం సర్వర్ రూపొందించిన ఐడెంటిఫైయర్, ఇది సాధారణ టూల్ ఆర్గ్యుమెంట్‌గా తిరిగి పంపబడుతుంది. ఇది టూల్ స్కీమాలో కనిపిస్తుంది, లాగ్ చేయవచ్చు, మరియు ఇది కనెక్షన్ ద్వారా ఎప్పటికీ సూచించబడదు. self-hosted MCP email server వంటి వినియోగదారు డేటాను కలిగి ఉన్న సర్వర్, సెషన్‌కు బదులుగా ఈ పద్ధతిని ఉపయోగిస్తుంది: మెయిల్‌బాక్స్ లేదా డ్రాఫ్ట్ ఐడెంటిఫైయర్ అనేది ఒక టూల్ ఆర్గ్యుమెంట్, కాబట్టి ఏదైనా రెప్లికా తదుపరి కాల్‌ను స్వీకరించగలదు. చాలా టూల్స్‌కు అసలు హ్యాండిల్ అవసరమే ఉండదు: SearXNG instance ద్వారా పనిచేసే సెర్చ్ టూల్ ఒక క్వెరీని తీసుకుని ఫలితాలను ఇస్తుంది, దీనికి తదుపరి కాల్ కోసం ఏదీ గుర్తుంచుకోవాల్సిన అవసరం లేదు మరియు ఏ రెప్లికా సమాధానం ఇచ్చిందనే దానితో సంబంధం ఉండదు.

Deployment: reverse proxy, timeouts, health checks

MCP endpoint అనేది POST అభ్యర్థనలను స్వీకరించే ఒక మార్గం. చాలా ట్రాఫిక్ స్వల్పకాలిక అభ్యర్థనలు మరియు JSON ప్రతిస్పందనలతో కూడి ఉంటుంది, వీటిని ఏదైనా ప్రాక్సీ సులభంగా నిర్వహిస్తుంది. అయితే, streaming response విషయంలో ప్రాక్సీ యొక్క డిఫాల్ట్ సెట్టింగ్‌లు సమస్యగా మారవచ్చు. మీరు ల్యాప్‌టాప్ డెమో నుండి VPSలో నడుస్తున్న MCP సర్వర్‌కు మారినప్పుడు ఈ అంశం కీలకం అవుతుంది.

location /mcp {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_buffering off;
    proxy_read_timeout 1h;
    proxy_send_timeout 1h;
}

proxy_buffering off ముఖ్యమైనది, ఎందుకంటే nginx డిఫాల్ట్‌గా ప్రాక్సీ చేసిన ప్రతిస్పందనలను బఫర్ చేస్తుంది. దీనివల్ల SSE ఈవెంట్‌లు బఫర్ నిండే వరకు లేదా ప్రతిస్పందన ముగిసే వరకు నిలిచిపోతాయి. SSE ప్రతిస్పందనలపై X-Accel-Buffering: no పంపాలని స్పెసిఫికేషన్ సూచిస్తుంది. nginx ఈ హెడర్‌ను గౌరవిస్తుంది కాబట్టి, సరైన సర్వర్ మీ ప్రాక్సీకి తగిన సూచనలను అందిస్తుంది. మీరు నియంత్రించగలిగే సగం బాధ్యత మీదే కాబట్టి, ఈ డైరెక్టివ్‌ను సెట్ చేయండి.

proxy_read_timeout డిఫాల్ట్‌గా 60 సెకన్లకు సెట్ చేయబడి ఉంటుంది. 60 సెకన్ల కంటే ఎక్కువ సమయం నిశ్శబ్దంగా ఉండే subscriptions/listen స్ట్రీమ్‌ను మీ సర్వర్ కాకుండా, nginx మూసివేస్తుంది. దీనివల్ల మీ లాగ్‌లలో సర్వర్ ఆరోగ్యంగా ఉన్నట్లు కనిపిస్తుంది, కానీ క్లయింట్ వైపు స్ట్రీమ్ కట్ అవుతుంది. దీన్ని మొత్తం సర్వర్ కోసం కాకుండా, కేవలం MCP location కోసం మాత్రమే పెంచండి. నిశ్శబ్ద సమయాల్లో కనెక్షన్‌ను యాక్టివ్‌గా ఉంచడానికి సర్వర్లు SSE comment line (కోలన్‌తో మొదలయ్యే లైన్) పంపడం మంచిది, ఇది మధ్యవర్తిత్వ ప్రాక్సీలు స్ట్రీమ్‌ను టైమ్-అవుట్ చేయకుండా నిరోధిస్తుంది.

Caddy కి తక్కువ సెట్టింగ్‌లు అవసరం. ఇది నెట్‌వర్క్ సామర్థ్యం కోసం పాక్షికంగా బఫర్ చేస్తుంది మరియు ప్రతిస్పందనలో Content-Type: text/event-stream ఉన్నప్పుడు వెంటనే ఫ్లష్ చేస్తుంది, కాబట్టి అదనపు డైరెక్టివ్‌లు లేకుండానే స్ట్రీమింగ్ పనిచేస్తుంది.

mcp.example.com {
	reverse_proxy 127.0.0.1:8080 {
		health_uri /healthz
		health_interval 10s
	}
}

ఆ హెల్త్ చెక్ దేనిని సూచిస్తుందో గమనించండి. MCP endpoint పై GET తో యాక్టివ్ చెక్ చేయవద్దు, ఎందుకంటే ఈ వెర్షన్‌ను అమలు చేసే సర్వర్ GET మరియు DELETE అభ్యర్థనలకు 405 Method Not Allowed అని సమాధానమిస్తుంది. Caddy యొక్క డిఫాల్ట్ హెల్త్ మెథడ్ GET. దీనివల్ల ప్రాక్సీ సరిగ్గా పనిచేస్తున్న బ్యాకెండ్‌ను కూడా డౌన్ అయినట్లు పరిగణిస్తుంది. ప్రాక్సీ కోసం /healthz వంటి సాధారణ పాత్‌ను ఉపయోగించండి మరియు ప్రోటోకాల్‌ను విడిగా POST ద్వారా తనిఖీ చేయండి.

curl -sS https://mcp.example.com/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2026-07-28' \
  -H 'Mcp-Method: server/discover' \
  -d '{"jsonrpc":"2.0","id":"health-1","method":"server/discover","params":{"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientCapabilities":{}}}}'

supportedVersions జాబితాను కలిగి ఉన్న 200, ప్రాసెస్ నడుస్తోందని మరియు ప్రోటోకాల్‌ను అర్థం చేసుకుంటోందని సూచిస్తుంది. JSON-RPC ఎర్రర్ -32601 తో కూడిన 404 అంటే ప్రాసెస్ నడుస్తోంది కానీ server/discover ను అందించడం లేదు, ఇది ప్రతి 2026-07-28 సర్వర్ తప్పనిసరిగా అమలు చేయాలి. -32022 తో కూడిన 400 అంటే మీ చెకర్ అడిగిన వెర్షన్‌కు ఈ బిల్డ్ మద్దతు ఇవ్వడం లేదు, డిపెండెన్సీ అప్‌గ్రేడ్ తర్వాత మీరు గుర్తించాల్సిన ముఖ్యమైన అంశం ఇది. ఓపెన్ సోర్స్ nginx లో యాక్టివ్ హెల్త్ చెక్స్ ఉండవు, కాబట్టి అప్‌స్ట్రీమ్‌లో పాసివ్ max_fails మరియు fail_timeout ఉపయోగించండి మరియు మీ మానిటరింగ్ ద్వారా ప్రోటోకాల్ చెక్ చేయండి.

Rolling restart ఇప్పుడు కేవలం నడుస్తున్న అభ్యర్థనలపై మాత్రమే ప్రభావం చూపుతుంది. కనెక్షన్‌లను డ్రైన్ చేయండి, ఓపెన్ POSTలు పూర్తయ్యే వరకు వేచి ఉండండి, కొత్త ప్రాసెస్‌ను ప్రారంభించండి; విఫలమైన వాటిని క్లయింట్లు తిరిగి పంపుతాయి. మీరు కోల్పోయే ఏకైక విషయం ఏదైనా ఓపెన్ subscriptions/listen స్ట్రీమ్, ఎందుకంటే అది ఒక నిర్దిష్ట ప్రాసెస్‌కు ఉన్న లైవ్ కనెక్షన్. Statelessness సెషన్ అఫినిటీని తొలగించింది, కానీ ప్రస్తుతం ఓపెన్ అయి ఉన్న స్ట్రీమ్ యొక్క కనెక్షన్ అఫినిటీని తొలగించలేదు; దీనిని ఏ రూటింగ్ రూల్ సరిచేయలేదు. క్లయింట్ దీనిని గుర్తించగలదు: ఖాళీ subscriptions/listen ఫలితంతో ముగిసే స్ట్రీమ్ విజయవంతంగా ముగిసినట్లు, అలా కాకుండా ముగిసే స్ట్రీమ్ కట్ అయినట్లు అర్థం. క్లయింట్ దీనిని రీకనెక్ట్ అవ్వడానికి ఒక కారణంగా పరిగణించవచ్చు.

మొదటిసారిగా క్యాషింగ్ సాధ్యమవుతుంది. లిస్ట్ మెథడ్స్ నుండి వచ్చే ఫలితాలు ఇప్పుడు ttlMs మరియు cacheScope కలిగి ఉంటాయి, మరియు cacheScope: "public" షేర్డ్ మధ్యవర్తులకు ప్రతిస్పందనను క్యాష్ చేయవచ్చని తెలియజేస్తుంది. సెషన్లను తొలగించడం వల్ల లిస్ట్ ఫలితాలు ప్రతి కనెక్షన్‌కు మారవు కాబట్టి, ఇది సురక్షితం.

సెషన్ లేనప్పుడు అథెంటికేషన్ ఎందుకు మారుతుంది

సెషన్ ఉన్నప్పుడు, initialize వద్ద ఒకసారి అథెంటికేట్ చేసి, ఆ తర్వాత సెషన్ IDని అన్నింటికీ ఆధారంగా పరిగణించడం సులభంగా అనిపిస్తుంది. ఆ విధంగా ఉపయోగించే సెషన్ ID అనేది ఆడియన్స్, గడువు ముగింపు తేదీ (expiry) లేదా రద్దు చేసే మార్గం లేని, మీ సర్వర్ ద్వారానే సృష్టించబడిన ఒక బేరర్ క్రెడెన్షియల్. సెషన్లను తొలగించడం ద్వారా ఆ షార్ట్‌కట్ తొలగిపోతుంది, మరియు దానికి బదులుగా వచ్చే విధానం మరింత కఠినంగా ఉంటుంది.

రక్షిత MCP సర్వర్ ఒక OAuth 2.1 రిసోర్స్ సర్వర్‌గా పనిచేస్తుంది. క్లయింట్ నుండి వచ్చే ప్రతి HTTP అభ్యర్థన తప్పనిసరిగా Authorization: Bearer <access token>ని కలిగి ఉండాలి, మరియు సర్వర్ ప్రతి అభ్యర్థనపై టోకెన్‌ను ధృవీకరిస్తుంది. ఈ ధృవీకరణలో ఆడియన్స్ కూడా ఉంటుంది: RFC 8707 (Resource Indicators for OAuth 2.0) ప్రకారం, ఆ టోకెన్ ప్రత్యేకంగా తన కోసమే జారీ చేయబడిందని సర్వర్ నిర్ధారించుకోవాలి, మరియు వేరే దేనికోసం ఉద్దేశించిన టోకెన్లను అంగీకరించకూడదు లేదా పంపకూడదు. క్లయింట్లు సర్వర్ యొక్క కానానికల్ URIతో resource పారామీటర్‌ను పంపడం ద్వారా సరైన ఆడియన్స్‌ను అభ్యర్థిస్తాయి.

డిస్కవరీ ఒక ఛాలెంజ్ ద్వారా జరుగుతుంది. ఉపయోగించదగిన టోకెన్ లేని అభ్యర్థన వచ్చినప్పుడు, సర్వర్ 401 Unauthorizedతో సమాధానం ఇస్తుంది.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         scope="files:read"

క్లయింట్ resource_metadataని చదివి, ఆ డాక్యుమెంట్‌ను (RFC 9728, OAuth 2.0 Protected Resource Metadata, దీనిని MCP సర్వర్లు తప్పనిసరిగా అమలు చేయాలి) పొంది, అథరైజేషన్ సర్వర్‌ను కనుగొని, ఆ ఫ్లోను రన్ చేస్తుంది. తగినంత అనుమతులు లేని చెల్లుబాటు అయ్యే టోకెన్ వచ్చినప్పుడు, error="insufficient_scope" మరియు ఆ ఆపరేషన్‌కు అవసరమైన స్కోప్‌లతో కూడిన 403 Forbidden వస్తుంది.

దీనిని మీరు ఎలా అమలు చేస్తారనే దానిపై రెండు పరిణామాలు ఉంటాయి. టోకెన్ ధృవీకరణ ఇప్పుడు ప్రతి సెషన్‌కు ఒకసారి కాకుండా ప్రతి అభ్యర్థనపై జరుగుతుంది, కాబట్టి ప్రతి కాల్‌కు ఇంట్రోస్పెక్షన్ ఎండ్‌పాయింట్‌కు నెట్‌వర్క్ రౌండ్ ట్రిప్ జరగడం వల్ల మీ లేటెన్సీ పెరుగుతుంది: సంతకం, ఆడియన్స్ మరియు గడువు తేదీ ఆధారంగా స్థానికంగా ధృవీకరించగల టోకెన్లను ఎంచుకోండి, లేదా టోకెన్ ఆధారంగా ధృవీకరణ ఫలితాన్ని స్వల్ప కాలం పాటు కాష్ చేయండి. మరియు గుర్తింపును కలిగి ఉండే సెషన్ ఏదీ లేనందున, ప్రతి కాల్‌లో టోకెన్ నుండి అథరైజేషన్‌ను లెక్కించాలి. ఇది సెషన్ మోడల్ కంటే మరింత పారదర్శకమైనది, మరియు ఇది ఏజెంట్ ప్రాసెస్ నుండి క్రెడెన్షియల్స్‌ను దూరంగా ఉంచే విస్తృత పద్ధతికి అనుగుణంగా ఉంటుంది, దీని గురించి AI ఏజెంట్ నుండి రహస్యాలను దూరంగా ఉంచడంలో వివరించబడింది.

ఈ రివిజన్ గురించి ఏది నిజం, ఏది నిజం కాదు

పైన పేర్కొన్నవన్నీ 2026-07-28 రివిజన్‌ను వివరిస్తాయి. ఇది MCPని శాశ్వతంగా వివరించదు, అలాగే మీరు గత ఏడాది డిప్లాయ్ చేసిన సర్వర్‌ను కూడా ఇది వివరించదు.

2025-11-25 మరియు అంతకంటే పాత వెర్షన్లలోని క్లయింట్లు మరియు సర్వర్లు ఇప్పటికీ handshake మోడల్‌ను ఉపయోగిస్తాయి. ఈ స్పెసిఫికేషన్ ఆ రివిజన్లను లెగసీ (legacy) అని, పర్-రిక్వెస్ట్-మెటాడేటా (per-request-metadata) రివిజన్లను మోడ్రన్ (modern) అని పిలుస్తుంది. కేవలం ఈ రివిజన్‌కు మాత్రమే మద్దతు ఇచ్చే సర్వర్, పాత క్లయింట్‌ను కలిసినప్పుడు, MCP ఎండ్‌పాయింట్‌పై 405 Method Not Allowed నుండి GET లేదా DELETE వరకు సమాధానం ఇవ్వాలి, ఎటువంటి Mcp-Session-Id హెడర్‌ను సృష్టించకుండా లేదా ప్రతిధ్వనించకుండా దానిని విస్మరించాలి, మరియు స్ట్రీమ్‌లు పునఃప్రారంభించదగినవి కావు కాబట్టి Last-Event-IDని విస్మరించాలి. డ్యూయల్-ఎరా (dual-era) సర్వర్ ఒకే ఎండ్‌పాయింట్‌పై రెండింటినీ అందించవచ్చు: మోడ్రన్ _metaని కలిగి ఉన్న అభ్యర్థన స్టేట్‌లెస్‌గా (statelessly) అందించబడుతుంది, మరియు initialize అభ్యర్థన పాత సెషన్ సెమాంటిక్స్‌ను ఎంచుకుంటుంది.

కాబట్టి వీటిలో దేనినైనా నమ్మే ముందు రివిజన్ స్ట్రింగ్‌ను తనిఖీ చేయండి. మీ SDK ఇప్పటికీ initializeని పంపుతుంటే, మీ డిప్లాయ్‌మెంట్‌లో సెషన్లు ఇప్పటికీ అమలులో ఉన్నాయని మరియు పైన పేర్కొన్న సెషన్-సంబంధిత సమస్యలను మీరే నిర్వహించుకోవాలని అర్థం. క్లయింట్ వైపు కూడా ఇదే వర్తిస్తుంది: మీ సొంత బాక్స్‌లో ఉన్న ఏజెంట్ ప్రాసెస్, ఉదాహరణకు running a coding agent on a VPS లోని సెటప్, అది ఉపయోగించే లైబ్రరీ మోడ్రన్ రివిజన్‌ను ఉపయోగిస్తేనే ఈ అర్థంలో స్టేట్‌లెస్‌గా ఉంటుంది. మీ రన్‌టైమ్ ఏ వెర్షన్‌ను నెగోషియేట్ చేస్తుందో చదవండి, ఆపై స్పెసిఫికేషన్‌లోని సంబంధిత రివిజన్‌ను చదవండి, మరియు ఈ పేజీని సాధారణ ప్రోటోకాల్‌గా కాకుండా, ఒక నిర్దిష్ట రివిజన్ వివరణగా పరిగణించండి.

FAQ

Stateless MCP సర్వర్ అంటే నేను దేనినీ స్టోర్ చేయలేనా?

లేదు. Stateless అనేది ప్రోటోకాల్‌ను సూచిస్తుంది, మీ అప్లికేషన్‌ను కాదు. డేటాబేస్‌లు, క్యూలు మరియు క్యాచీలు అన్నీ యథావిధిగా పనిచేస్తాయి. మారేది ఏమిటంటే, అనేక కాల్‌లకు విస్తరించే స్టేట్‌ను క్లయింట్ ప్రతి అభ్యర్థనలో పంపే స్పష్టమైన ఐడెంటిఫైయర్ ద్వారా సూచించాలి, ఉదాహరణకు టూల్ ఆర్గ్యుమెంట్‌లో సర్వర్ అందించే హ్యాండిల్. మీరు కనెక్షన్ నుండి సందర్భాన్ని (context) ఊహించకూడదు: సామర్థ్యాలు, ప్రోటోకాల్ వెర్షన్ లేదా క్లయింట్ గుర్తింపును స్థాపించడానికి ఒకే కనెక్షన్‌పై మునుపటి అభ్యర్థనలపై సర్వర్ ఆధారపడకూడదని స్పెసిఫికేషన్ చెబుతోంది, ఎందుకంటే ప్రతి అభ్యర్థన వాటిని _meta లో అందిస్తుంది.

నా లోడ్ బ్యాలెన్సర్‌పై నాకు ఇంకా sticky sessions అవసరమా?

సాధారణ అభ్యర్థనలకు అవసరం లేదు. 2026-07-28 రివిజన్ ప్రకారం, ప్రతి POST దాని స్వంత ప్రోటోకాల్ వెర్షన్, సామర్థ్యాలు మరియు క్రెడెన్షియల్స్‌ను కలిగి ఉంటుంది, కాబట్టి ఏ రెప్లికా అయినా ఏ అభ్యర్థనకైనా సమాధానం ఇవ్వగలదు మరియు రౌండ్-రాబిన్ పద్ధతి సరిపోతుంది. మిగిలి ఉన్న ఏకైక దీర్ఘకాలిక అంశం subscriptions/listen రెస్పాన్స్ స్ట్రీమ్, ఇది ఒకే ప్రాసెస్‌కు ఒకే ఓపెన్ కనెక్షన్. ఆ ప్రాసెస్ ముగిసినప్పుడు ఇది ముగుస్తుంది, మరియు క్లయింట్ దానిని తిరిగి స్థాపించడానికి subscriptions/listen ను మళ్ళీ పంపుతుంది. ఇది సెషన్ అఫినిటీ కంటే కనెక్షన్ లైఫ్‌టైమ్‌కు సంబంధించినది, మరియు ఏ రూటింగ్ రూల్ దీనిని నిరోధించదు.

Mcp-Session-Id మరియు HTTP GET స్ట్రీమ్‌కు ఏమైంది?

SEP-2567 మరియు SEP-2575 ప్రకారం, రెండింటినీ 2026-07-28 రివిజన్‌లో తొలగించారు. ఈ రివిజన్‌ను మాత్రమే అమలు చేసే సర్వర్, MCP ఎండ్‌పాయింట్‌పై 405 Method Not Allowed నుండి GET మరియు DELETE లకు సమాధానం ఇవ్వాలి, మరియు Mcp-Session-Id హెడర్‌ను తిరిగి పంపే బదులు దానిని విస్మరించాలి. సర్వర్ ప్రారంభించే మార్పు నోటిఫికేషన్‌లు ఇప్పుడు స్వతంత్ర GET స్ట్రీమ్‌కు బదులుగా subscriptions/listen అభ్యర్థన యొక్క రెస్పాన్స్ స్ట్రీమ్ ద్వారా ప్రయాణిస్తాయి. పాత క్లయింట్‌లకు సేవలను అందించాల్సిన సర్వర్లు, ఈ రివిజన్‌తో పాటు పాత రివిజన్ ప్రవర్తనను కూడా అమలు చేయాలి.

హ్యాండ్‌షేక్ లేని MCP సర్వర్‌ను హెల్త్ చెక్ చేయడం ఎలా?

రెండు స్థాయిలను ఉపయోగించండి. ప్రాక్సీ యొక్క యాక్టివ్ చెక్‌ను మీ అప్లికేషన్ అందించే సాధారణ HTTP పాత్‌కు పాయింట్ చేయండి, ఎందుకంటే MCP ఎండ్‌పాయింట్‌కు చేసే GET సరిగ్గా 405 ను రిటర్న్ చేస్తుంది మరియు ఆరోగ్యకరమైన బ్యాకెండ్‌ను డౌన్‌గా చూపిస్తుంది. ఆ తర్వాత, ప్రతి 2026-07-28 సర్వర్ తప్పనిసరిగా అమలు చేయాల్సిన server/discover ను POST చేయడం ద్వారా ప్రోటోకాల్‌ను స్వయంగా తనిఖీ చేయండి. సమాధానం HTTP 200 అని మరియు మీ క్లయింట్లు ఉపయోగించే ప్రోటోకాల్ వెర్షన్‌ను కలిగి ఉందని నిర్ధారించుకోండి. JSON-RPC ఎర్రర్ -32601 తో వచ్చే 404 అంటే ప్రాసెస్ రన్ అవుతోంది కానీ ఆ మెథడ్‌ను అందించడం లేదని అర్థం, మరియు -32022 తో వచ్చే 400 అంటే మీరు అడిగిన వెర్షన్ ఆ బిల్డ్ ద్వారా సపోర్ట్ చేయబడటం లేదని అర్థం.