MCP ನ ಹೊಸ 2026-07-28ರ ಸ್ಪೆಕ್ (specification) ಪ್ರತಿಯೊಂದು ಸೆಷನ್-ಸ್ಟೇಟ್ (session-state) ಅಗತ್ಯತೆಗಳನ್ನು ಕೈಬಿಡುತ್ತದೆ, ಇದರಿಂದ ಪ್ರತಿಯೊಂದು ವಿನಂತಿಯು (request) ಅದಕ್ಕೆ ಬೇಕಾದ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಸ್ಟೇಟ್‌ಲೆಸ್ ಪ್ರೊಟೊಕಾಲ್‌ಗೆ (stateless protocol) ಬದಲಾಗುವುದರಿಂದ, ಡೆವಲಪರ್‌ಗಳು ಪ್ರತಿ ಕರಲ್‌ಗೆ (call) ಒಂದೇ ಇನ್‌ಸ್ಟೆನ್ಸ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು, ಸರ್ವರ್‌ಲೆಸ್ (serverless) ಅಥವಾ ಎಡ್ಜ್ ನೋಡ್‌ಗಳಲ್ಲಿ (edge nodes) ಚಲಾಯಿಸಬಹುದು ಮತ್ತು ನಿಯೋಜನೆಯಲ್ಲಿ (deployment) ತಲೆನೋವಾಗಿ ಪರಿಣಮಿಸಿದ ಹಳೆಯ ಸ್ಟಿಕಿ-ರೂಟಿಂಗ್ (sticky-routing) ಮತ್ತು ಶೇರ್ಡ್-ಸ್ಟೋರ್ (shared-store) ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿಲ್ಲಿಸಬಹುದು.

ಹ್ಯಾಂಡ್‌ಶೇಕ್‌ಗಳಿಂದ ಸ್ವಯಂ-ಸಂಪೂರ್ಣ ಕರಲ್‌ಗಳವರೆಗೆ

ಇದುವರೆಗೆ, Model Context Protocol (MCP) ಸೆಷನ್ ಐಡಿ (session ID) ನೀಡುವ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಅನ್ನು ಕಡ್ಡಾಯಗೊಳಿಸಿತ್ತು. ಸರ್ವರ್‌ಗಳು ಕನೆಕ್ಷನ್ ಇರುವವರೆಗೆ ಆ ಐಡಿಯನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳಬೇಕಿತ್ತು, ಪ್ರಾಯೋಗಿಕವಾಗಿ ಇದರರ್ಥ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು (processes) ಜೀವಂತವಾಗಿಡುವುದು, Redis ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸ್ಟೇಟ್ ಅನ್ನು ರೆಪ್ಲಿಕೇಟ್ ಮಾಡುವುದು ಅಥವಾ "ಸ್ಟಿಕಿ" ರೂಟಿಂಗ್‌ಗಾಗಿ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು ಎಂದರ್ಥ. ಇದರ ಪರಿಣಾಮವಾಗಿ ಸಂಕೀರ್ಣವಾದ ಮತ್ತು ಸಂಪನ್ಮೂಲ-ಭಾರೀ ಸ್ಟ್ಯಾಕ್ (resource-heavy stack) ಸೃಷ್ಟಿಯಾಗಿತ್ತು, ಇದು ಸ್ಕೇಲಿಂಗ್‌ಗೆ ಅಡ್ಡಿಯಾಗುತ್ತಿತ್ತು ಮತ್ತು ಹಾರಿಜಾಂಟಲ್ ಬೆಳವಣಿಗೆಯನ್ನು (horizontal growth) ದುಬಾರಿಯಾಗಿಸುತ್ತಿತ್ತು.

ಹೊಸ ಸ್ಪೆಕ್ ಪ್ರತಿಯೊಂದು ವಿನಂತಿಯನ್ನು ಸ್ವಯಂ-ಸಂಪೂರ್ಣವಾಗಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಪೇಲೋಡ್ (payload) ಪ್ರೊಟೊಕಾಲ್ ವರ್ಷನ್ ಮತ್ತು ಕರಲರ್‌ನ (caller) ಗುರುತನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಸರ್ವರ್ ವಿನಂತಿಯನ್ನು ಒಂದು ಬಾರಿಯ ವಹಿವಾಟು (one-off transaction) ಎಂದು ಪರಿಗಣಿಸಬಹುದು. ಯಾವುದೇ ಸೆಷನ್ ಸ್ಟೋರ್ ಇಲ್ಲ, ದೀರ್ಘಕಾಲದ ಪ್ರಕ್ರಿಯೆ ಇಲ್ಲ, ಯಾವುದೇ ವಿಶೇಷ ರೂಟಿಂಗ್ ನಿಯಮಗಳಿಲ್ಲ.

ನಿಯೋಜನೆಗೆ (Deployment) ಸ್ಟೇಟ್‌ಲೆಸ್ ಏಕೆ ಮುಖ್ಯ?

  • ಸರ್ವರ್‌ಲೆಸ್ ಮತ್ತು ಎಡ್ಜ್ ಸಿದ್ಧತೆ (Serverless and edge ready) – ಒಂದು ವಿನಂತಿಯು ಅದಕ್ಕೆ ಬೇಕಾದ ಎಲ್ಲವನ್ನೂ ಹೊಂದಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಒಂದು ಫಂಕ್ಷನ್ (function) ವಾರ್ಮ್-ಅಪ್ ಸ್ಟೇಟ್ ಇಲ್ಲದೆಯೇ ಪ್ರಾರಂಭವಾಗಿ, ಉತ್ತರಿಸಿ, ಮತ್ತು ಮುಚ್ಚಬಹುದು. ಪ್ರತಿ ಇನ್ವೋಕೇಶನ್‌ಗೆ (invocation) ಶುಲ್ಕ ವಿಧಿಸುವ ಪ್ರೊವೈಡರ್‌ಗಳು MCP ವರ್ಕ್‌ಲೋಡ್‌ಗಳಿಗೆ (workloads) ಸೂಕ್ತವಾಗುತ್ತಾರೆ.
  • ಸರಳೀಕೃತ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ (Simplified load balancing) – ಸ್ಟ್ಯಾಂಡರ್ಡ್ L4/L7 ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳು ಟ್ರಾಫಿಕ್ ಅನ್ನು ಏಕರೂಪವಾಗಿ ವಿತರಿಸಬಹುದು; ಕ್ಲೈಂಟ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟ ಬ್ಯಾಕೆಂಡ್‌ನೊಂದಿಗೆ (backend) ಜೋಡಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.
  • ಕಡಿಮೆಯಾದ ಕಾರ್ಯಾಚರಣೆಯ ಹೊರೆ (Reduced operational overhead) – ತಂಡಗಳು Redis ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಅಥವಾ ಕಸ್ಟಮ್ ಸೆಷನ್-ರೆಪ್ಲಿಕೇಶನ್ ಕೋಡ್‌ಗಳನ್ನು ನಿಲ್ಲಿಸಬಹುದು, ಇದರಿಂದ ವೆಚ್ಚ ಮತ್ತು ವೈಫಲ್ಯದ ಸಾಧ್ಯತೆ ಎರಡನ್ನೂ ಕಡಿಮೆ ಮಾಡಬಹುದು.

ಈಗಾಗಲೇ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ನ ಹಿಂದೆ MCP ಅನ್ನು ಬಳಸುತ್ತಿರುವ ಸಂಸ್ಥೆಗಳಿಗೆ, ಈ ಬದಲಾವಣೆಯು ಅಸಮಾನ ಟ್ರಾಫಿಕ್ ವಿತರಣೆಯನ್ನು ಉಂಟುಮಾಡುವ "ಸ್ಟಿಕಿ" ನಿಯಮಗಳ ಅಗತ್ಯವನ್ನು ತಪ್ಪಿಸುತ್ತದೆ. ದಿನಕ್ಕೆ ಲಕ್ಷಾಂತರ ಕರಲ್‌ಗಳನ್ನು ಪಡೆಯುವ ಹೆಚ್ಚಿನ ಥ್ರೂಪುಟ್ (high-throughput) ಸೇವೆಗಳಿಗೆ ಈ ಉಳಿತಾಯವು ವಿಶೇಷವಾಗಿ ಗಮನಾರ್ಹವಾಗಿದೆ.

ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಭದ್ರತಾ ಮೇಲ್ದರ್ಜೆಗೇರಿಸುವಿಕೆ

ಈ ಸ್ಪೆಕ್ ತನ್ನ ಸ್ಟೇಟ್‌ಲೆಸ್‌ನೆಸ್‌ಗಿಂತಲೂ ಹೆಚ್ಚಿನ ಸುಧಾರಣೆಗಳನ್ನು ತರುತ್ತದೆ:

  • TTL-ಆಧಾರಿತ ಕ್ಯಾಷಿಂಗ್ (TTL-based caching) – ಟೂಲ್ ಮತ್ತು ಪ್ರಾಂಪ್ಟ್ ಪಟ್ಟಿಗಳು ಈಗ time-to-live ಫೀಲ್ಡ್ ಅನ್ನು ಒಳಗೊಂಡಿವೆ, ಇದು ಕ್ಲೈಂಟ್‌ಗಳು ಫಲಿತಾಂಶಗಳನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಕ್ಯಾಶ್ ಮಾಡಲು ಮತ್ತು ಅನಗತ್ಯ ರೌಂಡ್-ಟ್ರಿಪ್‌ಗಳನ್ನು ತಪ್ಪಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
  • ಹೆಡರ್-ಚಾಲಿತ ರೂಟಿಂಗ್ (Header-driven routing) – ಹೊಸ HTTP ಹೆಡರ್‌ಗಳು ರೂಟಿಂಗ್ ಮಾಹಿತಿಯನ್ನು ಮೊದಲೇ ಬಹಿರಂಗಪಡಿಸುತ್ತವೆ, ಇದರಿಂದ ಗೇಟ್‌ವೇಗಳು (gateways) ಪೂರ್ಣ JSON ಬಾಡಿಯನ್ನು ಪಾರ್ಸ್ ಮಾಡದೆಯೇ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಬಹುದು, ಇದು ವಿಳಂಬವನ್ನು (latency) ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಷ್ಟು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
  • OAuth/OIDC ಬಲವರ್ಧನೆ (OAuth/OIDC hardening) – ಐಡೆಂಟಿಟಿ ಟೋಕನ್‌ಗಳು ಕಟ್ಟುನಿಟ್ಟಾದ OAuth ಮತ್ತು OpenID Connect ಪರಿಶೀಲನೆಗಳಿಗೆ ಒಳಗಾಗುತ್ತವೆ, ಇದು ರಿಪ್ಲೇ (replay) ಮತ್ತು ಟೋಕನ್ ಕಳ್ಳತನದ ದಾಳಿಗಳ ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
  • ಔಪಚಾರಿಕ ಎಕ್ಸ್‌ಟೆನ್ಶನ್ ಫ್ರೇಮ್‌ವರ್ಕ್ (Formal extensions framework) – ಟಾಸ್ಕ್‌ಗಳು ಮತ್ತು ಆಪ್‌ಗಳು ಈಗ ನಿರ್ದಿಷ್ಟ ಎಕ್ಸ್‌ಟೆನ್ಶನ್ ಮಾದರಿಗೆ ಸೇರಿವೆ, ಇದು SDK ನಿರ್ವಹಕರೇ (maintainers) ಭವಿಷ್ಯದ ಫೀಚರ್‌ಗಳನ್ನು ಸುಲಭವಾಗಿ ಬಿಡುಗಡೆ ಮಾಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಡೆವಲಪರ್‌ಗಳ ಮೇಲೆ ಪರಿಣಾಮ

SDK ಪರಿಸರ ವ್ಯವಸ್ಥೆಯು ಈಗಾಗಲೇ ಈ ಬದಲಾವಣೆಯನ್ನು ಪ್ರತಿಫಲಿಸುತ್ತಿದೆ: TypeScript, Python, Go ಮತ್ತು C# ಲೈಬ್ರರಿಗಳು ಹೊಸ ವಿನಂತಿ ಫಾರ್ಮ್ಯಾಟ್ ಅನ್ನು ನೀಡುತ್ತಿವೆ. ಈ SDKಗಳ ಒಟ್ಟು ಡೌನ್‌ಲೋಡ್‌ಗಳು ತಿಂಗಳಿಗೆ ಅರ್ಧ ಶತಕೋಟಿ ತಲುಪುತ್ತಿವೆ, ಇದು ವರ್ಷದ ಆರಂಭಕ್ಕಿಂತ ನಾಲ್ಕು ಪಟ್ಟು ಹೆಚ್ಚಾಗಿದ್ದು, MCP ಎಷ್ಟು ವ್ಯಾಪಕವಾಗಿ ಅಳವಡಿಸಿಕೊಳ್ಳಲಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಸೂಚಿಸುತ್ತದೆ.

ಪರ್ಸಿಸ್ಟೆಂಟ್ ಸೆಷನ್ (persistent session) ಅನ್ನು ಅಂದುಕೊಂಡಿರುವ ಯಾವುದೇ ಕೋಡ್ ಅನ್ನು ಡೆವಲಪರ್‌ಗಳು ಹೊಂದಾಣಿಕೆ ಮಾಡಿಕೊಳ್ಳಬೇಕು. ಸಾಮಾನ್ಯವಾಗಿ ಇದರರ್ಥ ಸೆಷನ್-ನಿರ್ದಿಷ್ಟ ಡೇಟಾವನ್ನು ವಿನಂತಿ ಪೇಲೋಡ್‌ಗೆ ಅಥವಾ ಪ್ರತಿ ಕರಲ್‌ಗೆ ಬಳಸಲಾಗುವ ಬಾಹ್ಯ ಸ್ಟೋರ್‌ಗೆ ವರ್ಗಾಯಿಸುವುದು ಎಂದರ್ಥ. ಮೈಗ್ರೇಷನ್ ಅವಧಿಯು ಹನ್ನೆರಡು ತಿಂಗಳುಗಳಾಗಿದ್ದು, ಇದು ತಂಡಗಳಿಗೆ ರಿಫ್ಯಾಕ್ಟರ್ (refactor), ಪರೀಕ್ಷಿಸಲು ಮತ್ತು ಹೊಸ ಮಾದರಿಯನ್ನು ಜಾರಿಗೆ ತರಲು ಸಮಯ ನೀಡುತ್ತದೆ.

ವಿರೋಧಾತ್ಮಕ ಅಂಶ: ಮೈಗ್ರೇಷನ್ ಸಂಕೀರ್ಣತೆ

ಸ್ಟೇಟ್‌ಲೆಸ್‌ನೆಸ್ ಎಂಬುದು ಸುಲಭವಾದ ವಿಷಯವಲ್ಲ. ಪ್ರಗತಿಪರ ಸಂಭಾಷಣೆಯ ಇತಿಹಾಸದಂತಹ (progressive conversation history) ವಿಷಯಗಳಿಗಾಗಿ ಈ ಮೊದಲು ಸರ್ವರ್-ಸೈಡ್ ಸ್ಟೇಟ್ ಅನ್ನು ಅವಲಂಬಿಸಿದ್ದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಈಗ ಆ ಸ್ಟೇಟ್ ಅನ್ನು ಕ್ಲೈಂಟ್-ಸೈಡ್‌ನಲ್ಲಿ ಅಥವಾ ಪ್ರತ್ಯೇಕ ಪರ್ಸಿಸ್ಟೆನ್ಸ್ ಲೇಯರ್ (persistence layer) ಮೂಲಕ ನಿರ್ವಹಿಸಬೇಕಾಗುತ್ತದೆ.

