MCP ವರ್ಷ 2 ಜುಲೈ 28, 2026 ರಂದು ಲಭ್ಯವಾಗಲಿದೆ. ಇದು ಪ್ರತಿಯೊಂದು handshake, session-ID header ಮತ್ತು Model Context Protocol (MCP) ಅನ್ನು sticky-session ಸರ್ವರ್‌ಗಳಿಗೆ ಕೊಂಡಿಕೆಯಲ್ಲಿರಿಸಿದ್ದ ಮೂರು legacy subsystems ಗಳನ್ನು ಕೈಬಿಡುತ್ತದೆ. ಈ ಪ್ರೊಟೊಕಾಲ್ ಸಂಪೂರ್ಣವಾಗಿ stateless ಆಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾವುದೇ autoscaled ಅಥವಾ serverless instance ಯಾವುದೇ ಕ್ಲೈಂಟ್ ಸ್ಟೇಟ್ ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳದೆ ಯಾವುದೇ ವಿನಂತಿಯನ್ನು (request) ನಿರ್ವಹಿಸಬಹುದು.

ಈ ಬದಲಾವಣೆ ಏಕೆ ಮುಖ್ಯ

MCP v1 ನಲ್ಲಿ, ಕ್ಲೈಂಟ್ initialize handshake ಮೂಲಕ ಸೆಷನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಬೇಕಾಗಿತ್ತು; ನಂತರ ಸರ್ವರ್ Mcp-Session-Id ಅನ್ನು ನಿಯೋಜಿಸುತ್ತಿತ್ತು. ನಂತರದ ಪ್ರತಿಯೊಂದು ಕರೆಯನ್ನು (call) ಆ ಹೆಡರ್ ಅನ್ನು ಹೊಂದಿರಬೇಕಿತ್ತು, ಇದು ಬಳಕೆದಾರರನ್ನು ಒಂದೇ ಬ್ಯಾಕೆಂಡ್ ನೋಡ್‌ಗೆ ಸೀಮಿತಗೊಳಿಸುತ್ತಿತ್ತು. Load balancers ಗಳು session affinity ಅನ್ನು ಕಡ್ಡಾಯಗೊಳಿಸಬೇಕಾಗುತ್ತಿತ್ತು, ಇದು latency ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯ ಅಡಚಣೆಯನ್ನು (operational friction) ಹೆಚ್ಚಿಸುತ್ತಿತ್ತು.

Statelessness ಈ ಅಡಚಣೆಯನ್ನು ನಿವಾರಿಸುತ್ತದೆ. ಈಗ ಎಲ್ಲಾ context ಗಳು ಪ್ರತಿಯೊಂದು HTTP call ನೊಂದಿಗೆ ಚಲಿಸುವ ಮೀಸಲಾದ meta fields ಗಳಲ್ಲಿ ಇರುತ್ತವೆ. ಒಂದು ವಿನಂತಿಯು (request) ಯಾವುದೇ instance ಮೇಲೆ ಬರಬಹುದು, ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲ್ಪಡಬಹುದು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು (response) ಕಳುಹಿಸಿದ ತಕ್ಷಣ ಆ instance ಅನ್ನು ಕೈಬಿಡಬಹುದು. serverless platforms, container-orchestrated clusters ಅಥವಾ ಬೇಡಿಕೆಯ ಮೇರೆಗೆ pods ಗಳನ್ನು ಸೃಷ್ಟಿಸುವ ಅಥವಾ ಅಳಿಸುವ ಯಾವುದೇ ಪರಿಸರವನ್ನು ಬಳಸುವ ತಂಡಗಳು ಈಗ ಈ ಪ್ರೊಟೊಕಾಲ್ ಅನ್ನು ತಮ್ಮ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ (infrastructure) ಹೊಂದಿಸಿಕೊಳ್ಳಬಹುದು.

ಯಾವುದನ್ನು ನಿಲ್ಲಿಸಲಾಗುತ್ತಿದೆ (Retiring)

