ஆல் Matt Connor 2026-08-07 · புதுப்பிக்கப்பட்டது 2026-08-13

Stateless MCP server என்றால் என்ன? மாற்றங்கள் என்ன?

Q: Load balancer-ல் எனக்கு இன்னும் sticky sessions தேவையா?

சாதாரண கோரிக்கைகளுக்குத் தேவையில்லை. 2026-07-28 திருத்தத்தின்படி, ஒவ்வொரு POST கோரிக்கையும் அதன் சொந்த protocol version, capabilities மற்றும் credentials-ஐக் கொண்டுள்ளது. எனவே, எந்த replica-வும் கோரிக்கைக்குப் பதிலளிக்க முடியும், round-robin முறையும் சரியாகச் செயல்படும். நீண்ட காலம் நீடிக்கும் ஒரே விஷயம் subscriptions/listen response stream ஆகும், இது ஒரு process-க்கான ஒற்றை open connection ஆகும். அந்த process முடிவடையும் போது இதுவும் முடிந்துவிடும், client மீண்டும் subscriptions/listen-ஐ அனுப்பி அதைத் தொடங்க வேண்டும். இது session affinity அல்ல, connection lifetime ஆகும்; இதை எந்த routing விதியும் தடுக்காது.

Q: Mcp-Session-Id மற்றும் HTTP GET stream-க்கு என்ன ஆனது?

SEP-2567 மற்றும் SEP-2575-ன் கீழ், 2026-07-28 திருத்தத்தில் இவை இரண்டும் நீக்கப்பட்டன. இந்தத் திருத்தத்தை மட்டும் செயல்படுத்தும் ஒரு server, MCP endpoint-ல் 405 Method Not Allowed-க்கு GET மற்றும் DELETE எனப் பதிலளிக்க வேண்டும். மேலும், Mcp-Session-Id header-ஐப் புறக்கணிக்க வேண்டும், அதைத் திருப்பி அனுப்பக்கூடாது. Server-ஆல் தொடங்கப்படும் மாற்ற அறிவிப்புகள் (change notifications), தனித்த GET stream-க்கு பதிலாக, subscriptions/listen கோரிக்கையின் response stream வழியாகச் செல்லும். பழைய client-களுக்குச் சேவை வழங்க வேண்டிய server-கள், இந்தத் திருத்தத்துடன் சேர்த்து முந்தைய திருத்தத்தின் செயல்பாட்டையும் செயல்படுத்த வேண்டும்.

MCP 2026-07-28 பதிப்பில் sessions மற்றும் initialize handshake நீக்கப்பட்டுள்ளது. உங்கள் reverse proxy, health checks, timeouts மற்றும் auth ஆகியவற்றில் ஏற்படும் மாற்றங்களை அறியுங்கள்.

Stateless MCP server என்றால் என்ன

Stateless MCP server என்பது கோரிக்கைகளுக்கு (requests) இடையே எந்தவொரு client-ன் நிலையையும் (state) சேமித்து வைப்பதில்லை. ஒவ்வொரு கோரிக்கையிலும் protocol version, client-ன் திறன்கள் (capabilities) மற்றும் பதிலளிக்கத் தேவையான நற்சான்றிதழ்கள் (credentials) ஆகியவை இடம்பெற்றிருக்கும். எனவே, எந்தவொரு கணினியில் உள்ள எந்தவொரு process-ம் ஒரு கோரிக்கைக்குப் பதிலளிக்க முடியும். MCP (Model Context Protocol, முகவர்கள் கருவிகளை அணுகப் பயன்படுத்தும் wire format) தனது 2026-07-28 திருத்தத்தில் இதை ஒரு விதியாக மாற்றியது. இது initialize handshake மற்றும் அதற்கு அடியில் இருந்த HTTP session-ஐ நீக்கியது.

இதுவே இதன் முழுமையான செயல்பாட்டு நோக்கம் ஆகும். ஒவ்வொரு client-க்கும் தனித்தனி நிலையைச் சேமிக்காத ஒரு server-ஐ, session affinity இல்லாத சாதாரண load balancer-க்கு பின்னால் வைக்க முடியும். deploy செய்யும்போது clients-க்கு இடையூறு இல்லாமல் இதை restart செய்ய முடியும். மேலும், ஒரு process-க்கு பதிலாக நான்கு ஒரே மாதிரியான process-களாக இதை இயக்க முடியும். session-ஐ அடிப்படையாகக் கொண்ட ஒரு server, கூடுதல் கட்டமைப்பு இல்லாமல் இவற்றைச் செய்ய முடியாது.

