MCP টুল তার স্কিমা পরিবর্তন করেছে। আপনার এজেন্ট তা খেয়াল করেনি।

আপনার টুল কলটি ক্র্যাশ করেনি। এটি একটি 200 স্ট্যাটাস কোড এবং বৈধ JSON রিটার্ন করেছে।

কিন্তু এটি ভুল কন্ট্রাক্টের (contract) বিপরীতে কাজ করেছে। আপস্ট্রিম সার্ভার তিন দিন আগে একটি ফিল্ডের নাম পরিবর্তন করেছে। আপনার এজেন্ট পুরনো নামটিই পাঠাতে থাকল। সার্ভারটি নিঃশব্দে সেটি বাদ দিয়ে দিল। ফলাফলটি খালি (empty) ফিরে এল। কোনো এরর (error) দেখা দিল না। এক সপ্তাহ কেউ এটি খেয়াল করেনি।

এটি হলো একটি সাইলেন্ট ফেইলিওর (silent failure)। এটি সেই ধরণের শব্দবহুল সমস্যা নয় যেখানে লগগুলো লাল হয়ে যায়। এটি এমন এক ধরণের সমস্যা যেখানে সার্ভারটি সঠিকভাবে সাড়া দেয়, কিন্তু ডেটা ভুল থাকে।

MCP সার্ভার কলগুলোর মাঝখানে একটি টুলের কন্ট্রাক্ট পরিবর্তন করতে পারে। তারা একটি প্যারামিটার রিনেম করতে পারে বা একটি ফিল্ডের বর্ণনা পরিবর্তন করতে পারে। এই পরিবর্তনগুলো প্রায়শই কাঠামোগতভাবে (structurally) বৈধ থাকে। JSON ভ্যালিডেশন সফল হয়। সার্ভার 200 রেসপন্স দেয়। আপনার এজেন্ট একটি মাত্র এরর ছাড়াই ভুল ডেটা নিয়ে কাজ চালিয়ে যায়।

সমাধানটি সহজ: • প্রতিটি টুল কন্ট্রাক্টের একটি SHA-256 হ্যাশ পিন (pin) করে রাখুন। • সেই হ্যাশের মধ্যে স্কিমা এবং বর্ণনা (description) উভয়ই অন্তর্ভুক্ত করুন। • প্রতিটি কলের আগে হ্যাশটি পরীক্ষা করুন। • যদি কন্ট্রাক্টে কোনো পরিবর্তন (drift) দেখা দেয়, তবে কলটি থামিয়ে দিন।

আমরা মূলত টুলটি উত্তর দিচ্ছে কি না তার ওপর মনোযোগ দিই। আমরা স্ট্যাটাস কোড পরীক্ষা করি। আমরা টাইমআউট সেট করি। আমরা 5xx এরর হলে পুনরায় চেষ্টা (retry) করি। এজেন্ট যখন স্কিমাটি শিখেছিল এবং যখন কলটি করেছিল—এই দুই সময়ের মাঝখানে কন্ট্রাক্ট পরিবর্তিত হয়েছে কি না, তা প্রায় কেউ পরীক্ষা করে না।

একটি MCP সার্ভার tools/list-এর মাধ্যমে টুলগুলো প্রকাশ করে। প্রতিটি টুলের একটি inputSchema এবং একটি বর্ণনা (description) থাকে। আপনার এজেন্ট একটি সেশনের শুরুতে এটি একবার পড়ে নেয়।

সার্ভার আপডেট হলে এটি যা করতে পারে:

  • অতিরিক্ত প্রপার্টিগুলো খোলা রেখে একটি প্যারামিটারের নাম পরিবর্তন করতে পারে (যেমন query থেকে q)। পুরনো প্যারামিটারটি নিঃশব্দে বাদ পড়ে যায়।
  • একটি ফিল্ডের অর্থ পরিবর্তন করতে পারে। একটি লিমিট "max results" থেকে পরিবর্তিত হয়ে "page index" হতে পারে। টাইপটি ইন্টিজার (integer) হিসেবেই থাকে, তাই ভ্যালিডেশন সফল হয়।
  • একটি enum-এর পরিসর কমিয়ে দিতে পারে। একটি বৈধ মান নতুন কোনো ডিফল্ট মানে রূপান্তরিত হতে পারে।

MCP স্পেসিফিকেশন অনুযায়ী, লিস্ট পরিবর্তন হলে একটি সার্ভারের ক্লায়েন্টকে জানানো উচিত (SHOULD)। এটি অবশ্যই (MUST) করতে হবে এমন বলা নেই। অনেক সার্ভার এই নোটিফিকেশন পাঠাবে না। এমনকি তারা পাঠালেও, একটি নির্দিষ্ট টুলের স্কিমা পরিবর্তিত হয়েছে তা হয়তো আপনাকে জানাবে না।

স্ট্রাকচারাল ভ্যালিডেশনের (structural validation) ওপর নির্ভর করা বন্ধ করুন। এটি অর্থের পরিবর্তন বুঝতে পারে না।

আপনার MCP টুলগুলোকে সফটওয়্যার ডিপেন্ডেন্সি (software dependencies)-এর মতো বিবেচনা করুন। একটি লকফাইল (lockfile) পদ্ধতি ব্যবহার করুন। প্রথমবার যোগাযোগের সময় টুলের স্কিমা এবং বর্ণনার একটি SHA-256 হ্যাশ নিন। প্রতিটি কলের আগে হ্যাশটি পুনরায় গণনা করুন। যদি সেগুলো মিলে যায়, তবে এগিয়ে যান। যদি না মিলে, তবে পরিবর্তনটি (drift) চিহ্নিত করুন এবং থামিয়ে দিন।

বর্ণনার (description) হ্যাশিং করাই হলো আসল রহস্য। যদি একটি প্যারামিটার "max results" থেকে "page index"-এ পরিবর্তিত হয়, তবে স্কিমা দেখতে একই রকম মনে হবে। কিন্তু শব্দ পরিবর্তিত হওয়ায় হ্যাশ পরিবর্তিত হয়ে যাবে। এটি সেই সিম্যান্টিক ড্রিফট (semantic drift) ধরতে পারে যা ভ্যালিডেশন মিস করে।

কন্ট্রাক্টে পরিবর্তন হলে অনুমান করবেন না। অন্ধভাবে পুনরায় চেষ্টা (retry) করবেন না। থামুন, পার্থক্যটি লগ (log) করুন এবং কন্ট্রাক্টটি ঠিক করুন।

Source: https://dev.to/0012303/the-mcp-tool-your-agent-calls-changed-its-schema-it-didnt-notice-5g6m

Optional learning community: https://t.me/GyaanSetuAi