ನಿರಂತರ ಸಂಪರ್ಕಗಳ (persistent connections) ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದ್ದ ಮೂರು subsystems ಗಳನ್ನು ಅಧಿಕೃತವಾಗಿ ನಿಲ್ಲಿಸಲಾಗಿದೆ (deprecated):

  • Sampling – v1 ನಲ್ಲಿ, ಸರ್ವರ್ ಕ್ಲೈಂಟ್‌ಗೆ ಪಠ್ಯವನ್ನು (text) ಸೃಷ್ಟಿಸಲು ಕೇಳಬಹುದಿತ್ತು, ಇದು ತೆರೆದ ಸೆಷನ್ ಅಗತ್ಯವಿರುವ ಮಾದರಿಯಾಗಿತ್ತು. v2 ನಲ್ಲಿ ಸರ್ವರ್ ನೇರವಾಗಿ large-language-model provider ಅನ್ನು ಕರೆಯುವ ಅಥವಾ InputRequiredResult ಮಾದರಿಯನ್ನು ಬಳಸುವ ನಿರೀಕ್ಷೆಯಿದೆ, ಇಲ್ಲಿ ಕ್ಲೈಂಟ್ ಮುಂದಿನ ವಿನಂತಿಯಲ್ಲಿ (follow-up request) ಅಗತ್ಯವಿರುವ ಇನ್‌ಪುಟ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ.
  • Roots – ಈ ಮೊದಲು, ಕ್ಲೈಂಟ್‌ಗಳು ಹೊರಗಿನ ಸಂಪನ್ಮೂಲಗಳ (external resources) ಸರ್ವರ್‌ನ ದೃಷ್ಟಿಕೋನವನ್ನು ಸೀಮಿತಗೊಳಿಸುವ URIs ಗಳನ್ನು ಕಳುಹಿಸುತ್ತಿದ್ದವು. ಹೊಸ ವಿಧಾನವು ಆ URIs ಗಳನ್ನು tool parameters ಗಳಾಗಿ ವರ್ಗಾಯಿಸುತ್ತದೆ ಅಥವಾ ವಿನಂತಿಯ resource fields ಗಳಲ್ಲಿ ಸೇರಿಸುತ್ತದೆ, ಇದರಿಂದ ಪ್ರತ್ಯೇಕ "roots" ಮಾತುಕತೆಯ ಹಂತವು (negotiation step) ಇಲ್ಲವಾಗುತ್ತದೆ.
  • Logging – ಪ್ರೊಟೊಕಾಲ್-ಮಟ್ಟದ logging headers ಮಾಯವಾಗುತ್ತವೆ. ಸ್ಥಳೀಯ ಡಿಬಗ್‌ಗೆ (local debugging) stderr ಗೆ ಬರೆಯಿರಿ ಅಥವಾ ಪ್ರೊಡಕ್ಷನ್ ಅಬ್ಸರ್ವೇಬಿಲಿಟಿಗಾಗಿ (production observability) OpenTelemetry ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಿ.

ಈ ನಿಷೇಧದ ಅವಧಿಯು (deprecation window) ಒಂದು ವರ್ಷ ಇರುತ್ತದೆ. ನಿಷೇಧಿತ ಫೀಚರ್‌ಗಳು ಆ ಅವಧಿಯವರೆಗೆ ಕೆಲಸ ಮಾಡುತ್ತಲೇ ಇರುತ್ತವೆ, ಇದು ಪ್ರೊಟೊಕಾಲ್ ಅವುಗಳನ್ನು ತಿರಸ್ಕರಿಸುವ ಮೊದಲು ತಂಡಗಳಿಗೆ refactor ಮಾಡಲು ಸಮಯ ನೀಡುತ್ತದೆ.

Statelessness ಹೊರತಾಗಿ ಹೊಸದಾಗಿ ಏನಿದೆ?

MCP v2 ಎರಡು ಅಧಿಕೃತ extensions ಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ:

  • MCP Apps – ಪ್ರೊಟೊಕಾಲ್ ಕರೆಯಬಹುದಾದ server-rendered user interfaces ಗಳನ್ನು ವಿವರಿಸುವ ಒಂದು ಲಘು ವಿಧಾನ.
  • Tasks – ಬಹು ವಿನಂತಿ-ಪ್ರತಿಕ್ರಿಯೆ ಚಕ್ರಗಳನ್ನು (request-response cycles) ಒಳಗೊಂಡಿರಬಹುದಾದ ದೀರ್ಘಾವಧಿಯ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಒಂದು ಮಾದರಿ.

ಎರಡೂ extensions stateless request ಮಾದರಿಯನ್ನು ಅನುಸರಿಸುತ್ತವೆ ಮತ್ತು ಗುಪ್ತ session state ಅನ್ನು ತಪ್ಪಿಸುತ್ತವೆ.

ಅಪಾಯಗಳು ಮತ್ತು ವಿರೋಧಾತ್ಮಕ ಅಂಶಗಳು

ಈ ಬದಲಾವಣೆಯು ಸುಲಭವಾದ (plug-and-play) ಅಪ್‌ಗ್ರೇಡ್ ಅಲ್ಲ. v2 SDK ಗಳು ಇನ್ನೂ beta ಹಂತದಲ್ಲಿವೆ ಮತ್ತು ಅವುಗಳ public APIs ಸ್ಥಿರ ಬಿಡುಗಡೆಯಾಗುವ ಮೊದಲು ಬದಲಾಗಬಹುದು. ಬ್ರೇಕಿಂಗ್ ಚೇಂಜ್‌ಗಳನ್ನು (breaking changes) ಸಹಿಸಿಕೊಳ್ಳಲಾಗದ ಪ್ರೊಡಕ್ಷನ್ ವರ್ಕ್‌ಲೋಡ್‌ಗಳಿಗಾಗಿ, v2 SDK ಸ್ಥಿರವಾಗುವವರೆಗೆ ಸ್ಥಿರ v1 SDK ಅನ್ನು ಬಳಸಿ.