Model Context Protocol என்பது ஒரு stateless protocol ஆகும்: ஒரு கோரிக்கையைச் செயலாக்கத் தேவையான அனைத்துத் தகவல்களும் அந்தக் கோரிக்கையிலேயே அடங்கியிருக்கும். ஒரு server ஒவ்வொரு கோரிக்கையையும் தனித்தனியாகச் செயலாக்குகிறது; முந்தைய கோரிக்கைகளிலிருந்து எந்தவொரு நிலையையும் ஊகிக்கக் கூடாது, அவை ஒரே connection அல்லது stream-ல் வந்திருந்தாலும் சரி.

Stateless என்பது உங்கள் server எதையும் சேமிக்காது என்று அர்த்தமல்ல. உங்கள் database, queue மற்றும் cache ஆகியவை தொடர்ந்து இருக்கும். இதன் பொருள், protocol ஆனது connection-ல் எந்த நிலையையும் சுமந்து செல்வதில்லை என்பதாகும். எனவே, ஒரு connection, process அல்லது open socket-ஐ "இந்த client, உரையாடலின் பாதியில் இருக்கிறார்" என்பதற்கான அடையாளமாக server கருதக்கூடாது.

2026-07-28 பதிப்பில் நீக்கப்பட்டவை

2026-07-28 என்பது ஆகஸ்ட் 2026 நிலவரப்படி இந்த விவரக்குறிப்பின் தற்போதைய பதிப்பாகும். 2025-11-25 உடன் ஒப்பிடும்போது, இது அமர்வுகளை (sessions) ஆதரிப்பதற்காக இருந்த ஐந்து அம்சங்களை நீக்கியுள்ளது.

initialize கோரிக்கை மற்றும் notifications/initialized அறிவிப்பு. இதில் எவ்வித handshake-ம் இல்லை (SEP-2575).
Mcp-Session-Id தலைப்பு (header), மற்றும் 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. லாக் நிலை (log level) இப்போது கோரிக்கை வாரியான புலமாக உள்ளது, இது _meta-ல் io.modelcontextprotocol/logLevel என அழைக்கப்படுகிறது.

ஒரு முறை (method) சேர்க்கப்பட்டுள்ளது, இதை ஒவ்வொரு சர்வர் மென்பொருளும் செயல்படுத்த வேண்டும். server/discover சர்வர் ஆதரிக்கும் புரோட்டோகால் பதிப்புகள், திறன்கள் மற்றும் அடையாளத்தை ஒரே அழைப்பில் வழங்குகிறது. இதுவே எஞ்சியிருக்கும் handshake-க்கு நெருக்கமான அம்சமாகும், மேலும் கிளையண்டுகள் இதை அழைப்பது விருப்பத்திற்குரியது.

Production சூழலில் session transport-ஐ இயக்குவது ஏன் கடினமாக இருந்தது

2025-11-25 மற்றும் அதற்கு முந்தைய பதிப்புகளில், ஒரு server initialization-ன் போது session ID-ஐ உருவாக்கி, அதை InitializeResult-ல் Mcp-Session-Id header மூலம் அனுப்ப முடியும். அதன் பிறகு வரும் ஒவ்வொரு கோரிக்கையிலும் (request) அந்த header-ஐ client அனுப்ப வேண்டியிருந்தது. பேச்சுவார்த்தை நடத்தப்பட்ட protocol பதிப்பு மற்றும் client-ன் திறன்கள் server-ன் நினைவகத்தில் (memory) அந்த ID-ன் கீழ் சேமிக்கப்பட்டன. இந்த ஒவ்வொரு தேர்வும் செயல்பாட்டு ரீதியான செலவுகளைக் கொண்டிருந்தன.

ஒரு restart நிகழ்ந்தால், session table முழுமையாக அழிந்துவிடும். காலாவதியான session ID-ஐக் கொண்ட எந்தவொரு கோரிக்கைக்கும் 404 Not Found மூலம் பதிலளிக்க வேண்டும் என்றும், புதிய InitializeRequest மூலம் client மீண்டும் தொடங்க வேண்டும் என்றும் விவரக்குறிப்பு (specification) கட்டாயப்படுத்தியது. இதனால் ஒவ்வொரு deploy-ம் இணைக்கப்பட்டிருந்த அனைத்து client-களுக்கும் ஒரு reconnect நிகழ்வாக மாறியது.
ஒரு replica-விற்கு மற்றொரு replica-வின் session விவரங்கள் தெரியாது. எனவே, scaling out செய்யும்போது load balancer-ல் sticky routing தேவைப்பட்டது, அல்லது ஒவ்வொரு replica-வும் ஒவ்வொரு கோரிக்கையின் போதும் வாசிக்கும் வகையில் பகிரப்பட்ட session store தேவைப்பட்டது.
session table என்பது idle நிலையில் உள்ள client-களின் எண்ணிக்கையைப் பொறுத்து வளரும் நினைவகமாகும். DELETE என்பது விருப்பத்தேர்வாக இருந்ததால், அதை அனுப்பாமல் connection-ஐ மூடிய client-களின் தரவுகள் நினைவகத்திலேயே தங்கிவிட்டன.
ஒவ்வொரு connection-க்கும் list முடிவுகள் மாறுபடலாம் என்பதால், server-க்கு முன்னால் caching செய்வது பாதுகாப்பற்றதாக இருந்தது.

