MCP ਦੀ ਜੁਲਾਈ 2026 ਦੀ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਪ੍ਰੋਟੋਕੋਲ ਲੇਅਰ ਤੋਂ ਸੈਸ਼ਨ ਸਟੇਟ (session state) ਦੇ ਹਰ ਰੂਪ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਸਾਰੀ ਸਟੇਟ ਮਾਡਲ ਦੇ ਕੰਟੈਕਸਟ ਵਿੰਡੋ (context window) ਦੇ ਅੰਦਰ ਰਹਿਣ ਲਈ ਮਜਬੂਰ ਹੋ ਜਾਂਦੀ ਹੈ। ਇਹ ਤਬਦੀਲੀ ਕਿਸੇ ਵੀ MCP ਸਰਵਰ ਨੂੰ ਕੋਈ ਵੀ ਰਿਕੁਐਸਟ ਜਵਾਬ ਦੇਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਲੋਡ ਬੈਲੇਂਸਰਾਂ (load balancers), ਸਰਵਰਲੈੱਸ ਫੰਕਸ਼ਨਾਂ (serverless functions) ਅਤੇ ਆਟੋਸਕੇਲਿੰਗ Kubernetes ਪੌਡਸ (pods) ਦੇ ਪਿੱਛੇ ਸ਼ੁੱਧ-ਸਟੇਟਲੈੱਸ (pure-stateless) ਤੈਨਾਤੀਆਂ ਲਈ ਰਾਹ ਖੁੱਲ੍ਹ ਜਾਂਦੇ ਹਨ।

ਇਹ ਤਬਦੀਲੀ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

ਆਪਣੀ ਪਹਿਲੀ ਰਿਲੀਜ਼ ਤੋਂ ਹੀ, MCP (Model Communication Protocol) ਨੇ ਕਈ HTTP ਕਾਲਾਂ ਵਿੱਚ ਗੱਲਬਾਤ ਦੀ ਸਟੇਟ ਨੂੰ ਟ੍ਰੈਕ ਕਰਨ ਲਈ ਇੱਕ ਹਲਕਾ-ਫੁਲਕਾ ਸੈਸ਼ਨ ਹੈਂਡਸ਼ੇਕ (session handshake) ਅਤੇ ਇੱਕ Mcp-Session-Id ਹੈਡਰ ਰੱਖਿਆ ਸੀ। ਉਸ ਡਿਜ਼ਾਈਨ ਨੇ ਸਰਵਰ ਨੂੰ ਇਹ ਯਾਦ ਰੱਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਕਿ ਕਿਹੜੇ ਟੂਲ ਹੈਂਡਲ (tool handles), ਸੈਂਪਲਿੰਗ ਰੇਟ (sampling rates) ਜਾਂ ਲੌਗਿੰਗ ਪਸੰਦ ਇੱਕ ਦਿੱਤੇ ਗਏ ਕਲਾਇੰਟ ਨਾਲ ਸਬੰਧਤ ਸਨ। ਇਸ ਨੇ ਰੀਜ਼ਿਊਮੇਬਲ (resumable) Server-Sent Events (SSE) ਸਟ੍ਰੀਮਾਂ ਵੀ ਪ੍ਰਦਾਨ ਕੀਤੀਆਂ, ਤਾਂ ਜੋ ਟੁੱਟਿਆ ਹੋਇਆ ਕਨੈਕਸ਼ਨ ਉੱਥੋਂ ਹੀ ਸ਼ੁਰੂ ਹੋ ਸਕੇ ਜਿੱਥੇ ਉਹ ਰੁਕਿਆ ਸੀ।

