আপনার MCP সার্ভারের ৪০টি টুলের প্রয়োজন নেই

MCP ডেমোগুলোতে প্রায়শই সবকিছু একসাথে দেখানো হয়। তারা প্রতিটি এন্ডপয়েন্ট এবং প্রতিটি ডাটাবেস টেবিল দেখায়। তারা দাবি করে যে এজেন্ট যেকোনো কিছু কল করতে পারে।

এটি দশ মিনিটের জন্য শক্তিশালী মনে হতে পারে। তারপর মডেলটি ব্যর্থ হয়। এটি ভুল টুল কল করে। এটি ভুল ফরম্যাটে আর্গুমেন্ট পাস করে। এটি একটি সার্চ এন্ডপয়েন্ট থেকে চার্ট চায়। এটি একটি ধ্বংসাত্মক (destructive) কাজ পুনরায় করার চেষ্টা করে।

সমস্যাটি MCP-তে নয়। সমস্যাটি হলো MCP-কে আপনার ব্যাকএন্ডের জন্য একটি জাদুকরী অ্যাডাপ্টার হিসেবে বিবেচনা করা।

একটি MCP সার্ভার মানে কেবল আপনার API-কে এজেন্টদের জন্য সহজলভ্য করা নয়। এটি একটি অত্যন্ত আক্ষরিক এবং খুব সহজেই বিভ্রান্ত হতে পারে এমন ব্যবহারকারীর জন্য একটি প্রোডাক্ট সারফেস। সেই ব্যবহারকারী হলো একটি ল্যাঙ্গুয়েজ মডেল।

আপনি যদি একটি মডেলকে ৪০টি একই ধরণের টুল দেন, তবে আপনি তাকে ক্ষমতা দিচ্ছেন না। আপনি তাকে প্রায় সঠিক হওয়ার ৪০টি উপায় দিচ্ছেন।

আপনার API রুটগুলোকে হুবহু কপি (mirror) করা বন্ধ করুন। মানুষ ডকুমেন্টেশন পড়তে পারে এবং প্রেক্ষাপট (context) বুঝতে পারে। মডেলগুলো নাম এবং বর্ণনার প্যাটার্ন ম্যাচ করে।

ব্যবহারকারীর উদ্দেশ্যের (user intent) ওপর ভিত্তি করে আপনার MCP লেয়ার তৈরি করুন।

প্রতিটি রুটকে হুবহু কপি করার পরিবর্তে, সেগুলোকে স্পষ্ট সীমানায় গ্রুপ করুন:

  • মার্কেট সামারির জন্য একটি টুল
  • রিলিজ ক্যালেন্ডারের জন্য একটি টুল
  • নির্দিষ্ট ডাটা স্ন্যাপশটের জন্য একটি টুল
  • ঐতিহাসিক নির্দেশকগুলোর (historical indicators) জন্য একটি টুল

একটি API রুট বলে: আপনি যদি এই রিকোয়েস্টটি পাঠান, তবে সার্ভার রেসপন্স করবে। একটি MCP টুলের বলা উচিত: এই নির্দিষ্ট কাজের জন্য আমাকে ব্যবহার করুন, এই নির্দিষ্ট ইনপুটগুলোর সাথে, এবং এই নির্দিষ্ট ফলাফলটি আশা করুন।

ভালো টুলের বর্ণনা হলো রাউটিং লজিক, মার্কেটিং কপি নয়।

খারাপ: name: get_data description: Gets data from the API.

আরও ভালো: name: lookup_release_calendar description: একটি কারেন্সি এবং তারিখের পরিসরের জন্য নির্ধারিত অর্থনৈতিক ইভেন্টগুলো রিটার্ন করুন। আসন্ন ম্যাক্রো ইভেন্ট সম্পর্কে প্রশ্নের উত্তর দেওয়ার আগে এটি ব্যবহার করুন।

আরও উন্নত এজেন্টের জন্য এই নিয়মগুলো অনুসরণ করুন:

১. সাধারণ বা নিরস নাম ব্যবহার করুন। ডেভেলপাররা fetch বা query-এর মতো সংক্ষিপ্ত নাম পছন্দ করেন। মডেলগুলোর search_docs বা check_deployment_status-এর মতো সুনির্দিষ্ট নাম প্রয়োজন। অস্পষ্ট নামগুলো ব্যয়বহুল (expensive)।

২. রেসপন্স শেপ (response shape) নিয়ন্ত্রণ করুন। বিশাল নেস্টেড অবজেক্ট রিটার্ন করবেন না। কাজটি সম্পন্ন করার জন্য প্রয়োজনীয় ক্ষুদ্রতম শেপটি রিটার্ন করুন। মডেল যদি অতিরিক্ত ডাটা দেখে, তবে এটি ভুল ফিল্ড ব্যবহার করবে বা বিস্তারিত তথ্য নিয়ে হ্যালুসিনেশন (hallucinate) করবে।

৩. ব্যর্থতার জন্য ডিজাইন করুন। প্রোডাকশন কোয়ালিটি নির্ভর করে আপনি কীভাবে এরর (error) হ্যান্ডেল করছেন তার ওপর। কেবল একটি 500 এরর বা একটি খালি অ্যারে (empty array) রিটার্ন করবেন না। মডেলকে জানান কেন এটি ব্যর্থ হয়েছে। যদি কোনো রেকর্ড না মিলে, তবে মডেলকে ব্যবহারকারীকে একটি বিস্তৃত তারিখের পরিসর (wider date range) প্রস্তাব করতে বলুন।

সেরা এজেন্ট টুলটি সবচেয়ে শক্তিশালী টুল নয়। এটি হলো সেই টুল যা মডেল ভুল বুঝতে পারে না।

উৎস: https://dev.to/roberttidball/your-mcp-server-doesnt-need-40-tools-2ig1

ঐচ্ছিক লার্নিং কমিউনিটি: https://t.me/GyaanSetuAi