ಗಮನಿಸಬೇಕಾದ ಅಂಶಗಳು

  • ಅಳವಡಿಕೆಯ ಮಾಪನಗಳು (Adoption metrics) – SDK ವರ್ಷನ್ ಬಳಕೆಯನ್ನು ಗಮನಿಸಿ; ಬಳಕೆ ಕಡಿಮೆಯಾದರೆ ಅದು ಮೈಗ್ರೇಷನ್‌ನಲ್ಲಿನ ಅಡಚಣೆಯನ್ನು ಸೂಚಿಸಬಹುದು.
  • ಎಡ್ಜ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಬೆಂಬಲ (Edge platform support) – ಹೆಚ್ಚು ಪ್ರೊವೈಡರ್‌ಗಳು MCP-ಅನುಸರಣೆಯ ರನ್‌ಟೈಮ್‌ಗಳನ್ನು (runtimes) ಘೋಷಿಸಿದಂತೆ, ಸರ್ವರ್‌ಲೆಸ್‌ನ ನೈಜ ವೆಚ್ಚದ ಪ್ರಯೋಜನವು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ.
  • ಭದ್ರತಾ ಘಟನೆಗಳ ವರದಿಗಳು (Security incident reports) – ಬಲವರ್ಧಿತ OAuth/OIDC ಫ್ಲೋವು ಐಡೆಂಟಿಟಿ ದಾಳಿಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಆದರೆ ಯಾವುದೇ ಉಲ್ಲಂಘನೆಯು (breach) ಹೊಸ ಸುರಕ್ಷತಾ ಕ್ರಮಗಳನ್ನು ಪರೀಕ್ಷಿಸುತ್ತದೆ.

ಸಾರಾಂಶ (Takeaway): MCP ಅನ್ನು ಸ್ಟೇಟ್‌ಲೆಸ್ ಮಾಡುವುದರ ಮೂಲಕ, ಈ ಸ್ಪೆಕ್ ಪ್ರೊಟೊಕಾಲ್ ಅನ್ನು ಆಧುನಿಕ ಕ್ಲೌಡ್-ನೇಟಿವ್ ಮಾದರಿಗಳೊಂದಿಗೆ ಹೊಂದಿಸುತ್ತದೆ, ಸೆಷನ್ ನಿರ್ವಹಣೆಯ ಕಾರ್ಯಾಚರಣೆಯ ಹೊರೆವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅಗ್ಗದ, ಹೆಚ್ಚು ಎಲಾಸ್ಟಿಕ್ (elastic) ನಿಯೋಜನಾ ಮಾದರಿಗಳಿಗೆ ದಾರಿ ಮಾಡಿಕೊಡುತ್ತದೆ. ಇದರ ಬದಲಾಗಿ ಸ್ವಲ್ಪ ಅವಧಿಯ ಕೋಡ್ ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಮತ್ತು ದೊಡ್ಡ ವಿನಂತಿ ಫುಟ್‌ಪ್ರಿಂಟ್‌ಗಳು (request footprints) ಬೇಕಾಗಬಹುದು, ಆದರೆ ದೀರ್ಘಕಾಲದ ಲಾಭವೆಂದರೆ ಅದು ಯಾವ ಇನ್‌ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ಮೇಲೆ ಚಲಿಸುತ್ತದೆಯೋ ಅಷ್ಟೇ ಸುಲಭವಾಗಿ ಸ್ಕೇಲ್ ಆಗುವ ಪ್ರೊಟೊಕಾಲ್ ಆಗಿರುತ್ತದೆ.