28 ਜੁਲਾਈ, 2026 ਦੀ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਸੈਸ਼ਨ ਹੈਂਡਸ਼ੇਕ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਤਮ ਕਰ ਦਿੰਦੀ ਹੈ। ਹੁਣ ਹਰ ਰਿਕੁਐਸ _meta ਫੀਲਡ ਵਿੱਚ ਪ੍ਰੋਟੋਕੋਲ ਵਰਜ਼ਨ ਅਤੇ ਕਲਾਇੰਟ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਲੈ ਕੇ ਜਾਂਦੀ ਹੈ, ਅਤੇ Mcp-Session-Id ਹੈਡਰ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ। Roots, sampling ਅਤੇ logging ਫੀਲਡਸ ਨੂੰ ਡਿਪ੍ਰਿਕੇਟਡ (deprecated) ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਸੰਖੇਪ ਵਿੱਚ, ਵਾਇਰ ਪ੍ਰੋਟੋਕੋਲ ਹੁਣ ਸ਼ੁੱਧ ਰਿਕੁਐਸ-ਰਿਸਪਾਂਸ (request-response) ਹੈ; ਇਸ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਲਈ ਕੋਈ "ਸੈਸ਼ਨ" ਨਹੀਂ ਹੈ।

ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਕੀ ਵੱਖਰਾ ਕਰਨਾ ਪਵੇਗਾ

ਸਟੇਟ ਹੁਣ ਸਰਵਰ ਦੀ ਚਿੰਤਾ ਨਹੀਂ ਰਹੀ; ਇਹ ਮਾਡਲ ਦੇ ਕੰਟੈਕਸਟ ਵਿੰਡੋ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ। ਜਦੋਂ ਕਿਸੇ ਮਾਡਲ ਨੂੰ ਕਿਸੇ ਬਾਹਰੀ ਸਰੋਤ (external resource) ਦਾ ਹਵਾਲਾ ਦੇਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਉਸ ਨੂੰ ਟੂਲ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਸਰਵਰ ਤੋਂ ਇੱਕ ਸਪੱਸ਼ਟ ਹੈਂਡਲ (explicit handle) ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਅਗਲੀ ਰਿਕੁਐਸ ਉਸ ਹੈਂਡਲ ਨੂੰ ਇੱਕ ਆਰਗੂਮੈਂਟ ਵਜੋਂ ਸ਼ਾਮਲ ਕਰਦੀ ਹੈ, ਅਤੇ ਮਾਡਲ ਇਸ ਨਾਲ ਕਿਸੇ ਹੋਰ ਟੋਕਨ ਵਾਂਗ ਸਲੂਕ ਕਰਦਾ ਹੈ।

ਕਿਉਂਕਿ ਕੰਟੈਕਸਟ ਵਿੰਡੋ ਇੱਕ ਨਿਸ਼ਚਿਤ-ਆਕਾਰ ਦਾ ਟੋਕਨ ਬਫਰ (token buffer) ਹੈ, ਹਰੇਕ ਹੈਂਡਲ ਉਹ ਜਗ੍ਹਾ ਵਰਤਦਾ ਹੈ ਜੋ ਯੂਜ਼ਰ ਪ੍ਰੋਂਪਟ ਜਾਂ ਮਾਡਲ ਆਊਟਪੁੱਟ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦੀ ਹੈ।

ਭਰੋਸੇਯੋਗਤਾ (Reliability) ਵੀ ਬਦਲ ਜਾਂਦੀ ਹੈ। SSE ਰੀਜ਼ਿਊਮੇਬਿਲਟੀ (resumability) ਜਾਂ ਮੈਸੇਜ ਰੀ-ਡਿਲੀਵਰੀ ਤੋਂ ਬਿਨਾਂ, ਇੱਕ ਟੁੱਟੀ ਹੋਈ ਸਟ੍ਰੀਮ ਪੂਰੀ ਰਿਕੁਐਸ ਨੂੰ ਗੁਆ ਦਿੰਦੀ ਹੈ। ਕਲਾਇੰਟਸ ਨੂੰ ਕਾਲ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨਾ ਪਵੇਗਾ। ਤੇਜ਼, ਸਟੇਟਲੈੱਸ ਕੁਐਰੀਆਂ ਲਈ ਇਹ ਸਵੀਕਾਰਯੋਗ ਹੈ; ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੀ ਰਿਟ੍ਰੀਵਲ (retrieval) ਜਾਂ ਮਲਟੀ-ਸਟੈਪ ਏਜੰਟ ਕੰਮਾਂ ਲਈ, ਇਹ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਆਪਣਾ ਰੀਟ੍ਰਾਈ ਲੌਜਿਕ (retry logic) ਬਣਾਉਣ ਜਾਂ ਕੰਮ ਨੂੰ ਛੋਟੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ।

