Model Context Protocol (MCP) ਹੁਣ ਸਟੇਟਲੈੱਸ (stateless) ਹੋ ਗਿਆ ਹੈ, ਅਤੇ ਇਹ ਬਦਲਾਅ ਡਿਵੈਲਪਰਾਂ ਨੂੰ Cloudflare Workers ਦੇ ਫ੍ਰੀ ਟਾਇਰ 'ਤੇ ਛੋਟੇ MCP ਸਰਵਰ ਚਲਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ—ਬਸ਼ਰਤੇ ਕਿ ਹਰ ਰਿਕਵੈਸਟ ਪਲੇਟਫਾਰਮ ਦੀ 10 ms CPU ਸੀਮਾ ਦੇ ਅੰਦਰ ਰਹੇ।

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

ਦੋ ਹਾਲੀਆ ਕਦਮਾਂ ਨੇ ਇਸ ਦਾ ਰਾਹ ਖੋਲ੍ਹ ਦਿੱਤਾ ਹੈ। ਪਹਿਲਾਂ, MCP ਕੋਰ ਨੇ ਆਪਣਾ ਸੈਸ਼ਨ-ਅਧਾਰਤ ਡਿਜ਼ਾਈਨ ਛੱਡ ਦਿੱਤਾ ਹੈ ਅਤੇ ਹੁਣ ਇਹ ਬਿਨਾਂ ਹੈਂਡਸ਼ੇਕ (handshakes) ਦੇ ਚੱਲਦਾ ਹੈ; ਕਿਸੇ ਵੀ ਰਿਕਵੈਸਟ ਨੂੰ ਕੋਡ ਦੇ ਕਿਸੇ ਵੀ ਇੰਸਟੈਂਸ (instance) ਦੁਆਰਾ ਸੰਭਾਲਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਦੂਜਾ, Cloudflare ਨੇ McpAgent ਕਲਾਸ ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ ਹੈ ਅਤੇ ਹੁਣ ਨਵੇਂ ਸਰਵਰਾਂ ਲਈ ਸਾਧਾਰਨ ਰਿਕਵੈਸਟ ਹੈਂਡਲਰਾਂ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹੈ। ਇਕੱਠੇ ਮਿਲ ਕੇ, ਉਹਨਾਂ ਨੇ Durable Objects ਜਾਂ ਹੋਰ ਸਟੇਟਫੁੱਲ (stateful) ਸਟੋਰੇਜ ਦੀ ਲੋੜ ਨੂੰ ਖਤਮ ਕਰ ਦਿੱਤਾ ਹੈ, ਜੋ ਕਿ ਫ੍ਰੀ ਪਲਾਨ 'ਤੇ MCP ਚਲਾਉਣ ਲਈ ਮੁੱਖ ਰੁਕਾਵਟਾਂ ਸਨ।

ਫ੍ਰੀ ਟਾਇਰ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰ ਸਕਦਾ ਹੈ

ਅਸੀਂ ਇੱਕ ਰੀਡ-ਓਨਲੀ (read-only) MCP ਸਰਵਰ ਬਣਾਇਆ ਹੈ ਜੋ ਇੱਕ ਸਟੈਟਿਕ ਸਾਈਟ ਤੋਂ Markdown ਫਾਈਲਾਂ ਸਰਵ ਕਰਦਾ ਹੈ। ਸਰਵਰ ਮੈਥਡਾਂ ਨੂੰ ਰੂਟ ਕਰਨ ਲਈ ਇੱਕ ਸਧਾਰਨ switch statement ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਦੋ ਟੂਲ—list_articles ਅਤੇ get_article—ਲਾਗੂ ਕਰਦਾ ਹੈ। ਕੋਈ ਭਾਰੀ ਗਣਨਾ ਨਹੀਂ, ਸਿਰਫ਼ ਸਟੈਟਿਕ ਐਸੇਟਸ (assets) ਨੂੰ ਫੈਚ ਕਰਨਾ।

Cloudflare ਦੀ CPU ਗਿਣਤੀ ਕੁੱਲ ਰਿਸਪਾਂਸ ਸਮੇਂ ਤੋਂ ਵੱਖਰੀ ਹੁੰਦੀ ਹੈ। CPU ਸਮੇਂ ਵਿੱਚ ਸਿਰਫ਼ ਤੁਹਾਡੇ JavaScript ਨੂੰ ਚਲਾਉਣ ਵਿੱਚ ਲੱਗੇ ਚੱਕਰ (cycles) ਗਿਣੇ ਜਾਂਦੇ ਹਨ; ਨੈੱਟਵਰਕ ਕਾਲਾਂ ਜਾਂ ਡਿਸਕ ਰੀਡਸ ਦੀ ਉਡੀਕ ਵਿੱਚ ਬਿਤਾਇਆ ਸਮਾਂ ਇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਅੰਤਰ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਫ੍ਰੀ ਟਾਇਰ ਪ੍ਰਤੀ ਰਿਕਵੈਸਟ CPU ਨੂੰ 10 ms 'ਤੇ ਸੀਮਤ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਕੁੱਲ ਲੈਟੈਂਸੀ (latency) ਇਸ ਤੋਂ ਵੱਧ ਹੋ ਸਕਦੀ ਹੈ।