Session-களை நீக்குவதன் மூலம் இந்த நான்கு சிக்கல்களும் ஒரே நேரத்தில் தீர்க்கப்படுகின்றன. எந்தவொரு configuration-ஐ மாற்றும் முன்பும் இந்த மாற்றத்தைப் புரிந்துகொள்வது அவசியம்.

ஒவ்வொரு கோரிக்கையிலும் இப்போது இடம்பெறுபவை

MCP endpoint-க்கு அனுப்பப்படும் ஒவ்வொரு POST கோரிக்கையும் தனித்தன்மை வாய்ந்தது. Protocol version மற்றும் client capabilities ஆகியவை கோரிக்கையின் உடற்பகுதியில் (request body) _meta-ன் கீழ் இடம்பெறுகின்றன. மேலும், தேர்ந்தெடுக்கப்பட்ட புலங்கள் HTTP headers-ல் பிரதிபலிக்கப்படுகின்றன; இதனால், ஒரு இடைநிலை அமைப்பு (intermediary) JSON-ஐப் பகுப்பாய்வு செய்யாமலேயே அவற்றை வைத்து routing செய்ய முடியும்.

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 கட்டாயமில்லை என்றாலும், clients அதை அனுப்ப வேண்டும். தேவையான புலம் விடுபட்ட ஒரு கோரிக்கை தவறான வடிவமாகக் கருதப்படுகிறது; எனவே, server அதை JSON-RPC error -32602 மற்றும் HTTP 400 Bad Request மூலம் நிராகரிக்க வேண்டும்.

ஒவ்வொரு கோரிக்கையிலும் Mcp-Method header கட்டாயம் இருக்க வேண்டும். tools/call, resources/read மற்றும் prompts/get ஆகியவற்றில் Mcp-Name கட்டாயமாகும். Header-ன் மதிப்பு உடற்பகுதியுடன் ஒத்துப்போக வேண்டும். உடற்பகுதியைச் செயலாக்கும் ஒரு server, முரண்பாடு இருந்தால் அதை 400 Bad Request மற்றும் error code -32020, HeaderMismatch மூலம் நிராகரிக்க வேண்டும். இந்த விதி ஏன் உள்ளது என்றால், header-ஐ வைத்து routing செய்யும் load balancer-ம், உடற்பகுதியைச் செயல்படுத்தும் server-ம் வெவ்வேறு ஆதாரங்களாகச் செயல்படுவதால் ஆகும். இந்த headers-ஐ வைத்து நீங்கள் routing அல்லது rate-limit செய்கிறீர்கள் என்றால், முதலில் MCP-Protocol-Version-ஐச் சரிபார்க்கவும்: முந்தைய பதிப்புகளில் header-க்கும் உடற்பகுதிக்கும் இடையிலான சரிபார்ப்பு இல்லை, எனவே அந்தப் பதிப்புகளில் header-ன் மதிப்பை நம்ப முடியாது.

பதிப்பு முரண்பாடு (Version disagreement) என்பது இப்போது தோல்வியடைந்த handshake-க்கு பதிலாக, ஒரு சாதாரண per-request பிழையாகக் கருதப்படுகிறது. கோரப்பட்ட பதிப்பைச் செயல்படுத்தாத ஒரு server, 400 Bad Request மற்றும் error -32022, UnsupportedProtocolVersion மூலம் பதிலளிக்கும்; மேலும், தான் ஆதரிக்கும் பதிப்புகளை data.supported-ல் பட்டியலிடும். Client அந்தப் பட்டியலிலிருந்து ஒன்றைத் தேர்ந்தெடுத்து மீண்டும் முயற்சிக்கும்.

நிலைத் தரவுகள் சென்ற இடம்: tokens, cursors, subscriptions

நிலைத் தரவுகள் (state) மறையவில்லை. அவை நீங்கள் பார்க்கக்கூடிய மற்றும் பதிவு செய்யக்கூடிய இடங்களுக்கு நகர்த்தப்பட்டுள்ளன.