ಡೆವಲಪರ್‌ಗಳು ನಿಷೇಧಿತ ಮೂರು subsystems ಗಳಿಗಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕೋಡ್ ಅನ್ನು ಕೂಡ ಆಡಿಟ್ (audit) ಮಾಡಬೇಕಾಗುತ್ತದೆ.

ಪ್ರಾಯೋಗಿಕ ಮೈಗ್ರೇಶನ್ ರೋಡ್‌ಮ್ಯಾಪ್

  1. ಇಂದೇ ಆಡಿಟ್ ಮಾಡಿ – handshake, Mcp-Session-Id, sampling calls, roots URIs ಮತ್ತು ಪ್ರೊಟೊಕಾಲ್-ಮಟ್ಟದ logging ಬಳಕೆಯ ಬಗ್ಗೆ ನಿಮ್ಮ ಸೇವೆಗಳನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡಿ. stateless ಮಾದರಿಯ ಅಡಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡದ ಕೋಡ್ ಅನ್ನು ಗುರುತಿಸಿ.
  2. ಗಂಭೀರವಲ್ಲದ ನೋಡ್‌ನಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ – ಸ್ಥಿರ v2 SDK ಬಿಡುಗಡೆಯಾದಾಗ, ಒಂದು sandbox ಸರ್ವರ್ ಅನ್ನು ಸೃಷ್ಟಿಸಿ, ಅದನ್ನು ಟೆಸ್ಟ್ ಕ್ಲೈಂಟ್‌ಗೆ ಕಳುಹಿಸಿ ಮತ್ತು ಎಲ್ಲಾ ಅಗತ್ಯ meta fields ಇ presence ಮತ್ತು ಅವುಗಳನ್ನು ಸರಿಯಾಗಿ ಅರ್ಥೈಸಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.
  3. ಅವಧಿಯ ಮುಕ್ತಾಯದ ಮೊದಲು ಸಂಪೂರ್ಣ ಮೈಗ್ರೇಶನ್ – runtime ತಿರಸ್ಕಾರಗಳನ್ನು ತಪ್ಪಿಸಲು ಒಂದು ವರ್ಷದ ಗ्रेस ಅವಧಿ ಮುಗಿಯುವ ಮೊದಲು ಎಲ್ಲಾ ಪ್ರೊಡಕ್ಷನ್ ನೋಡ್‌ಗಳಲ್ಲಿ ಬದಲಾವಣೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಿ.

ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು

  • ಸ್ಥಿರ SDK ಬಿಡುಗಡೆ – beta SDK ಗಳನ್ನು ಸ್ಥಗಿತಗೊಳಿಸಲಾಗುವುದು ಮತ್ತು ಒಂದು ವರ್ಷದ ಸ್ಥಿರ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಪ್ರಕಟಿಸಲಾಗುವುದು. ಯಾವುದೇ ನಿರ್ಣಾಯಕ ನಿಯೋಜನೆಗೆ (critical deployment) ಆ ವರ್ಷವು ಸುರಕ್ಷಿತ ಗುರಿಯಾಗಿರುತ್ತದೆ.

ಈ ಪರಿವರ್ತನೆಗೆ ಕೋಡ್ ಬದಲಾವಣೆಗಳು ಮತ್ತು beta-SDK ಪ್ರಯೋಗದ ಅವಧಿಯ ಅಗತ್ಯವಿರುತ್ತದೆ, ಆದರೆ ಇದರ ಪ್ರತಿಫಲವು ಯಾವುದೇ LLM-backed ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಹೆಚ್ಚು ಸ್ವಚ್ಛವಾದ ಮತ್ತು ಸ್ಕೇಲೆಬಲ್ ಆಗಿರುವ ಇಂಟಿಗ್ರೇಶನ್ ಪಾಯಿಂಟ್ ಆಗಿರುತ್ತದೆ.

ಸಾರಾಂಶ: ನಿಮ್ಮ ಸ್ಟ್ಯಾಕ್ ಇನ್ನೂ MCP handshakes ಅಥವಾ ನಿಷೇಧಿತ ಮೂರು subsystems ಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದ್ದರೆ, ಈಗಲೇ ಆಡಿಟ್ ಪ್ರಾರಂಭಿಸಿ; ಒಂದು ವರ್ಷದ ಗ्रेस ಅವಧಿಯು ಉದಾರವಾಗಿದ್ದರೂ, ನಿಜವಾದ ವೆಚ್ಚವು ಮೈಗ್ರೇಶನ್ ಅವಧಿಯಲ್ಲಲ್ಲ, ಬದಲಾಗಿ refactor ಮಾಡುವ ಪ್ರಯತ್ನದಲ್ಲಿದೆ.