Model Context Protocol (MCP) তার session state বাদ দিয়ে সেটিকে রসিদ-শৈলীর (receipt-style) রিকোয়েস্ট এবং একটি নতুন server/discover কমান্ড দিয়ে প্রতিস্থাপন করেছে। ডেভেলপাররা এখন AWS Lambda-এর মতো serverless প্ল্যাটফর্মে MCP চালাতে পারবেন এবং দীর্ঘকাল ধরে নির্ভরযোগ্যতাকে ক্ষতিগ্রস্ত করা “single waiter” বা একক ওয়েটারের প্রতিবন্ধকতা এড়াতে পারবেন।

কেন পুরনো মডেলটি গুরুত্বপূর্ণ ছিল

MCP মূলত একটি নির্দিষ্ট সার্ভারের সাথে একটি persistent connection বা স্থায়ী সংযোগের প্রয়োজন হতো। সার্ভারটি ব্যবহারকারীর একটি “table number”—একটি লুকানো session যেখানে context, নিয়ম এবং পেন্ডিং অ্যাকশনগুলো জমা থাকত—তা ধরে রাখত। যখন সেই সার্ভারটি ক্র্যাশ করত, তখন session-টি হারিয়ে যেত এবং ক্লায়েন্টকে আবার শুরু থেকে শুরু করতে হতো।

এই আপডেটে কী ভিন্নতা আনা হয়েছে

  • No sessions – প্রতিটি রিকোয়েস্ট সার্ভারের প্রয়োজনীয় সবকিছু বহন করে নিয়ে যায়, ঠিক যেমন একটি রেস্তোরাঁর রসিদ যা যেকোনো ক্যাশিয়ার পড়তে পারেন। “initialize” হ্যান্ডশেক এখন আর প্রয়োজন নেই।
  • Receipt model – প্রতিটি রিকোয়েস্টের শুরুতে একটি ছোট meta block থাকে যাতে ভার্সন তথ্য এবং প্রয়োজনীয় প্যারামিটার অন্তর্ভুক্ত থাকে। সার্ভার রিকোয়েস্টটি আলাদাভাবে (in isolation) প্রসেস করে এবং তারপর resultType, ttlMs (মিলিসেকেন্ডে time-to-live) এবং cacheScope সহ একটি ফলাফল প্রদান করে। এই ফিল্ডগুলো ক্লায়েন্টকে নিরাপদে উত্তরটি ক্যাশ (cache) করতে এবং এটি কখন মেয়াদোত্তীর্ণ হবে তা জানতে সাহায্য করে।
  • Server/discover – একটি নতুন কমান্ড ক্লায়েন্টকে সার্ভারের বর্তমান সক্ষমতা সম্পর্কে জানতে (query করতে) সাহায্য করে। এর রেসপন্স তাৎক্ষণিক এবং এটি পূর্ববর্তী কোনো ইন্টারঅ্যাকশনের ওপর নির্ভর করে না।
  • Subscriptions/listen – এটি একটি বাজার (buzzer)-এর মতো কাজ করে: ক্লায়েন্ট আপডেটের জন্য সাবস্ক্রাইব করে এবং শুধুমাত্র কিছু পরিবর্তন হলেই নোটিফিকেশন পায়, যা polling traffic কমিয়ে দেয়।
  • Input_required flow – যদি সার্ভারের আরও তথ্যের প্রয়োজন হয়, তবে এটি ক্লায়েন্টের কাছে পুনরায় না চেয়ে একটি input_required রেসপন্স প্রদান করে। এরপর ক্লায়েন্ট একটি ফলো-আপ রিকোয়েস্টের মাধ্যমে প্রয়োজনীয় তথ্য সরবরাহ করে।

যেহেতু সার্ভার এখন আর state ধরে রাখে না, তাই যেকোনো stateless compute environment-এ MCP endpoint হোস্ট করা সম্ভব। অন-ডিমান্ড চালু হওয়া, পজ হওয়া বা বিভিন্ন জোনে মাইগ্রেট হওয়া ফাংশনগুলো কোনো কথোপকথন বা কনভারসেশন বিচ্ছিন্ন না করেই ট্রাফিক সামলাতে পারে।

কারা লাভবান হচ্ছে, কারা চিন্তিত

AI front-end তৈরি করা ডেভেলপাররা – আরও সহজ এবং নির্ভরযোগ্য ব্যাক-এন্ড পাবেন। ইনফ্রাস্ট্রাকচার টিমগুলো – সস্তা এবং auto-scaling সার্ভিসে MCP প্রোভিশন করতে পারবে। MCP সার্ভার মেইনটেইনাররা – ttlMs, cacheScope প্রদান করতে এবং server/discover কন্ট্রাক্ট মেনে চলতে হ্যান্ডলারগুলো পুনরায় লিখতে হবে। যে কোডগুলো persistent session-এর ওপর নির্ভরশীল ছিল, সেগুলোর refactoring প্রয়োজন হবে। কঠোর কমপ্লায়েন্স মেনে চলা এন্টারপ্রাইজগুলো – আরও স্পষ্ট ডেটা-লাইফসাইকেল কন্ট্রোলের সুবিধা পাবে।

লুকিয়ে থাকা বিস্তারিত তথ্য: ভার্সন নেগোসিয়েশন

প্রতিটি রসিদে একটি ছোট meta block থাকে যা ক্লায়েন্ট প্রত্যাশিত প্রোটোকল ভার্সনটি জানিয়ে দেয়।

যা এখনও অনিশ্চিত

পরবর্তীতে যা লক্ষ্য রাখতে হবে

সারসংক্ষেপ

session state বাদ দিয়ে এবং প্রতিটি ইন্টারঅ্যাকশনকে একটি স্বয়ংসম্পূর্ণ রসিদে রূপান্তর করার মাধ্যমে, MCP এখন serverless ইকোসিস্টেমের সাথে সামঞ্জস্যপূর্ণ হয়ে উঠেছে। এই পরিবর্তনের ফলে MCP আরও স্থিতিশীল এবং স্কেলেবল হয়েছে, যা সার্ভারগুলোকে যেকোনো জায়গায় চালানো এবং যেকোনো সাধারণ ওয়েব সার্ভিসের মতো স্কেল করার সুযোগ করে দেয়।