Credentials ஒவ்வொரு கோரிக்கையிலும் (request) இடம்பெறுகின்றன. அடையாளத்தை இணைக்க session இல்லாததால், access token ஒவ்வொரு HTTP அழைப்பிலும் உடன் சென்று, ஒவ்வொரு முறையும் சரிபார்க்கப்படுகிறது. இது குறித்த விவரங்கள் கீழே உள்ள authentication பகுதியில் உள்ளன.

Cursors அவற்றின் நிலையைத் தாங்களே கொண்டிருக்க வேண்டும். tools/list, resources/list, prompts/list மற்றும் resources/templates/list ஆகியவற்றில் pagination செய்யும்போது, opaque cursor string பயன்படுத்தப்படுகிறது. இதை client-கள் பகுப்பாய்வு செய்யவோ அல்லது மாற்றவோ கூடாது. ஒரே process-ல் இயங்கும் server-ல், session-ஐ அடிப்படையாகக் கொண்டு offset-ஐ memory-ல் வைத்திருப்பது வழக்கமாக இருந்தது. இப்போது session இல்லாததால், எந்தவொரு replica-வும் பட்டியலைத் தொடர அந்த cursor போதுமானதாக இருக்க வேண்டும். எனவே, நிலையை cursor-க்குள் encode செய்து sign செய்யவும், அல்லது அனைத்து replica-களும் பகிரும் storage-ல் சேமிக்கவும். செல்லாத cursor-க்கு -32602 பிழையைத் திருப்பியளிக்க வேண்டும். Opaque cursor என்பது client வழங்கும் உள்ளீடு என்பதால், உங்கள் code அதை decode செய்து நம்புவதற்கு முன்பு அதை sign செய்வது அவசியம்.

Subscriptions ஒரு connection-ஐச் சாராமல், கோரிக்கையைச் (request) சார்ந்து இருக்கும். மாற்றங்கள் குறித்த அறிவிப்புகளைப் பெற விரும்பும் client, தனக்குத் தேவையான வகைகளைக் குறிப்பிட்டு subscriptions/listen-ஐ அனுப்ப வேண்டும்: toolsListChanged, promptsListChanged, resourcesListChanged மற்றும் resourceSubscriptions. Server notifications/subscriptions/acknowledged மூலம் பதிலளித்து, அந்த response stream-ஐத் திறந்து வைத்திருக்கும். stream துண்டிக்கப்பட்டால், server எதையும் சேமித்து வைக்காது; client மீண்டும் subscriptions/listen-ஐ அனுப்பி அதைப் பெற்றுக்கொள்ள வேண்டும்.

அழைப்புகளுக்கு இடையிலான application நிலை, ஒரு வெளிப்படையான handle-ஆக மாறுகிறது. அழைப்புகளுக்கு இடையில் server ஏதேனும் ஒரு தகவலை நினைவில் கொள்ள வேண்டிய கட்டாயம் ஏற்படும்போது, specification-ன் தீர்வு, server உருவாக்கிய identifier-ஐ ஒரு சாதாரண tool argument-ஆகத் திருப்பி அனுப்புவதாகும். இது tool schema-வில் தோன்றும், இதை log செய்ய முடியும், மேலும் இது connection மூலம் மறைமுகமாகத் தீர்மானிக்கப்படுவதில்லை. self-hosted MCP email server போன்ற பயனர் தரவுகளைக் கொண்ட server, session-க்கு பதிலாக இந்த முறையைப் பயன்படுத்துகிறது: mailbox அல்லது draft identifier ஒரு tool argument-ஆக இருப்பதால், எந்தவொரு replica-வும் அடுத்த அழைப்பை எடுத்துக்கொள்ள முடியும். பல tool-களுக்கு handle தேவையே இல்லை: SearXNG instance மூலம் இயங்கும் search tool, ஒரு query-ஐப் பெற்று முடிவுகளைத் தருகிறது. இதில் அடுத்த அழைப்பிற்காக எதையும் சேமிக்க வேண்டியதில்லை, எந்த replica பதிலளித்தது என்பதில் அக்கறையும் தேவையில்லை.

Deployment: reverse proxy, timeouts, health checks