Pilot Protocol ਇਸ ਕਮੀ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ

MCP ਦੀ ਸਟੇਟਲੈੱਸਤਾ ਜਾਣਬੁੱਝ ਕੇ ਕੀਤੀ ਗਈ ਹੈ, ਪਰ ਇਹ ਨੈੱਟਵਰਕ ਲੇਅਰ ਨੂੰ ਕਨੈਕਸ਼ਨ-ਲੇਵਲ ਦੀ ਪਛਾਣ ਜਾਂ ਭਰੋਸੇਯੋਗਤਾ ਦੀ ਗਾਰੰਟੀ ਤੋਂ ਬਿਨਾਂ ਛੱਡ ਦਿੰਦੀ ਹੈ। Pilot Protocol, ਜੋ MCP ਦੇ ਹੇਠਾਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਉਸ ਕਮੀ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ। Pilot ਇੱਕ ਵਾਰ ਪਛਾਣ ਸਥਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਪੈਕੇਟਾਂ ਨੂੰ ਭੇਜਣ ਵਾਲੇ ਨਾਲ ਜੋੜਨ ਲਈ ਐਨਕ੍ਰਿਪਸ਼ਨ (encryption) ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। MCP ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ, ਕਲਾਇੰਟ ਹਰ ਵਾਰ ਸਿਰਫ਼ ਇੱਕ ਨਵੀਂ HTTP ਰਿਕੁਐਸ ਭੇਜਦਾ ਹੈ; Pilot ਅੰਡਰਲਾਇੰਗ ਟ੍ਰਾਂਸਪੋਰਟ (underlying transport) ਨੂੰ ਸਥਿਰ ਰੱਖਦਾ ਹੈ।

ਦੋਵੇਂ ਪ੍ਰੋਟੋਕੋਲ ਇੱਕ ਦੂਜੇ ਦੇ ਪੂਰਕ ਹਨ: MCP ਹਲਕਾ, ਪ੍ਰਤੀ ਰਿਕੁਐਸ ਸਸਤਾ ਅਤੇ ਕਿਸੇ ਵੀ HTTP ਐਂਡਪੁਆਇੰਟ ਦੇ ਪਿੱਛੇ ਸਕੇਲ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਰਹਿੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ Pilot ਉਹ ਭਾਰੀ ਕੰਮ ਸੰਭਾਲਦਾ ਹੈ ਜੋ ਰਵਾਇਤੀ ਸੈਸ਼ਨ-ਅਧਾਰਤ ਪ੍ਰੋਟੋਕੋਲ ਪ੍ਰਦਾਨ ਕਰਦੇ ਸਨ।

ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਲਾਭ

  • Load-balancer ਅਨੁਕੂਲ – ਕਿਸੇ ਸੈਸ਼ਨ ਅਫਿਨਿਟੀ (session affinity) ਦੀ ਲੋੜ ਨਹੀਂ; ਕੋਈ ਵੀ ਬੈਕਐਂਡ ਕਿਸੇ ਵੀ ਰਿਕੁਐਸ ਨੂੰ ਸੇਵਾ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦਾ ਹੈ।
  • Serverless ਲਈ ਤਿਆਰ – ਫੰਕਸ਼ਨ ਮੰਗ 'ਤੇ ਚਾਲੂ ਹੋ ਸਕਦੇ ਹਨ, ਇੱਕ ਰਿਕੁਐਸ ਨੂੰ ਸੰਭਾਲ ਸਕਦੇ ਹਨ, ਅਤੇ ਬਿਨਾਂ ਕਿਸੇ ਬਾਕੀ ਰਹਿ ਗਈ ਸਟੇਟ ਦੇ ਬੰਦ ਹੋ ਸਕਦੇ ਹਨ।
  • Kubernetes ਆਟੋਸਕੇਲਿੰਗ – ਪੌਡਸ ਨੂੰ ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਜੋੜਿਆ ਜਾਂ ਹਟਾਇਆ ਜਾ