ਫ੍ਰੀ ਟਾਇਰ 'ਤੇ ਸਾਡੇ ਮਾਪ ਇਸ ਤਰ੍ਹਾਂ ਸਨ:

  • server/discover: 0-1 ms CPU
  • tools/list: 0 ms CPU
  • get_article (ਸਭ ਤੋਂ ਵੱਡੀ ਫਾਈਲ): 1-2 ms CPU

ਸਭ ਤੋਂ ਵੱਡੀ ਆਰਟੀਕਲ ਨੇ ਵੀ 10 ms ਦੇ ਬਜਟ ਦਾ ਇੱਕ ਛੋਟਾ ਹਿੱਸਾ ਹੀ ਵਰਤਿਆ। ਕਲਾਇੰਟ ਸਾਈਡ 'ਤੇ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ ਸੁਸਤੀ ਫਾਈਲ ਨੂੰ ਪੜ੍ਹਨ ਦੀ ਉਡੀਕ ਕਾਰਨ ਸੀ, ਨਾ ਕਿ ਕੋਡ ਦੇ ਚੱਲਣ ਕਾਰਨ।

ਸੀਮਾ ਕਿੱਥੇ ਮੁਸ਼ਕਲ ਪੈਦਾ ਕਰਦੀ ਹੈ

ਡਾਟਾ ਇੱਕ ਸਪੱਸ਼ਟ ਪੈਟਰਨ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ:

  • ਡਾਟਾ-ਸਰਵਿੰਗ ਟੂਲਜ਼ (ਸਧਾਰਨ ਰੀਡਸ, ਲਿਸਟਿੰਗ) ਆਰਾਮ ਨਾਲ ਸੀਮਾ ਦੇ ਅੰਦਰ ਰਹਿੰਦੇ ਹਨ।
  • ਕੰਪਿਊਟ-ਹੈਵੀ ਟੂਲਜ਼ (ਪਾਰਸਿੰਗ, ਰੈਂਡਰਿੰਗ, ਹੈਸ਼ਿੰਗ, ਜਾਂ ਕੋਈ ਵੀ ਅਲਗੋਰਿਦਮਿਕ ਕੰਮ) ਤੇਜ਼ੀ ਨਾਲ 10 ms ਦਾ ਬਜਟ ਖਤਮ ਕਰ ਸਕਦੇ ਹਨ।

ਜੇਕਰ ਕਿਸੇ ਟੂਲ ਨੂੰ ਮਾਮੂਲੀ ਤੋਂ ਵੱਧ ਪ੍ਰੋਸੈਸਿੰਗ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਪੇਡ (paid) Workers ਪਲਾਨ 'ਤੇ ਜਾਣਾ ਪਵੇਗਾ। $5 ਵਾਲਾ ਪਲਾਨ ਸੀਮਾ ਨੂੰ ਪ੍ਰਤੀ ਰਿਕਵੈਸਟ 30 ਸੈਕਿੰਡ ਤੱਕ ਵਧਾ ਦਿੰਦਾ ਹੈ।

ਕੌਣ ਜਿੱਤਦਾ ਹੈ, ਕੌਣ ਸਮੇਂ 'ਤੇ ਨਜ਼ਰ ਰੱਖਦਾ ਹੈ

ਛੋਟੀਆਂ ਸਾਈਟਾਂ ਜੋ ਪਹਿਲਾਂ ਹੀ Markdown ਫਾਈਲਾਂ ਜਾਂ RSS ਫੀਡ ਹੋਸਟ ਕਰਦੀਆਂ ਹਨ, ਉਹ ਇੱਕ ਨਵੇਂ ਰੂਟ ਨਾਲ ਇੱਕ MCP ਐਂਡਪੁਆਇੰਟ (endpoint) ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਫ੍ਰੀ ਪਲਾਨ 'ਤੇ ਰਹਿ ਸਕਦੀਆਂ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸ਼ੌਕੀਆ ਵਰਤੋਂਕਾਰਾਂ, ਡਾਕੂਮੈਂਟੇਸ਼ਨ ਸਾਈਟਾਂ, ਜਾਂ ਘੱਟ ਟ੍ਰੈਫਿਕ ਵਾਲੇ ਬਲੌਗਾਂ ਲਈ ਘੱਟ ਸੰਚਾਲਨ ਲਾਗਤ ਅਤੇ ਘੱਟ ਕੰਪਨੈਂਟ।

ਜੇਕਰ ਕਿਸੇ ਟੂਲ ਨੂੰ ਮਾਮੂਲੀ ਤੋਂ ਵੱਧ ਪ੍ਰੋਸੈਸਿੰਗ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਪੇਡ Workers ਪਲਾਨ 'ਤੇ ਜਾਣਾ ਪਵੇਗਾ।

