Model Context Protocol (MCP) এখন stateless হয়ে গেছে, এবং এই পরিবর্তনের ফলে ডেভেলপাররা Cloudflare Workers-এর free tier-এ ছোট ছোট MCP server চালু করতে পারবেন—যদি প্রতিটি request প্ল্যাটফর্মের 10 ms CPU limit-এর নিচে থাকে।

কেন এই পরিবর্তনটি গুরুত্বপূর্ণ

সাম্প্রতিক দুটি পদক্ষেপ এর পথ প্রশস্ত করেছে। প্রথমত, MCP core তার session-based ডিজাইন ত্যাগ করেছে এবং এখন কোনো handshake ছাড়াই চলে; যেকোনো request কোডের যেকোনো instance দ্বারা হ্যান্ডেল করা যেতে পারে। দ্বিতীয়ত, Cloudflare McpAgent class সরিয়ে দিয়েছে এবং এখন নতুন server-এর জন্য plain request handler ব্যবহারের পরামর্শ দিচ্ছে। একত্রে এগুলো Durable Objects বা অন্যান্য stateful storage-এর প্রয়োজনীয়তা দূর করে, যা free plan-এ MCP চালানোর ক্ষেত্রে প্রধান বাধা ছিল।

free tier দিয়ে আসলে কী করা সম্ভব

আমরা একটি read-only MCP server তৈরি করেছি যা একটি static site থেকে Markdown ফাইল পরিবেশন করে। সার্ভারটি দুটি tool—list_articles এবং get_article—ব্যবহার করে, যেখানে method গুলো route করার জন্য একটি সাধারণ switch statement ব্যবহার করা হয়েছে। কোনো ভারী ক্যালকুলেশন নেই, শুধু static assets ফেচ করা হয়।

Cloudflare-এর CPU accounting মোট response time থেকে আলাদা। CPU time শুধুমাত্র আপনার JavaScript এক্সিকিউট করতে ব্যয় হওয়া সাইকেলগুলো গণনা করে; network call বা disk read-এর জন্য অপেক্ষার সময় এতে অন্তর্ভুক্ত নয়। এই পার্থক্যটি গুরুত্বপূর্ণ কারণ free tier-এ প্রতি request-এ CPU limit 10 ms, যেখানে total latency আরও বেশি হতে পারে।

free tier-এ আমাদের পরিমাপগুলো ছিল এরকম:

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

এমনকি সবচেয়ে বড় আর্টিকেলটিও 10 ms বাজেটের একটি সামান্য অংশ ব্যবহার করেছে। ক্লায়েন্ট সাইডে দৃশ্যমান ধীরগতি ফাইলটি পড়ার জন্য অপেক্ষার কারণে হয়েছিল, কোড এক্সিকিউশনের কারণে নয়।

যেখানে সীমাবদ্ধতা বাধা হয়ে দাঁড়ায়

ডেটা একটি স্পষ্ট প্যাটার্ন নির্দেশ করে:

  • Data-serving tools (সহজ read, listing) অনায়াসেই limit-এর নিচে থাকে।
  • Compute-heavy tools (parsing, rendering, hashing, বা যেকোনো অ্যালগরিদমিক কাজ) দ্রুত 10 ms বাজেট শেষ করে দিতে পারে।

যদি কোনো tool-এর সামান্যর বেশি প্রসেসিংয়ের প্রয়োজন হয়, তবে ডেভেলপারদের একটি paid Workers plan-এ যেতে হবে। $5 plan-এ limit প্রতি request-এ 30 সেকেন্ড পর্যন্ত বাড়ানো হয়।

কারা লাভবান হচ্ছে এবং কাদের সতর্ক থাকতে হবে

ছোট সাইটগুলো যারা ইতিমধ্যে Markdown ফাইল বা RSS feed হোস্ট করে, তারা একটি মাত্র নতুন route যোগ করে একটি MCP endpoint প্রকাশ করতে পারে এবং free plan-এ থাকতে পারে। এর মানে হলো শৌখিন ডেভেলপার (hobbyists), ডকুমেন্টেশন সাইট বা কম ট্রাফিকযুক্ত ব্লগের জন্য অপারেটিং খরচ কম হবে এবং জটিলতাও কমবে।

যদি কোনো tool-এর সামান্যর বেশি প্রসেসিংয়ের প্রয়োজন হয়, তবে ডেভেলপারদের একটি paid Workers plan-এ যেতে হবে।

লঞ্চ করার আগে যা পরীক্ষা করবেন

  • Profile your tool: কিছু প্রতিনিধিধর্মী request চালান এবং Cloudflare-এর dashboard-এ CPU meter পরীক্ষা করুন।
  • Separate static and dynamic paths: static file serving free tier-এ রাখুন এবং compute-intensive call গুলো একটি paid worker বা অন্য কোনো backend-এ route করুন।
  • Watch for hidden latency: Network wait CPU-র ওপর প্রভাব ফেলে না, কিন্তু এটি ব্যবহারকারীর অভিজ্ঞতায় প্রভাব ফেলে। আপনি যে ফাইলগুলো পরিবেশন করছেন সেগুলোর জন্য edge caching বিবেচনা করুন।

পাল্টা যুক্তি: free plan অসীম নয়

যদিও stateless core-এর কারণে Durable Objects-এর প্রয়োজনীয়তা দূর হয়েছে, তবুও 10 ms-এর সীমা একটি কঠোর সীমাবদ্ধতা হিসেবে রয়ে গেছে। ডেভেলপাররা যদি সামান্যতম parsing-এর (যেমন: markdown থেকে HTML কনভার্সন) খরচ কম মনে করেন, তবে তারা অপ্রত্যাশিতভাবে limit-এ পৌঁছে যেতে পারেন। Free tier মূলত "serve-as-is" বা সরাসরি ফাইল পরিবেশনের ক্ষেত্রে উপযোগী, তাৎক্ষণিক কন্টেন্ট জেনারেশনের জন্য নয়।

Cloudflare-এ MCP-এর ভবিষ্যৎ কী

যদি আপনার সাইটের কন্টেন্ট ইতিমধ্যে একটি static bucket-এ থাকে, তবে একটি MCP endpoint যোগ করা মাত্র কয়েক লাইন কোড এবং একটি single route-এর মতো সহজ হতে পারে। প্রোটোকলটি এখন ছোট সার্ভারগুলোর প্রয়োজনের সাথে সামঞ্জস্যপূর্ণ—একটি সাধারণ HTTP endpoint যা বিনামূল্যে হোস্ট করা সম্ভব, যতক্ষণ আপনি 10 ms CPU ceiling-এর নিচে থাকেন।