Model Context Protocol (MCP) ಈಗ stateless ಆಗಿದೆ, ಮತ್ತು ಪ್ರತಿ ವಿನಂತಿಯು (request) ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ 10 ms CPU ಮಿತಿಯೊಳಗೆ ಇರುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಂಡರೆ, ಡೆವಲಪರ್‌ಗಳು Cloudflare Workers ನ ಉಚಿತ ಹಂತದಲ್ಲಿ (free tier) ಸಣ್ಣ MCP ಸರ್ವರ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು ಈ ಬದಲಾವಣೆಯು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

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

ಇತ್ತೀಚಿನ ಎರಡು ಕ್ರಮಗಳು ಇದಕ್ಕೆ ದಾರಿ ಮಾಡಿಕೊಟ್ಟಿವೆ. ಮೊದಲನೆಯದಾಗಿ, MCP core ತನ್ನ session-based ವಿನ್ಯಾಸವನ್ನು ಕೈಬಿಟ್ಟಿದೆ ಮತ್ತು ಈಗ handshakes ಇಲ್ಲದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ; ಯಾವುದೇ ವಿನಂತಿಯನ್ನು ಕೋಡ್‌ನ ಯಾವುದೇ ಇನ್‌ಸ್ಟೆನ್ಸ್ (instance) ನಿರ್ವಹಿಸಬಹುದು. ಎರಡನೆಯದಾಗಿ, Cloudflare ತನ್ನ McpAgent ಕ್ಲಾಸ್ ಅನ್ನು ನಿಲ್ಲಿಸಿದೆ ಮತ್ತು ಈಗ ಹೊಸ ಸರ್ವರ್‌ಗಳಿಗಾಗಿ ಸಾಮಾನ್ಯ request handlers ಅನ್ನು ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ. ಇವೆರಡೂ ಸೇರಿ Durable Objects ಅಥವಾ ಇತರ stateful storage ಗಳ ಅಗತ್ಯವನ್ನು ತಪ್ಪಿಸುತ್ತವೆ, ಇವುಗಳೇ ಉಚಿತ ಯೋಜನೆಯಲ್ಲಿ MCP ಅನ್ನು ನಡೆಸಲು ಮುಖ್ಯ ಅಡೆತಡೆಗಳಾಗಿದ್ದವು.

ಉಚಿತ ಹಂತದಲ್ಲಿ (free tier) ವಾಸ್ತವವಾಗಿ ಏನು ಮಾಡಬಹುದು

ನಾವು ಒಂದು ಸ್ಟ್ಯಾಟಿಕ್ ಸೈಟ್‌ನಿಂದ Markdown ಫೈಲ್‌ಗಳನ್ನು ನೀಡುವ 'read-only' MCP ಸರ್ವರ್ ಅನ್ನು ನಿರ್ಮಿಸಿದ್ದೇವೆ. ಈ ಸರ್ವರ್ ಮೆಥಡ್‌ಗಳನ್ನು ರೂಟ್ ಮಾಡಲು ಸರಳ switch statement ಅನ್ನು ಬಳಸಿಕೊಂಡು list_articles ಮತ್ತು get_article ಎಂಬ ಎರಡು ಟೂಲ್‌ಗಳನ್ನು ಅಳವಡಿಸಿದೆ. ಇಲ್ಲಿ ಯಾವುದೇ ಭಾರೀ ಲೆಕ್ಕಾಚಾರಗಳಿಲ್ಲ, ಕೇವಲ ಸ್ಟ್ಯಾಟಿಕ್ ಅಸೆಟ್‌ಗಳನ್ನು (static assets) ಪಡೆಯಲಾಗುತ್ತದೆ.

Cloudflare ನ CPU ಲೆಕ್ಕಾಚಾರವು ಒಟ್ಟು ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯಕ್ಕಿಂತ (total response time) ಭಿನ್ನವಾಗಿದೆ. CPU ಸಮಯವು ಕೇವಲ ನಿಮ್ಮ JavaScript ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಬಳಸಿದ ಸೈಕಲ್‌ಗಳನ್ನು ಮಾತ್ರ ಎಣಿಸುತ್ತದೆ; ನೆಟ್‌ವರ್ಕ್ ಕರೆಗಳು ಅಥವಾ ಡಿಸ್ಕ್ ರೀಡ್‌ಗಳಿಗಾಗಿ ಕಾಯುವ ಸಮಯವನ್ನು ಹೊರಗಿಡಲಾಗುತ್ತದೆ. ಈ ವ್ಯತ್ಯಾಸವು ಮುಖ್ಯವಾಗಿದೆ ಏಕೆಂದರೆ ಉಚಿತ ಹಂತವು ಪ್ರತಿ ವಿನಂತಿಗೆ CPU ಅನ್ನು 10 ms ಗೆ ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ, ಆದರೆ ಒಟ್ಟು ವಿಳಂಬವು (latency) ಅದಕ್ಕಿಂತ ಹೆಚ್ಚಿರಬಹುದು.