MCP endpoint என்பது POST-ஐ ஏற்கும் ஒரு பாதையாகும். பெரும்பாலான traffic என்பது குறுகிய கோரிக்கைகள் மற்றும் JSON பதில்களாக இருப்பதால், எந்தவொரு proxy-யும் இதை எளிதாகக் கையாளும். ஆனால் streaming response-ல் proxy-ன் இயல்புநிலை அமைப்புகள் உங்களுக்கு எதிராகச் செயல்படலாம். லேப்டாப் டெமோவிலிருந்து VPS-ல் இயங்கும் MCP server-க்கு மாறும்போது இந்த அம்சம் முக்கியமானது.

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 இயல்பாகவே proxied பதில்களை buffer செய்யும். இது SSE நிகழ்வுகளை buffer நிரம்பும் வரை அல்லது பதில் முடியும் வரை நிறுத்தி வைக்கும். SSE பதில்களில் X-Accel-Buffering: no-ஐ அனுப்ப வேண்டும் என்று விவரக்குறிப்பு (specification) கூறுகிறது. nginx அந்த header-ஐ மதிப்பதால், சரியான server உங்கள் proxy-க்குத் தேவையானதைச் சொல்லிவிடும். இருப்பினும், அந்த directive-ஐ நீங்களே அமைப்பது நல்லது, ஏனெனில் அது உங்கள் கட்டுப்பாட்டில் உள்ள பகுதி.

proxy_read_timeout இயல்பாக 60 வினாடிகளாக இருக்கும். ஒரு subscriptions/listen stream நீண்ட நேரம் அமைதியாக இருந்தால், அதை உங்கள் server அல்ல, nginx-தான் துண்டிக்கும். இதனால் உங்கள் logs-ல் process ஆரோக்கியமாகத் தெரியும், ஆனால் client-ல் stream துண்டிக்கப்பட்டிருக்கும். இதை முழு server-க்கும் மாற்றாமல், MCP location-க்கு மட்டும் அதிகரிக்கவும். அமைதியான நேரங்களில் keep-alive-ஆக SSE comment line-ஐ (colon-ல் தொடங்கும் வரி) அனுப்ப server-களுக்கு அறிவுறுத்தப்படுகிறது; இது இடைத்தரகர்கள் stream-ஐத் துண்டிப்பதைத் தடுக்கும்.

Caddy-க்குக் குறைவான அமைப்புகளே தேவை. இது wire efficiency-க்காகப் பகுதியளவு buffer செய்யும், மேலும் பதில் Content-Type: text/event-stream-ஐக் கொண்டிருக்கும்போது உடனடியாக flush செய்யும். எனவே, கூடுதல் directive-கள் இல்லாமலேயே streaming சரியாகச் செயல்படும்.

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

அந்த health check எதை நோக்கியுள்ளது என்பதைக் கவனிக்கவும். MCP endpoint-ல் GET-ஐப் பயன்படுத்தி active check செய்ய வேண்டாம். ஏனெனில், இந்த revision-ஐ மட்டும் செயல்படுத்தும் server, GET மற்றும் DELETE-க்கு 405 Method Not Allowed என்று பதிலளிக்கும். Caddy-ன் இயல்புநிலை health method GET ஆகும். இதனால், சரியாக இயங்கும் backend-ஐ proxy செயலிழந்ததாகக் கருதிவிடும். proxy-க்காக /healthz போன்ற ஒரு எளிய பாதையை உருவாக்கி, protocol-ஐத் தனித்தனியாக 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 என்பது process இயங்குவதையும், protocol-ஐப் பேசுவதையும் குறிக்கிறது. JSON-RPC error -32601 கொண்ட 404 என்பது, process இயங்குகிறது ஆனால் server/discover-ஐ வழங்கவில்லை என்று பொருள். இதை ஒவ்வொரு 2026-07-28 server-ம் செயல்படுத்த வேண்டும். -32022 கொண்ட 400 என்பது, உங்கள் checker இந்த build ஆதரிக்காத ஒரு version-ஐக் கேட்டுள்ளது என்று பொருள். dependency upgrade செய்த பிறகு இதைக் கண்டறிவது அவசியம். Open source nginx-ல் active health checks இல்லை, எனவே upstream-ல் passive max_fails மற்றும் fail_timeout-ஐப் பயன்படுத்தவும், protocol check-ஐ உங்கள் monitoring மூலம் இயக்கவும்.

Rolling restart செய்யும்போது, தற்போது செயல்பாட்டில் உள்ள கோரிக்கைகள் மட்டுமே பாதிக்கப்படும். Drain செய்து, திறந்திருக்கும் POST-கள் முடிவடையும் வரை காத்திருந்து, புதிய process-ஐத் தொடங்கவும்; தோல்வியடைந்த கோரிக்கைகளை client மீண்டும் அனுப்பும். நீங்கள் இழக்கும் ஒரே விஷயம் திறந்திருக்கும் subscriptions/listen stream ஆகும், ஏனெனில் அந்த stream ஒரு குறிப்பிட்ட process-க்கான நேரடித் தொடர்பாகும். Statelessness என்பது session affinity-ஐ நீக்கியது, ஆனால் தற்போது திறந்திருக்கும் stream-க்கான connection affinity-ஐ அது நீக்கவில்லை; எந்த routing rule-ஆலும் இதைச் சரிசெய்ய முடியாது. ஒரு client இதை வேறுபடுத்தி அறிய முடியும்: காலியான subscriptions/listen result-டன் முடியும் stream சரியாக முடிவடைந்தது, அது இல்லாமல் முடியும் stream துண்டிக்கப்பட்டது. துண்டிக்கப்பட்ட stream-ஐக் கண்டால் client மீண்டும் இணைய முயற்சிக்கும்.

இப்போது முதன்முறையாக caching சாத்தியமாகிறது. list முறைகளின் முடிவுகள் இப்போது ttlMs மற்றும் cacheScope-ஐக் கொண்டிருக்கும், மேலும் cacheScope: "public" என்பது பகிரப்பட்ட இடைத்தரகர்கள் அந்தப் பதிலைக் cache செய்யலாம் என்று கூறுகிறது. sessions நீக்கப்பட்டதால் list முடிவுகள் ஒவ்வொரு connection-க்கும் மாறுபடாது, எனவே இது பாதுகாப்பானது.

session இல்லாதபோது authentication ஏன் மாறுகிறது

Session இருக்கும்போது, initialize-ல் ஒருமுறை authenticate செய்துவிட்டு, அதன் பிறகு வரும் அனைத்திற்கும் session ID-யையே ஆதாரமாகக் கருதுவது எளிதாக இருந்தது. அவ்வாறு பயன்படுத்தப்படும் session ID என்பது audience, காலாவதி தேதி (expiry) அல்லது ரத்து செய்யும் வழிமுறை (revocation path) இல்லாத, உங்கள் server-ஆலேயே உருவாக்கப்பட்ட ஒரு bearer credential ஆகும். Session-களை நீக்குவது அந்த குறுக்குவழியை நீக்குகிறது, அதற்குப் பதிலாக வரும் முறை மிகவும் கடுமையானது.

பாதுகாக்கப்பட்ட ஒரு MCP server, OAuth 2.1 resource server-ஆகச் செயல்படுகிறது. Client-லிருந்து வரும் ஒவ்வொரு HTTP request-லும் Authorization: Bearer <access token> இருக்க வேண்டும், மேலும் ஒவ்வொரு request-லும் server அந்த token-ஐச் சரிபார்க்கும். இந்தச் சரிபார்ப்பில் audience-ம் அடங்கும்: RFC 8707 (Resource Indicators for OAuth 2.0)-ன் படி, அந்த token தனக்காகவே வழங்கப்பட்டது என்பதை server உறுதிப்படுத்த வேண்டும்; மற்ற எதற்கோ வழங்கப்பட்ட token-களை ஏற்கவோ அல்லது கடத்தவோ கூடாது. Server-ன் canonical URI-ஐக் கொண்டு resource parameter-ஐ அனுப்புவதன் மூலம், client சரியான audience-ஐக் கோருகிறது.

Discovery ஒரு challenge மூலம் இயங்குகிறது. பயன்படுத்தக்கூடிய token இல்லாத request வரும்போது, server 401 Unauthorized மூலம் பதிலளிக்கும்.

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

Client resource_metadata-ஐப் படித்து, அந்த ஆவணத்தைப் பெற்று (RFC 9728, OAuth 2.0 Protected Resource Metadata, இதை MCP server-கள் செயல்படுத்த வேண்டும்), authorization server-ஐக் கண்டறிந்து flow-வை இயக்கும். போதிய அனுமதிகள் இல்லாத செல்லுபடியாகும் token-க்கு, error="insufficient_scope" மற்றும் அந்தச் செயல்பாட்டிற்குத் தேவையான scopes-உடன் 403 Forbidden பதில் கிடைக்கும்.

இதை நீங்கள் இயக்கும் விதத்தில் இரண்டு விளைவுகள் உள்ளன. Token சரிபார்ப்பு இப்போது ஒவ்வொரு session-க்கும் ஒருமுறை என்பதற்குப் பதிலாக, ஒவ்வொரு request-லும் நடக்கும். எனவே, ஒவ்வொரு அழைப்பிற்கும் introspection endpoint-க்குச் செல்லும் network round trip உங்கள் latency-ல் பிரதிபலிக்கும்: signature, audience மற்றும் expiry ஆகியவற்றைக் கொண்டு உள்ளூர் அளவில் சரிபார்க்கக்கூடிய token-களைப் பயன்படுத்தவும், அல்லது token-ஐக் கொண்டு சரிபார்ப்பு முடிவைச் சிறிய கால இடைவெளிக்கு cache செய்யவும். மேலும், அடையாளத்தைத் தக்கவைக்கும் session இல்லாததால், ஒவ்வொரு அழைப்பிலும் token-லிருந்து authorization கணக்கிடப்பட வேண்டும். இது session மாதிரியை விட நேர்மையானது, மேலும் இது agent process-க்குள் credentials-ஐ வைக்காத பரவலான நடைமுறையுடன் ஒத்துப்போகிறது. இது AI agent-க்குள் ரகசியங்களை வைக்காமல் இருப்பது பகுதியில் விவரிக்கப்பட்டுள்ளது.

இந்தத் திருத்தம் எதைக் குறிக்கிறது, எதைக் குறிக்கவில்லை

மேலே உள்ள அனைத்தும் 2026-07-28 திருத்தத்தை மட்டுமே விவரிக்கின்றன. இது MCP-ஐ நிரந்தரமாக விவரிக்கவில்லை, மேலும் கடந்த ஆண்டு நீங்கள் deploy செய்த server-ஐயும் இது குறிக்கவில்லை.

2025-11-25 மற்றும் அதற்கு முந்தைய பதிப்புகளில் உள்ள clients மற்றும் servers இன்னும் handshake மாதிரியையே பயன்படுத்துகின்றன. இந்த விவரக்குறிப்பு (specification) அந்தத் திருத்தங்களை legacy என்றும், per-request-metadata திருத்தங்களை modern என்றும் அழைக்கிறது. இந்தத் திருத்தத்தை மட்டுமே ஆதரிக்கும் ஒரு server, பழைய client-ஐச் சந்திக்கும்போது, MCP endpoint-ல் 405 Method Not Allowed-க்கு GET அல்லது DELETE மூலம் பதிலளிக்க வேண்டும். எந்தவொரு Mcp-Session-Id header-ஐயும் உருவாக்காமலோ அல்லது echo செய்யாமலோ புறக்கணிக்க வேண்டும். மேலும், streams-ஐ மீண்டும் தொடங்க முடியாது என்பதால் Last-Event-ID-ஐயும் புறக்கணிக்க வேண்டும். ஒரு dual-era server ஒரே endpoint-ல் இரண்டையும் வழங்கலாம்: நவீன _meta-ஐக் கொண்ட கோரிக்கை stateless முறையில் கையாளப்படும், அதே சமயம் initialize கோரிக்கை பழைய session முறையைத் தேர்ந்தெடுக்கும்.

எனவே, இதில் எதையும் நம்புவதற்கு முன் revision string-ஐச் சரிபார்க்கவும். உங்கள் SDK இன்னும் initialize-ஐ அனுப்புகிறது என்றால், உங்கள் deployment-ல் sessions இன்னும் செயல்பாட்டில் உள்ளன என்று அர்த்தம்; மேலே குறிப்பிடப்பட்ட session தொடர்பான சிக்கல்களை நீங்களே நிர்வகிக்க வேண்டும். இது client பக்கத்திற்கும் பொருந்தும்: running a coding agent on a VPS-ல் உள்ளதைப் போன்ற உங்கள் சொந்த கணினியில் இயங்கும் ஒரு agent process, அது பயன்படுத்தும் library ஒரு நவீன திருத்தத்தைப் பேசினால் மட்டுமே இந்த அர்த்தத்தில் stateless ஆகும். உங்கள் runtime எந்தப் பதிப்பை negotiate செய்கிறது என்பதைப் படியுங்கள், பின்னர் விவரக்குறிப்பின் தொடர்புடைய திருத்தத்தைப் படியுங்கள். இந்தப் பக்கத்தை ஒட்டுமொத்த protocol-ஆகக் கருதாமல், ஒரு குறிப்பிட்ட திருத்தத்தை விவரிக்கும் ஆவணமாகக் கருதவும்.

FAQ

Stateless MCP server என்றால் என்னால் எதையும் சேமிக்க முடியாதா?

முடியாது. Stateless என்பது protocol-ஐ மட்டுமே குறிக்கும், உங்கள் application-ஐ அல்ல. Databases, queues மற்றும் caches ஆகியவை எப்போதும் போலச் செயல்படும். மாறாக, பல அழைப்புகளுக்கு இடையே உள்ள state-ஐ பராமரிக்க, ஒவ்வொரு கோரிக்கையிலும் client அனுப்பும் ஒரு குறிப்பிட்ட identifier-ஐப் பயன்படுத்த வேண்டும் (உதாரணமாக, tool argument-ல் உள்ள server உருவாக்கிய handle). Connection-ஐ வைத்து சூழலை (context) ஊகிக்கக்கூடாது: ஒரே connection-ல் முந்தைய கோரிக்கைகளை வைத்து capabilities, protocol version அல்லது client identity-ஐத் தீர்மானிக்கக்கூடாது என்று specification கூறுகிறது. ஏனெனில், ஒவ்வொரு கோரிக்கையும் _meta-ல் அந்தத் தகவல்களை வழங்குகிறது.