ਲਾਂਚ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਟੈਸਟ ਕਰਨਾ ਹੈ

  • ਆਪਣੇ ਟੂਲ ਦਾ ਪ੍ਰੋਫਾਈਲ ਬਣਾਓ: ਕੁਝ ਪ੍ਰਤੀਨਿਧ ਰਿਕਵੈਸਟਾਂ ਚਲਾਓ ਅਤੇ Cloudflare ਦੇ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ CPU ਮੀਟਰ ਦੀ ਜਾਂਚ ਕਰੋ।
  • ਸਟੈਟਿਕ ਅਤੇ ਡਾਇਨਾਮਿਕ ਪਾਥਾਂ ਨੂੰ ਵੱਖ ਕਰੋ: ਸਟੈਟਿਕ ਫਾਈਲ ਸਰਵਿੰਗ ਨੂੰ ਫ੍ਰੀ ਟਾਇਰ 'ਤੇ ਰੱਖੋ, ਅਤੇ ਕੰਪਿਊਟ-ਇੰਟੈਂਸਿਵ ਕਾਲਾਂ ਨੂੰ ਪੇਡ ਵਰਕਰ ਜਾਂ ਕਿਸੇ ਹੋਰ ਬੈਕਐਂਡ ਵੱਲ ਰੂਟ ਕਰੋ।
  • ਲੁਕੀ ਹੋਈ ਲੈਟੈਂਸੀ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ: ਨੈੱਟਵਰਕ ਉਡੀਕ CPU ਦੇ ਵਿਰੁੱਧ ਨਹੀਂ ਗਿਣੀ ਜਾਂਦੀ, ਪਰ ਉਹ ਫਿਰ ਵੀ ਯੂਜ਼ਰ ਅਨੁਭਵ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ। ਉਹਨਾਂ ਫਾਈਲਾਂ ਲਈ ਐਜ ਕੈਸ਼ਿੰਗ (edge caching) 'ਤੇ ਵਿਚਾਰ ਕਰੋ ਜੋ ਤੁਸੀਂ ਸਰਵ ਕਰਦੇ ਹੋ।

ਵਿਰੋਧੀ ਨੁਕਤਾ: ਫ੍ਰੀ ਪਲਾਨ ਅਸੀਮਤ ਨਹੀਂ ਹੈ

ਹਾਲਾਂਕਿ ਸਟੇਟਲੈੱਸ ਕੋਰ Durable Objects ਦੀ ਲੋੜ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ, ਪਰ 10 ms ਦੀ ਸੀਮਾ ਇੱਕ ਸਖ਼ਤ ਕੰਧ ਬਣੀ ਰਹਿੰਦੀ ਹੈ। ਉਹ ਡਿਵੈਲਪਰ ਜੋ ਮਾਮੂਲੀ ਪਾਰਸਿੰਗ (ਜਿਵੇਂ ਕਿ markdown ਤੋਂ HTML ਵਿੱਚ ਬਦਲਣਾ) ਦੀ ਲਾਗਤ ਨੂੰ ਘੱਟ ਸਮਝਦੇ ਹਨ, ਉਹ ਅਚਾਨਕ ਇਸ ਸੀਮਾ 'ਤੇ ਪਹੁੰਚ ਸਕਦੇ ਹਨ। ਫ੍ਰੀ ਟਾਇਰ "ਜਿਵੇਂ ਹੈ ਉਵੇਂ ਸਰਵ ਕਰਨ" ਵਾਲੇ ਮੈਨਾਰੀਓਜ਼ ਲਈ ਢੁਕਵਾਂ ਹੈ, ਨਾ ਕਿ ਤੁਰੰਤ ਕੰਟੈਂਟ ਜਨਰੇਸ਼ਨ (on-the-fly content generation) ਲਈ।

Cloudflare 'ਤੇ MCP ਲਈ ਅੱਗੇ ਕੀ ਹੈ

ਜੇਕਰ ਤੁਹਾਡੀ ਸਾਈਟ ਦਾ ਕੰਟੈਂਟ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਸਟੈਟਿਕ ਬੱਕਟ ਵਿੱਚ ਹੈ, ਤਾਂ ਇੱਕ MCP ਐਂਡਪੁਆਇੰਟ ਜੋੜਨਾ ਕੁਝ ਲਾਈਨਾਂ ਦੇ ਕੋਡ ਅਤੇ ਇੱਕ ਸਿੰਗਲ ਰੂਟ ਜਿੰਨਾ ਸੌਖਾ ਹੋ ਸਕਦਾ ਹੈ। ਪ੍ਰੋਟੋਕੋਲ ਹੁਣ ਛੋਟੇ ਸਰਵਰਾਂ ਦੀਆਂ ਲੋੜਾਂ ਦੇ ਅਨੁਕੂਲ ਹੈ—ਇੱਕ ਸਾਧਾਰਨ HTTP ਐਂਡਪੁਆਇੰਟ ਜਿਸ ਨੂੰ ਮੁਫ਼ਤ ਵਿੱਚ ਹੋਸਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ 10 ms CPU ਸੀਮਾ ਦੇ ਅੰਦਰ ਰਹਿੰਦੇ ਹੋ।