ಉಚಿತ ಹಂತದಲ್ಲಿ ನಮ್ಮ ಅಳತೆಗಳು ಈ ರೀತಿ ಕಂಡುಬಂದವು:

  • server/discover: 0-1 ms CPU
  • tools/list: 0 ms CPU
  • get_article (largest file): 1-2 ms CPU

ಅತಿದೊಡ್ಡ ಲೇಖನವು ಕೂಡ 10 ms ಬಜೆಟ್‌ನ ಒಂದು ಸಣ್ಣ ಭಾಗವನ್ನು ಮಾತ್ರ ಬಳಸಿತು. ಕ್ಲೈಂಟ್ ಕಡೆಯಲ್ಲಾದ ವಿಳಂಬವು ಫೈಲ್ ಅನ್ನು ಓದುವಿಕೆಯನ್ನು ಕಾಯುವುದರಿಂದ ಉಂಟಾಯಿತು ಹೊರತು ಕೋಡ್ ಕಾರ್ಯಗತಗೊಳಿಸುವುದರಿಂದಲ್ಲ.

ಮಿತಿ ಎಲ್ಲಿ ತೊಂದರೆ ನೀಡಬಹುದು

ದತ್ತಾಂಶವು ಒಂದು ಸ್ಪಷ್ಟ ಮಾದರಿಯನ್ನು ತೋರಿಸುತ್ತದೆ:

  • Data-serving tools (ಸರಳ ರೀಡ್‌ಗಳು, ಲಿಸ್ಟಿಂಗ್‌ಗಳು) ಸುಲಭವಾಗಿ ಮಿತಿಯೊಳಗೆ ಇರುತ್ತವೆ.
  • Compute-heavy tools (parsing, rendering, hashing, ಅಥವಾ ಯಾವುದೇ ಅಲ್ಗಾರಿದಮಿಕ್ ಕೆಲಸಗಳು) 10 ms ಬಜೆಟ್ ಅನ್ನು ಶೀಘ್ರವಾಗಿ ಖಾಲಿ ಮಾಡಬಹುದು.

ಒಂದು ಟೂಲ್‌ಗೆ ಸಾಮಾನ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಪ್ರೊಸೆಸಿಂಗ್ ಅಗತ್ಯವಿದ್ದರೆ, ಡೆವಲಪರ್‌ಗಳು ಪೇಯ್ಡ್ (paid) Workers ಪ್ಲಾನ್‌ಗೆ ಬದಲಾಯಿಸಬೇಕಾಗುತ್ತದೆ. $5 ಪ್ಲಾನ್ ಪ್ರತಿ ವಿನಂತಿಗೆ ಮಿತಿಯನ್ನು 30 ಸೆಕೆಂಡುಗಳಿಗೆ ಹೆಚ್ಚಿಸುತ್ತದೆ.

ಯಾರು ಗೆಲ್ಲುತ್ತಾರೆ, ಯಾರು ಸಮಯವನ್ನು ಗಮನಿಸಬೇಕು

ಈಗಾಗಲೇ Markdown ಫೈಲ್‌ಗಳು ಅಥವಾ RSS ಫೀಡ್ ಹೊಂದಿರುವ ಸಣ್ಣ ಸೈಟ್‌ಗಳು, ಕೇವಲ ಒಂದು ಹೊಸ ರೂಟ್ ಮೂಲಕ MCP ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಪ್ರದರ್ಶಿಸಬಹುದು ಮತ್ತು ಉಚಿತ ಯೋಜನೆಯಲ್ಲೇ ಇರಬಹುದು. ಇದರರ್ಥ ಹವ್ಯಾಸಿಗಳು, ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಸೈಟ್‌ಗಳು ಅಥವಾ ಕಡಿಮೆ ಟ್ರಾಫಿಕ್ ಇರುವ ಬ್ಲಾಗ್‌ಗಳಿಗೆ ಕಡಿಮೆ ಕಾರ್ಯಾಚರಣೆಯ ವೆಚ್ಚ ಮತ್ತು ಕಡಿಮೆ ಸಂಕೀರ್ಣತೆ ಇರುತ್ತದೆ.

ಒಂದು ಟೂಲ್‌ಗೆ ಸಾಮಾನ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಪ್ರೊಸೆಸಿಂಗ್ ಅಗತ್ಯವಿದ್ದರೆ, ಡೆವಲಪರ್‌ಗಳು ಪೇಯ್ಡ್ Workers ಪ್ಲಾನ್‌ಗೆ ಬದಲಾಯಿಸಬೇಕಾಗುತ್ತದೆ.