Load balancer-ல் எனக்கு இன்னும் sticky sessions தேவையா?

சாதாரண கோரிக்கைகளுக்குத் தேவையில்லை. 2026-07-28 திருத்தத்தின்படி, ஒவ்வொரு POST கோரிக்கையும் அதன் சொந்த protocol version, capabilities மற்றும் credentials-ஐக் கொண்டுள்ளது. எனவே, எந்த replica-வும் கோரிக்கைக்குப் பதிலளிக்க முடியும், round-robin முறையும் சரியாகச் செயல்படும். நீண்ட காலம் நீடிக்கும் ஒரே விஷயம் subscriptions/listen response stream ஆகும், இது ஒரு process-க்கான ஒற்றை open connection ஆகும். அந்த process முடிவடையும் போது இதுவும் முடிந்துவிடும், client மீண்டும் subscriptions/listen-ஐ அனுப்பி அதைத் தொடங்க வேண்டும். இது session affinity அல்ல, connection lifetime ஆகும்; இதை எந்த routing விதியும் தடுக்காது.

Mcp-Session-Id மற்றும் HTTP GET stream-க்கு என்ன ஆனது?

SEP-2567 மற்றும் SEP-2575-ன் கீழ், 2026-07-28 திருத்தத்தில் இவை இரண்டும் நீக்கப்பட்டன. இந்தத் திருத்தத்தை மட்டும் செயல்படுத்தும் ஒரு server, MCP endpoint-ல் 405 Method Not Allowed-க்கு GET மற்றும் DELETE எனப் பதிலளிக்க வேண்டும். மேலும், Mcp-Session-Id header-ஐப் புறக்கணிக்க வேண்டும், அதைத் திருப்பி அனுப்பக்கூடாது. Server-ஆல் தொடங்கப்படும் மாற்ற அறிவிப்புகள் (change notifications), தனித்த GET stream-க்கு பதிலாக, subscriptions/listen கோரிக்கையின் response stream வழியாகச் செல்லும். பழைய client-களுக்குச் சேவை வழங்க வேண்டிய server-கள், இந்தத் திருத்தத்துடன் சேர்த்து முந்தைய திருத்தத்தின் செயல்பாட்டையும் செயல்படுத்த வேண்டும்.

Handshake இல்லாத MCP server-ஐ எப்படி health check செய்வது?

இரண்டு நிலைகளைப் பயன்படுத்தவும். Proxy-ன் active check-ஐ உங்கள் application வழங்கும் ஒரு சாதாரண HTTP path-க்குச் சுட்டிக்காட்டவும். ஏனெனில், MCP endpoint-க்கு அனுப்பப்படும் GET சரியாக 405 எனப் பதிலளிக்கும், இது ஆரோக்கியமான backend-ஐத் தவறாக 'down' எனக் காட்டும். பிறகு, ஒவ்வொரு 2026-07-28 server-ம் செயல்படுத்த வேண்டிய server/discover-ஐ POST செய்து protocol-ஐச் சரிபார்க்கவும். பதில் HTTP 200 ஆகவும், உங்கள் client பயன்படுத்தும் protocol version-ஐக் கொண்டிருப்பதாகவும் இருப்பதை உறுதி செய்யவும். JSON-RPC error -32601 உடன் வரும் 404, அந்த process இயங்குகிறது ஆனால் அந்த method-ஐ வழங்கவில்லை என்று பொருள். -32022 உடன் வரும் 400, நீங்கள் கேட்ட version அந்த build-ல் ஆதரிக்கப்படவில்லை என்று பொருள்.

#mcp #ai-agents #self-hosting#protocol#http

Built for exactly this: a fresh Ubuntu 24.04 KVM VPS with root.

SSD Nodes-ன் 15 ஆண்டுகள், அனைத்திற்கும் 15% தள்ளுபடி: எந்தத் திட்டமும், எந்தக் கட்டணச் சுழற்சியும், புதிய மற்றும் ஏற்கனவே உள்ள வாடிக்கையாளர்களும். முழு root access, 4TB தரவு பரிமாற்றம், 14 நாள் பணம் திரும்பப் பெறும் உத்தரவாதம்.

செலுத்தும் பக்கத்தில் LEARN15 குறியீடு உங்களுக்காகப் பயன்படுத்தப்படும்.

எனது 15% தள்ளுபடியைப் பெறுக →