ನೀವು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಏನನ್ನು ಪರೀಕ್ಷಿಸಬೇಕು

  • ನಿಮ್ಮ ಟೂಲ್ ಅನ್ನು ಪ್ರೊಫೈಲ್ ಮಾಡಿ (Profile your tool): ಕೆಲವು ಪ್ರತಿನಿಧಿ ವಿನಂತಿಗಳನ್ನು (representative requests) ಚಲಾಯಿಸಿ ಮತ್ತು Cloudflare ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿನ CPU ಮೀಟರ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ.
  • ಸ್ಟ್ಯಾಟಿಕ್ ಮತ್ತು ಡೈನಾಮಿಕ್ ಪಥಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ: ಸ್ಟ್ಯಾಟಿಕ್ ಫೈಲ್ ಸರ್ವಿಂಗ್ ಅನ್ನು ಉಚಿತ ಹಂತದಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಕಂಪ್ಯೂಟ್-ಅಂತರ್ನಿಹಿತ (compute-intensive) ಕರೆಗಳನ್ನು ಪೇಯ್ಡ್ ವರ್ಕರ್ ಅಥವಾ ಇನ್ನೊಂದು ಬ್ಯಾಕೆಂಡ್‌ಗೆ ರೂಟ್ ಮಾಡಿ.
  • ಅಡಗಿರುವ ವಿಳಂಬವನ್ನು (latency) ಗಮನಿಸಿ: ನೆಟ್‌ವರ್ಕ್ ಕಾಯುವಿಕೆಗಳು CPU ಮಿತಿಗೆ ಎಣಿಸುವುದಿಲ್ಲ, ಆದರೆ ಅವು ಬಳಕೆದಾರರ ಅನುಭವದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ. ನೀವು ನೀಡುವ ಫೈಲ್‌ಗಳಿಗಾಗಿ edge caching ಅನ್ನು ಪರಿಗಣಿಸಿ.

ವಿರೋಧಾತ್ಮಕ ಅಂಶ: ಉಚಿತ ಯೋಜನೆಯು ಅನಂತವಲ್ಲ

Stateless core ಇಂದ Durable Objects ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೂ, 10 ms ಮಿತಿಯು ಕಠಿಣವಾದ ಗಡಿಯಾಗಿ ಉಳಿದಿದೆ. ಸಾಧಾರಣ ಪಾರ್ಸಿಂಗ್‌ನ (ಉದಾಹರಣೆಗೆ, markdown ನಿಂದ HTML ಪರಿವರ್ತನೆ) ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಅಂದಾಜಿಸುವ ಡೆವಲಪರ್‌ಗಳು ಅನಿರೀಕ್ಷಿತವಾಗಿ ಈ ಮಿತಿಯನ್ನು ತಲುಪಬಹುದು. ಉಚಿತ ಹಂತವು "serve-as-is" (ಹಾಗೆಯೇ ನೀಡುವುದು) ಸನ್ನಿವೇಶಗಳಿಗೆ ಸೂಕ್ತವಾಗಿದೆ, ತಕ್ಷಣದ ಕಂಟೆಂಟ್ ಜನರೇಷನ್‌ಗೆ (on-the-fly content generation) ಅಲ್ಲ.

Cloudflare ನಲ್ಲಿ MCP ನ ಮುಂದಿನ ಹಂತವೇನು

ನಿಮ್ಮ ಸೈಟ್‌ನಲ್ಲಿ ಈಗಾಗಲೇ ಸ್ಟ್ಯಾಟಿಕ್ ಬಕೆಟ್‌ನಲ್ಲಿ ಕಂಟೆಂಟ್ ಇದ್ದರೆ, MCP ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಸೇರಿಸುವುದು ಕೇವಲ ಕೆಲವು ಸಾಲುಗಳ ಕೋಡ್ ಮತ್ತು ಒಂದು ರೂಟ್ ಮೂಲಕ ಸುಲಭವಾಗಬಹುದು. ನೀವು 10 ms CPU ಮಿತಿಯೊಳಗೆ ಇರುವವರೆಗೆ, ಉಚಿತವಾಗಿ ಹೋಸ್ಟ್ ಮಾಡಬಹುದಾದ ಸಾಮಾನ್ಯ HTTP ಎಂಡ್‌ಪಾಯಿಂಟ್ ಎಂಬ ಸಣ್ಣ ಸರ್ವರ್‌ಗಳ ಅಗತ್ಯಕ್ಕೆ ಈ ಪ್ರೊಟೊಕಾಲ್ ಈಗ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ.