এমসিপি: ত্রুটি এবং সম্ভাবনা

মেশিন কমিউনিকেশন প্রোটোকল (MCP)-এর সীমাবদ্ধতা এবং সম্ভাবনা নিয়ে একটি সমালোচনামূলক আলোচনা

প্রযুক্তি বিশ্বে, বিশেষ করে লার্জ ল্যাঙ্গুয়েজ মডেলের (LLMs) ক্ষেত্রে মেশিন কমিউনিকেশন প্রোটোকল (MCP) ধারণাটি যথেষ্ট মনোযোগ আকর্ষণ করেছে। এটি LLM এবং বাহ্যিক সংস্থানগুলোর মধ্যে মিথস্ক্রিয়াকে সুগম করার প্রতিশ্রুতি দেয়, তবে একটি গভীর পর্যালোচনাতে বেশ কিছু অন্তর্নিহিত সমস্যা এবং সীমাবদ্ধতা প্রকাশ পায়, যা মনোযোগের দাবি রাখে। এই বিশ্লেষণে এমসিপি (MCP) সম্পর্কিত সমালোচনা, এর দুর্বলতা, পরিমাপযোগ্যতার চ্যালেঞ্জ এবং এআই (AI) এজেন্ট বিকাশের উপর এর বিস্তৃত প্রভাবগুলো নিয়ে আলোচনা করা হলো।

এমসিপি (MCP)-এর দায়িত্বের অতিভার

একটি সাধারণ সমালোচনা হলো এমসিপিকে (MCP) অতিরিক্ত দায়িত্ব দেওয়া হচ্ছে। লেখকের মতে, এমসিপির (MCP) প্রধান কাজ হওয়া উচিত LLM-এর জন্য বাহ্যিক সংস্থানগুলোতে প্রবেশ এবং তাদের সাথে যোগাযোগ করার একটি প্রবেশদ্বার হিসেবে কাজ করা। এটিকে শুধুমাত্র একটি ‘দরজা’ বা ‘সেতু’ হিসেবে দেখলে এর উদ্দেশ্য এবং সীমাবদ্ধতা স্পষ্ট হবে।

দুর্ঘটনাজনিত ডেটা প্রকাশ, প্রম্পট ইনজেকশন দুর্বলতা এবং খরচ নিয়ন্ত্রণের ঘাটতির মতো সমস্যাগুলোকে সরাসরি এমসিপির (MCP) উপর চাপানো ভুল। এই সমস্যাগুলো ডেভেলপারদের তাদের নিয়ন্ত্রণের মধ্যে সমাধান করা উচিত। ডেভেলপারদের রেট লিমিট প্রয়োগ করতে হবে এবং ব্যবহার নিরীক্ষণ করতে হবে, প্রোটোকল যাই হোক না কেন। এটিকে গতির জন্য রাস্তার উপর দোষ চাপানোর সাথে তুলনা করা যায় - অবকাঠামো ব্যক্তিগত আচরণের জন্য দায়ী নয়।

পরিশেষে, উত্থাপিত উদ্বেগের অনেকগুলি এআই (AI) এজেন্টদের কাছে কাজ অর্পণের সাথে সম্পর্কিত বৃহত্তর সমস্যা। ডেভেলপারদের তাদের নির্দিষ্ট অ্যাপ্লিকেশনগুলোর মধ্যে এই চ্যালেঞ্জগুলো পরিচালনার দায়িত্ব নিতে হবে, API নিজেই সবকিছু পরিচালনা করবে এমন প্রত্যাশা না করে।

এলএলএম (LLM) এবং প্রম্পট ইনজেকশনের দ্বিধারী তলোয়ার

এমসিপি (MCP) নিয়ে সাম্প্রতিক আলোচনা প্রায়শই ধারালো ছুরির অন্তর্নিহিত বিপদ সম্পর্কে সতর্কতার মতো শোনায় - ভুলভাবে ধরলে এটি কাটতে পারে। প্রম্পট ইনজেকশন একটি গুরুত্বপূর্ণ উদ্বেগ, যা LLM-এর প্রকৃতির ফলস্বরূপ। প্রম্পট ইনজেকশন দূর করার প্রচেষ্টা LLM-এর সেই ক্ষমতাগুলোকে হ্রাস করতে পারে, যা এটিকে মূল্যবান করে তোলে।

ঐতিহ্যবাহী সিস্টেমগুলোতে ‘নিয়ন্ত্রণ বনাম ডেটা’ বিভাজনের ধারণা LLM-এ স্বাভাবিকভাবে বিদ্যমান নেই। LLM এই অনমনীয় বিভাজন না থাকার কারণেই তাদের শক্তি এবং সাধারণীকরণ ক্ষমতা অর্জন করে। এই অন্তর্নিহিত বৈশিষ্ট্য তাদের প্রম্পট ইনজেকশন আক্রমণের জন্য দুর্বল করে তোলে।

রিমোট এমসিপি (MCP) একটি পরিষেবা হিসাবে ঝুঁকি তৈরি করতে পারে, তবে ত্রুটিটি প্রোটোকলের মধ্যে নয়, বরং অবিশ্বস্ত তৃতীয় পক্ষের কাছে সংবেদনশীল কাজগুলো অর্পণের মধ্যে নিহিত। এই উপমাটি একটি এলোমেলো রুম্বার সাথে একটি ছুরি টেপ করার ধারণার সাথে তুলনীয় - সমস্যাটি ছুরির মধ্যে নয়, বরং এটিকে একটি অপ্রত্যাশিত ডিভাইসের সাথে সংযুক্ত করার সিদ্ধান্তের মধ্যে নিহিত।

‘সতর্ক থাকুন’ বা সুরক্ষামূলক সরঞ্জাম ব্যবহারের পরামর্শগুলো প্রযুক্তিগতভাবে সঠিক হলেও মূল সমস্যাটি এড়িয়ে যায়: একটি ধারালো সরঞ্জামকে একটি অনিয়ন্ত্রিত সিস্টেমের সাথে একত্রিত করার ভুল সিদ্ধান্ত।

মাপযোগ্যতার চ্যালেঞ্জ

নিরাপত্তা উদ্বেগের বাইরেও, এমসিপি (MCP) মৌলিক পরিমাপযোগ্যতার সীমাবদ্ধতার সম্মুখীন। লেখক LLM-এর নির্ভরযোগ্যতা এবং প্রদত্ত নির্দেশমূলক প্রসঙ্গের পরিমাণের মধ্যে একটি নেতিবাচক সম্পর্ক তুলে ধরেছেন। এটি সাধারণ বিশ্বাসকে চ্যালেঞ্জ করে যে আরও ডেটা এবং ইন্টিগ্রেশন যোগ করলে স্বয়ংক্রিয়ভাবে সমস্যার সমাধান হবে। সরঞ্জাম এবং ইন্টিগ্রেশনের সংখ্যা বাড়ার সাথে সাথে একটি এজেন্টের কর্মক্ষমতা হ্রাস পেতে পারে, সেই সাথে প্রতিটি অনুরোধের খরচও বাড়তে পারে।

লেখক জোর দিয়েছেন যে এমসিপি (MCP) একটি নির্দিষ্ট প্রান্তিকের বাইরে স্কেল করে না। একটি এজেন্টের প্রসঙ্গের মধ্যে সীমাহীন সংখ্যক সরঞ্জাম যুক্ত করার চেষ্টা অনিবার্যভাবে এর ক্ষমতাকে নেতিবাচকভাবে প্রভাবিত করবে। এই সীমাবদ্ধতা এমসিপি (MCP) ধারণার অন্তর্নিহিত এবং প্রমাণীকরণ সমস্যার চেয়ে বেশি মনোযোগের দাবি রাখে।

ব্যবহারকারীরা শেষ পর্যন্ত কর্মক্ষমতা হ্রাস অনুভব করতে পারেন, কারণ তারা আরও এমসিপি (MCP) সার্ভার সক্ষম করে, যার ফলে তাদের মধ্যে হস্তক্ষেপ ঘটে। এটি সাধারণ প্যাকেজ ম্যানেজমেন্ট সিস্টেমগুলোর সাথে সম্পূর্ণ বিপরীত, যেখানে অ-হস্তক্ষেপ একটি মৌলিক বৈশিষ্ট্য।

এমসিপির (MCP) মূল সমস্যা হলো এর প্রকৃত আচরণ ব্যবহারকারীর প্রত্যাশা থেকে বিচ্যুত হয়। এটা স্বীকার করা জরুরি যে এমসিপি (MCP) একটি প্লাগ-এন্ড-প্লে সমাধান নয়, যা কোনো পরিণতি ছাড়াই সীমাহীন সংখ্যক সরঞ্জামকে নির্বিঘ্নে একত্রিত করে।

ইউআই (UI) এবং সরঞ্জাম ব্যবস্থাপনার মাধ্যমে সীমাবদ্ধতা মোকাবেলা

এমসিপির (MCP) সীমাবদ্ধতাগুলোর একটি প্রস্তাবিত সমাধান হলো ইউজার ইন্টারফেসের (UI) উন্নতি করা। যদি কোনো সরঞ্জাম অনিচ্ছাকৃতভাবে চালানো হয়, তাহলে ইউআইতে (UI) এটিকে নিষ্ক্রিয় করার বা এর উদ্দেশ্যযুক্ত ব্যবহার স্পষ্ট করার জন্য এর বিবরণ পরিবর্তন করার একটি সহজ উপায় থাকা উচিত।

লেখক আরও উল্লেখ করেছেন যে প্রসঙ্গের বৃদ্ধি প্রায়শই উন্নত কর্মক্ষমতা এবং বাস্তব-বিশ্ব ব্যবহারের ক্ষমতাগুলোর দিকে পরিচালিত করে, যা কঠোরভাবে নেতিবাচক সম্পর্কের ধারণাটির বিরোধিতা করে। তবে, তারা স্বীকার করেন যে কিছু ক্ষেত্রে বা দুর্বলভাবে ডিজাইন করা প্রসঙ্গের কারণে কর্মক্ষমতা হ্রাস ঘটতে পারে।

সরঞ্জামের অপ্রতিরোধ্য পছন্দ মোকাবেলা করার জন্য একটি ‘বিভাজন এবং জয়’ পদ্ধতির পরামর্শ দেওয়া হয়েছে। এর মধ্যে একটি নির্দিষ্ট কাজের জন্য সবচেয়ে প্রাসঙ্গিক সরঞ্জামগুলো নির্বাচন করার জন্য বিশেষভাবে ডিজাইন করা একটি সরঞ্জাম যুক্ত করা জড়িত। এই ‘সরঞ্জাম-নির্বাচন সরঞ্জাম’ অন্য একটি LLM কল হতে পারে, যা উপলব্ধ সরঞ্জামগুলোর একটি উপসেট ‘পিতা’ এজেন্টের কাছে ফেরত দেওয়ার দায়িত্বে থাকবে। এই স্তরায়িত পদ্ধতি জটিলতা পরিচালনা করতে অতিরিক্ত স্তরের পরোক্ষতা যোগ করে।

তবে, কেবলমাত্র প্রসঙ্গের মধ্যে সরঞ্জাম থাকা মডেলের আউটপুটকে উল্লেখযোগ্যভাবে পরিবর্তন করতে পারে। প্রাসঙ্গিকভাবে প্রাসঙ্গিক সরঞ্জামগুলো (যেমন রিট্রিভাল-অগমেন্টেড জেনারেশন বা RAG-এর মাধ্যমে অর্জিত) উপকারী, তবে ‘get_tools’ অনুরোধের আড়ালে সমস্ত সরঞ্জাম লুকানো ক্ষতিকর হতে পারে।

পরিবহন এবং অনুমোদন স্তর হিসাবে এমসিপি (MCP)

এমসিপি (MCP) প্রাথমিকভাবে সরঞ্জাম-স্তরের অনুমোদনের উপর দৃষ্টি নিবদ্ধ করে একটি অনুরোধ/প্রতিক্রিয়া জীবনচক্রের সাথে একটি পরিবহন এবং ওয়্যার ফর্ম্যাট হিসাবে কাজ করে। প্রবন্ধে যুক্তি দেওয়া হয়েছে যে এমসিপির (MCP) সবচেয়ে বড় সমস্যা হলো এআই (AI) এজেন্টদের কার্যকরীভাবে সরঞ্জামগুলো রচনা করতে সক্ষম করতে এর ব্যর্থতা।

লেখক মনে করেন যে এমসিপি (MCP) প্রথম স্থানে অপ্রয়োজনীয় হতে পারে, কারণ এলএলএমগুলোতে (LLM) ইতিমধ্যে ওপেনএপিআই (OpenAPI) স্পেসিফিকেশন ব্যবহার করে নথিভুক্ত API-এর সাথে যোগাযোগ করার ক্ষমতা রয়েছে। অনুপস্থিত উপাদানটি হলো অনুমোদন - একটি এআই (AI) কোন API অ্যাক্সেস করতে পারবে তা নিয়ন্ত্রণ করার ক্ষমতা। এমসিপির (MCP) পরিবর্তে, লেখক এআইগুলোকে (AI) HTTP অনুরোধ করার অনুমতি দেওয়ার পরামর্শ দেন, যখন নির্দিষ্ট এন্ডপয়েন্টগুলোতে অনুমোদন প্রয়োগ করা হয়। এই পদ্ধতিটি বিদ্যমান API-গুলোকে পাতলা এমসিপি (MCP) সরঞ্জামগুলোর সাথে মোড়ানোর বর্তমান প্রবণতার সাথে সঙ্গতিপূর্ণ।

এমসিপির (MCP) একটি বিশেষ বিরক্তিকর দিক হলো স্ট্রিমিং সরঞ্জাম কলের ফলাফলের জন্য এর সমর্থন অভাব। একক অনুরোধ/প্রতিক্রিয়া জোড়া ক্লায়েন্টদের পৃষ্ঠাঙ্কনের জন্য বারবার সরঞ্জাম কল করতে বাধ্য করে, যা দীর্ঘ-চলমান প্রক্রিয়াগুলোকে বাধা দেয়। স্ট্রিমিং ক্ষমতা প্রয়োগ করা, সম্ভবত জিআরপিসি (gRPC) ব্যবহার করে, এমসিপির (MCP) কার্যকারিতা উল্লেখযোগ্যভাবে উন্নত করতে পারে।

সংবেদনশীল ডেটা প্রকাশের সহজতা

এমসিপি (MCP) নিয়ে একটি উল্লেখযোগ্য উদ্বেগ হলো সংবেদনশীল ডেটা প্রকাশের সহজ সম্ভাবনা। তদুপরি, এমসিপি (MCP) অন্তর্নিহিতভাবে এআই (AI) এজেন্টদের আরও নির্ভরযোগ্য করে তোলে না; এটি কেবল তাদের আরও সরঞ্জামে অ্যাক্সেস দেয়, যা কিছু পরিস্থিতিতে বিপরীতভাবে নির্ভরযোগ্যতা হ্রাস করতে পারে।

লেখক স্বীকার করেছেন যে তারা আশা করেন না যে এমসিপি (MCP) এই সমস্ত সমস্যার সমাধান করবে বা এর জন্য দায়ী থাকবে। বরং, এমসিপি (MCP) এই সমস্যাগুলোর জন্য একটি বৃহত্তর পৃষ্ঠ তৈরি করে, যার জন্য অ্যাপ ডেভেলপার এবং ব্যবহারকারীদের সতর্ক থাকতে হবে।

উপমা এবং নগর পরিকল্পনা

লেখক এই সমস্যাটি বোঝাতে নগর পরিকল্পনার উপমা ব্যবহার করেছেন। এমসিপিকে (MCP) একটি ছয় লেনের শহরের রাস্তার সাথে তুলনা করা, যেখানে গতির সীমা ২৫ মাইল প্রতি ঘণ্টা, নকশা এবং উদ্দেশ্যযুক্ত ব্যবহারের মধ্যে সংযোগ বিচ্ছিন্নতাকে তুলে ধরে। কেবল জরিমানা আরোপ করা বা বাহ্যিক ‘ফিক্স’ যোগ করা দুর্বল নকশার অন্তর্নিহিত সমস্যার সমাধান করে না।

কার্যকর নগর পরিকল্পনায় এমন রাস্তাগুলোর নকশা করা জড়িত, যা প্রাকৃতিকভাবে গতির সীমা মেনে চলতে উৎসাহিত করে। একইভাবে, এমসিপিকে (MCP) বাহ্যিক নিয়ন্ত্রণের উপর সম্পূর্ণরূপে নির্ভর না করে সম্ভাব্য ঝুঁকিগুলো হ্রাস করার জন্য ডিজাইন করা উচিত।

এলএলএমের (LLM) অবাঞ্ছিত পদক্ষেপ নেওয়া

নিবন্ধটি সেই প্রোটোকলগুলোর একটি বিস্তৃত সমালোচনার দিকে দৃষ্টি আকর্ষণ করে, যা এলএলএমগুলোকে (LLM) পরিষেবাগুলোতে পদক্ষেপ নেওয়ার অনুমতি দেয়। লেখক একটি মূল সমস্যা চিহ্নিত করেছেন: এলএলএম (LLM) এমন পদক্ষেপ নিতে পারে, যা ব্যবহারকারীরা নিতে চান না। তারা সেই পদক্ষেপগুলোর মধ্যে পার্থক্য করেন, যা এলএলএম (LLM) স্বাধীনভাবে নিতে পারে এবং যেগুলোর জন্য ব্যবহারকারীর প্রম্পটিং প্রয়োজন।

চূড়ান্ত লক্ষ্য পুরো ব্যবসা এলএলএম (LLM) দ্বারা পরিচালনা করা হলেও, প্রযুক্তি এখনও এই ধরনের স্বায়ত্তশাসনের জন্য প্রস্তুত নয়। বর্তমানে, ব্যবহারকারীরা সম্ভবত পূর্ব পর্যালোচনার আগে এআই (AI) দ্বারা ইমেল পাঠাতেও চান না।

লেখক ব্যবহারকারীকে নিশ্চিতকরণের জন্য অনুরোধ করার সমাধানটি প্রত্যাখ্যান করেন, কারণ ব্যবহারকারীরা স্বয়ংক্রিয় নিশ্চিতকরণের একটি প্যাটার্নে (“YOLO-mode”) পড়ার ঝুঁকি থাকে, যখন বেশিরভাগ সরঞ্জাম নিরীহ মনে হয়। এটিকে কার্ডের মাধ্যমে নগদ থেকে বেশি ব্যয় করার মানসিক ঘটনার সাথে তুলনা করা হয় - একটি সমস্যা, যা প্রযুক্তি নয় বরং মানুষের আচরণের গভীরে প্রোথিত।

মৌলিক প্রশ্ন: কেন শুধু API ব্যবহার করবেন না?

এমসিপি (MCP) নিয়ে আলোচনার একটি পুনরাবৃত্তিমূলক প্রশ্ন হলো কেন শুধু API সরাসরি ব্যবহার করা যায় না।

এমসিপি (MCP) সেই এলএলএম (LLM) ক্লায়েন্টগুলোকে API-এর সাথে যোগাযোগ করতে দেয়, যা ব্যবহারকারীরা সরাসরি নিয়ন্ত্রণ করেন না (যেমন ক্লড, চ্যাটজিপিটি, কার্সার, ভিএসকোড)। এমসিপি (MCP) ছাড়া, ডেভেলপারদের এলএলএম (LLM) API ব্যবহার করে কাস্টম ক্লায়েন্ট তৈরি করতে হতো, যা বিদ্যমান ক্লায়েন্টগুলোকে একটি সাবস্ক্রিপশন দিয়ে ব্যবহার করার চেয়ে অনেক বেশি ব্যয়বহুল, সেই সাথে নির্দিষ্ট সরঞ্জামগুলো কীভাবে ব্যবহার করতে হয় তাও শেখাতে হতো।

একজন ডেভেলপার তাদের এফএম (FM) হার্ডওয়্যার সিনথেসাইজারের সাথে ইউএসবি (USB)-এর মাধ্যমে সংযোগ স্থাপনের জন্য একটি এমসিপি (MCP) সার্ভার তৈরি করার অভিজ্ঞতা বর্ণনা করেছেন, যা এআই (AI) চালিত সাউন্ড ডিজাইন সক্ষম করে।

এলএলএম (LLM) ক্লায়েন্ট ইন্টিগ্রেশন এবং স্ট্যান্ডার্ডাইজেশন

মূল সমস্যা হলো সমস্ত এলএলএম (LLM) ক্লায়েন্ট নেটিভভাবে সরাসরি API মিথস্ক্রিয়া সমর্থন করে না, চ্যাটজিপিটি (ChatGPT) কাস্টম জিপিটি (GPT) অ্যাকশন একটি উল্লেখযোগ্য ব্যতিক্রম। অ্যানথ্রোপিক, গুগল এবং ওপেনএআই (OpenAI) ক্লড, চ্যাটজিপিটি (ChatGPT) এবং কার্সারের মতো এলএলএম (LLM)-চালিত ক্লায়েন্টগুলোর জন্য প্রক্রিয়াটিকে সুগম করতে একটি ভাগ করা প্রোটোকল হিসাবে এমসিপি (MCP) গ্রহণ করতে সম্মত হয়েছে।

এমসিপি (MCP) এলএলএম (LLM) ক্লায়েন্ট নির্মাতাদের জন্য প্রক্রিয়াটিকে সহজ করে তোলে। আপনি যদি কোনও এলএলএমকে (LLM) কোনও API-এর সাথে যোগাযোগ করতে চান, তবে আপনি কেবল একটি API কী সরবরাহ করে আশা করতে পারেন না যে এটি কাজ করবে - আপনাকে একটি এজেন্ট তৈরি করতে হবে।

এমসিপিকে (MCP) API নথিভুক্ত করার এবং কীভাবে কল করতে হয় তা বর্ণনা করার একটি উপায় হিসাবে দেখা যেতে পারে, সেই সাথে সেই ডকুমেন্টেশন প্রকাশ এবং কলগুলো সহজতর করার জন্য স্ট্যান্ডার্ডাইজড সরঞ্জামও রয়েছে। এটি অপ্রয়োজনীয় জটিলতা ছাড়াই API মোড়ানোর জন্য যথেষ্ট বিমূর্ততা সরবরাহ করে, তবে এই সরলতা ব্যবহারকারীদের ‘নিজের পায়ে গুলি’ করার দিকেও নিয়ে যেতে পারে।

এমসিপির (MCP) কার্যকারিতা এবং পুনঃব্যবহারযোগ্যতা

এমসিপি (MCP) ছাড়া, ডেভেলপারদের প্রতিটি বার ব্যবহারের সময় LLM-কে একটি সরঞ্জাম কীভাবে ব্যবহার করতে হয় তা বারবার ব্যাখ্যা করতে হতো। এর ফলে LLM ভুলে যাওয়া তথ্য বা অ-মানক API আচরণের কারণে সরঞ্জামটি সঠিকভাবে ব্যবহার করতে ব্যর্থ হতে পারে।

এই অবিরাম ব্যাখ্যা এবং নকল প্রসঙ্গের টোকেন নষ্ট করে, খরচ এবং সময় বাড়ায়। এমসিপি (MCP) প্রয়োজনীয় সমস্ত তথ্য একত্রিত করে এই প্রক্রিয়াটিকে সুগম করে, সরঞ্জাম ব্যবহারকে আরও দক্ষ করে তোলে এবং সরঞ্জাম ভাগ করে নেওয়া সহজ করে তোলে।

এলএলএম (LLM) সরবরাহকারীকে API ডকুমেন্টেশন সহ ‘এখানে একটি সরঞ্জাম রয়েছে যা আপনি ব্যবহার করতে পারেন’ বলার মাধ্যমে ব্যবহারকারীরা একাধিক চ্যাটে বারবার অনুস্মারক ছাড়াই সেই সরঞ্জামটি পুনরায় ব্যবহার করতে পারেন। এটি ডেস্কটপ এলএলএম (LLM) ক্লায়েন্টগুলোকে স্থানীয়ভাবে চলমান প্রোগ্রামগুলোর সাথে সংযোগ স্থাপনে সক্ষম করে, অপারেটিং সিস্টেম-নির্দিষ্ট এক্সিকিউশন প্রক্রিয়াগুলোর সমস্যা সমাধান করে।

এমসিপি (MCP) এবং স্থানীয় রিসোর্স অ্যাক্সেস

এমসিপি (MCP) এলএলএমগুলোর (LLM) জন্য ফাইল, পরিবেশের ভেরিয়েবল এবং নেটওয়ার্ক অ্যাক্সেসের মতো স্থানীয় সংস্থানগুলোতে অ্যাক্সেস সহজতর করে। এটি স্থানীয়ভাবে চালানোর জন্য ডিজাইন করা হয়েছে, যা এলএলএমকে (LLM) এই সংস্থানগুলোতে নিয়ন্ত্রিত অ্যাক্সেস দেয়।

স্ট্যান্ডার্ড এলএলএম (LLM) সরঞ্জাম কল ‘আকৃতি’ এমসিপি (MCP) সরঞ্জাম কল ‘আকৃতি’-কে ঘনিষ্ঠভাবে প্রতিফলিত করে, যা সরঞ্জামগুলোকে এজেন্টদের সাথে সংযোগ করার জন্য এটিকে একটি সরল মানক করে তোলে।

এমসিপি (MCP) এআই (AI) মডেলের কাছে প্রকাশিত ফাংশন কলিং স্কিমা এবং অন্তর্নিহিত API-গুলোর মধ্যে একটি সেতু হিসাবে কাজ করে। এটি ফাংশন কলগুলোকে সরঞ্জামগুলোতে অনুবাদ করে, নির্বিঘ্ন যোগাযোগ সক্ষম করে।

আপনি যদি কোনও সরঞ্জাম সরবরাহকারী হন, তবে এমসিপি (MCP) আপনার সরঞ্জামের সাথে সংযোগ স্থাপনের জন্য এআই (AI) এজেন্ট ফ্রন্টএন্ডের জন্য একটি স্ট্যান্ডার্ডাইজড প্রোটোকল সরবরাহ করে। এটি HTTP এবং ওপেনএপিআই (OpenAPI) কেন স্ট্যান্ডার্ড প্রোটোকল হতে পারে না সেই প্রশ্নের উত্তর দেয়।

এমসিপি (MCP) একটি মেটা-এপিআই (Meta-API) যা এন্ডপয়েন্ট এবং তাদের অপারেশনাল বিবরণ স্পেসিফিকেশনের মধ্যে অন্তর্ভুক্ত করে, যা এলএলএমগুলোকে (LLM) তাদের সাথে আরও কার্যকরভাবে যোগাযোগ করতে সক্ষম করে।

নির্দিষ্ট পরিস্থিতিতে এমসিপি (MCP)

এমসিপি (MCP) ব্যবহারকারীদের প্রশ্ন জিজ্ঞাসা বা কোন API ব্যবহার করতে হবে তা নিশ্চিত না হলে সমস্যা সমাধান করতে পারে। এটি পূর্ববর্তী বার্তাগুলোর উপর ভিত্তি করে অনুরোধগুলোও প্রক্রিয়া করতে পারে।

একজন ব্যবহারকারী তাদের ‘X’ পুনরুদ্ধার করতে এবং এটিকে একটি এন্ডপয়েন্টে পাঠানোর অভিজ্ঞতা বর্ণনা করেছেন। তারা দেখেছেন যে এমসিপি (MCP) এত সহজ কাজের জন্য অতিরিক্ত, যা ইঙ্গিত করে যে মৌলিক API মিথস্ক্রিয়াগুলোর জন্য এটি সর্বদা প্রয়োজনীয় নয়।

এমসিপিকে (MCP) এজেন্টিক অভিজ্ঞতাগুলোর জন্য বিশেষভাবে ডিজাইন করা নেটওয়ার্কে যোগাযোগ করতে পারে এমন সফ্টওয়্যার তৈরির জন্য একটি ফাস্টএপিআই (FastAPI) ওয়েব অ্যাপ ফ্রেমওয়ার্কের সাথে তুলনা করা হয়। এটিকে এআই (AI) এজেন্ট বিকাশের জন্য একটি স্ট্যান্ডার্ডাইজড ফ্রেমওয়ার্ক সরবরাহ করে ‘রেলস-ফর-স্কাইনেট’ হিসাবে দেখা যেতে পারে।

সরবরাহকারী নিয়ন্ত্রণের উদ্বেগ

উদ্বেগ রয়েছে যে এমসিপিকে (MCP) সিস্টেমের উপর সরবরাহকারী-পাশের নিয়ন্ত্রণ বাড়ানোর জন্য চাপ দেওয়া হচ্ছে। এলএলএম (LLM) সরবরাহকারীরা শেষ পর্যন্ত API অ্যাক্সেস সীমাবদ্ধ করতে পারে, যেমন গুগল জিমেইলের সাথে IMAP/SMTP ব্যবহার করা কঠিন করে তুলেছিল।

ওপেনএপিআই (OpenAPI) এজেন্টদের /openapi.json থেকে API স্পেসিফিকেশন পুনরুদ্ধার করতে দেয়।

এমসিপি (MCP) দ্রুত মিথস্ক্রিয়া সক্ষম করে, যা ব্যবহারকারীদের ইনপুট ডেটা প্রস্তুত করতে, API-তে পাঠাতে, আউটপুট পার্স করতে এবং প্রতিটি বার্তার জন্য প্রক্রিয়াটি পুনরাবৃত্তি করতে সময় ব্যয় না করে সেকেন্ডের মধ্যে কাজগুলো সম্পন্ন করতে দেয়।

স্যান্ডবক্সিং এবং সুরক্ষা ঝুঁকি

সবচেয়ে বড় সমস্যাগুলোর মধ্যে একটি হলো কীভাবে একই বার্তা থ্রেডে একটি এমসিপি (MCP) সার্ভার টুলের আউটপুট অন্যান্য সরঞ্জামগুলোকে প্রভাবিত করতে পারে। এটি অনাকাঙ্ক্ষিত পরিণতিগুলো রোধ করতে সরঞ্জামগুলোর মধ্যে স্যান্ডবক্সিংয়ের প্রয়োজনীয়তা তৈরি করে। অপরিবর্তনীয় ল্যাবগুলো সরঞ্জাম বর্ণনার মাধ্যমে এটি সমাধান করেছে, অন্যরা এমসিপি (MCP) রিসোর্স অ্যাটাচমেন্ট ব্যবহার করেছে। স্যান্ডবক্সিংয়ের অভাব প্রম্পট ইনজেকশন ঝুঁকি বাড়িয়ে তোলে।

এটিকে এসকিউএল (SQL) ইনজেকশনের সাথে তুলনা করা হয় - একটি সিস্টেম একসাথে জোড়া দেওয়া হয়েছে, যেখানে ন্যূনতম পর্যবেক্ষণযোগ্যতার সাথে যেকোনো মুহুর্তে দুর্বলতা কাজে লাগানো যেতে পারে।

প্রম্পট ইন্টারফেসও এসকিউএল (SQL) ইনজেকশনের একটি রূপের জন্য সংবেদনশীল, কারণ মডেলটি প্রম্পটের বিশ্বস্ত অংশগুলোকে ব্যবহারকারী-দূষিত ইনপুট থেকে আলাদা করতে পারে না। এটি সমাধান করার জন্য এনকোডিং, ডিকোডিং এবং মডেল প্রশিক্ষণে মৌলিক পরিবর্তন প্রয়োজন।

এটি প্রম্পট ইনজেকশন এবং সরঞ্জাম ইনজেকশন উভয়ের জন্যই অনুমতি দেয়, সম্ভাব্যভাবে অবিশ্বস্ত কোড নির্বাহের দিকে পরিচালিত করে।

কন্টেইনারাইজেশন এবং নিয়ন্ত্রিত অ্যাক্সেস

একজন ডেভেলপার একটি এমসিপি (MCP) সার্ভার তৈরি করেছেন, যা প্রোজেক্ট কোড মাউন্ট করা একটি ডকার কন্টেইনার শুরু করে। এই পদ্ধতিটি এলএলএমকে (LLM) একটি স্যান্ডবক্সযুক্ত পরিবেশে পুরো ইউনিক্স টুলসেট এবং প্রোজেক্ট-নির্দিষ্ট সরঞ্জামগুলোতে অ্যাক্সেস করতে দেয়।

চ্যাট-ভিত্তিক ইন্টারফেসের মাধ্যমে চালিত এই এজেন্টিক কর্মপ্রবাহ ঐতিহ্যবাহী পদ্ধতির চেয়ে বেশি কার্যকর প্রমাণিত হয়েছে।

মূল বিষয় হলো এমসিপি (MCP) এজেন্টদের তাদের যা প্রয়োজন তা অ্যাক্সেস দেওয়া এবং এর বেশি কিছু নয়। সুরক্ষা ঝুঁকি কমাতে কন্টেইনারাইজেশন এবং স্বচ্ছ সরঞ্জাম ইউএক্স (UX) অত্যন্ত গুরুত্বপূর্ণ।

ভার্চুয়াল মেশিন এবং ইন্টারনেট অ্যাক্সেস

এজেন্টদের একটি ন্যূনতম লিনাক্স ইনস্টলেশন (ভিএম (VM) বা কন্টেইনার হিসাবে) সহ একটি কম্পিউটার দেওয়া আরও ভাল ফলাফল দিতে পারে, যা তাদের ইন্টারনেট থেকে তথ্য আনতে দেয়। তবে, এটি দূষিত নির্দেশাবলী এবং ডেটা বহির্গমন সম্পর্কিত সুরক্ষা উদ্বেগ তৈরি করে।

বিশ্বস্ত ওয়েবসাইটগুলোতে অ্যাক্সেস সীমাবদ্ধ করা কিছু ঝুঁকি কমাতে পারে, তবে এমনকি বিশ্বস্ত উৎসগুলোতেও দূষিত সামগ্রী থাকতে পারে। দূষিত নির্দেশাবলী সম্মুখীন হওয়ার সম্ভাবনা এবং উৎপাদনশীলতা সুবিধার মধ্যে আপসটি সাবধানে বিবেচনা করতে হবে।

কর্মচারী এবং এআই (AI) এজেন্টদের মধ্যে পার্থক্যগুলো উল্লেখযোগ্য। কর্মচারীরা আইন এবং চুক্তির অধীন আইনি ব্যক্তি, যা জবাবদিহিতা সরবরাহ করে। এআই (AI) এজেন্টদের এই আইনি কাঠামোর অভাব রয়েছে, যা বিশ্বাস করা আরও কঠিন করে তোলে।

এমসিপি (MCP) বিকাশের প্রাথমিক পর্যায়

এমসিপি (MCP) শুধুমাত্র ২০২৪ সালের নভেম্বরে ঘোষণা করা হয়েছিল এবং আরএফসি (RFC) সক্রিয়ভাবে বিকশিত হচ্ছে।

কেউ কেউ এমসিপি (MCP) সহ পুরো এআই (AI) ব্যক্তিগত সহকারী ধারণাটিকে মৌলিকভাবে ত্রুটিপূর্ণ হিসাবে দেখেন।

১৯৯০-এর দশকের শেষের দিকে এবং ২০০০-এর দশকের গোড়ার দিকে এআই (AI) সহকারীর জন্য প্রাথমিক ধাক্কা ব্যর্থ হয়েছিল কারণ উল্লম্ব ইন্টিগ্রেশন এবং বাল্ক কেনার ক্ষমতা সম্পন্ন সামগ্রী একত্রিতকারীরা আরও কার্যকর প্রমাণিত হয়েছিল। এর ফলে এক্সপেডিয়া এবং ইবেয়ের মতো প্ল্যাটফর্মগুলোর উত্থান ঘটেছিল।

মাল্টি-এজেন্ট সিস্টেমগুলোর জন্য প্রোগ্রামারদের এজেন্টদের অবস্থাকে প্রভাবিত করতে হয়, যা একটি চ্যালেঞ্জিং প্রোগ্রামিং কাজ।

বিনামূল্যে মূল্যের সীমা

‘পার্কিংয়ের উপলব্ধতা অনুসারে ফলাফল র‍্যাঙ্ক করুন’ করার আকাঙ্ক্ষা অর্থপ্রদত্ত API বা বিজ্ঞাপন-সমর্থিত ফ্রন্টএন্ডগুলোর পিছনে ডেটা অ্যাক্সেস করার সমস্যাটিকে তুলে ধরে। কোম্পানিগুলো সম্ভবত API-এর মাধ্যমে তাদের পুরো ডেটাসেটে বিনামূল্যে অ্যাক্সেস সরবরাহ করবে না।

যদিও সমস্ত কোম্পানি তাদের ডেটা এআই (AI) এজেন্টগুলোতে সংহত করবে না, তবে বিভিন্ন সরঞ্জামগুলোকে একত্রিত করে কর্মপ্রবাহকে শক্তিশালী করার সম্ভাবনা উল্লেখযোগ্য।

যে কোম্পানিগুলো ডেটা সুরক্ষিত রাখতে অগ্রাধিকার দেয়, তারা সম্ভবত সেই নতুন প্রযুক্তিগুলোর বিরোধিতা করবে, যা সেই নিরাপত্তাকে হুমকির মুখে ফেলে।

যদি বুকিং ডটকমের (booking.com) একটি API থাকত, তবে তারা সম্ভবত JSON বা XML ফরম্যাটিং সহ তাদের ওয়েবসাইটের মতোই ফলাফল ফেরত দিত।

মধ্যস্বত্বভোগীকে বাইপাস করা

বুকিং ডটকমের (booking.com) মতো মধ্যস্বত্বভোগীদের ব্যবহারকারীদের তাদের পরিষেবাগুলোকে সম্পূর্ণরূপে বাইপাস করার অনুমতি দেওয়া সামান্য অর্থবোধ করে।

তবে, পৃথক হোটেলগুলো বুকিং ডটকমকে (booking.com) বাইপাস করা উপকারী মনে করতে পারে, যা তারা প্রায়শই অপছন্দ করে।

একটি ডিপ রিসার্চ এআই (Deep Research AI) নির্দিষ্ট মানদণ্ডের ভিত্তিতে হোটেলগুলোর জন্য স্ক্যান করতে পারে এবং পৃথক হোটেল দ্বারা চালিত হোটেল ডিসকভারি এমসিপি (MCP) সার্ভারগুলোর সাথে যোগাযোগ করতে পারে, বুকিং ডটকমের (booking.com) ইন্টারফেস এবং বিজ্ঞাপনগুলোতে নেভিগেট করার প্রয়োজনীয়তা এড়িয়ে।

বাস্তব ব্যবহারিক ক্ষেত্র

এমসিপি (MCP) আরও কাঠামোগত উপায়ে ইলাস্টিকসার্চ থেকে লগ আনা বা ডেটাবেস কোয়েরি করার মতো কাজগুলো সহজতর করতে পারে।

এমসিপি (MCP) সার্ভার কনফিগারেশনের স্ট্যাটিক প্রকৃতি, যেখানে নতুন সার্ভারের জন্য একটি .json ফাইল সম্পাদনা করা এবং অ্যাপটি পুনরায় চালু করা প্রয়োজন, তা সীমিত হতে পারে।

ফাইন-টিউনড মডেল

এমসিপিকে (MCP) একটি ছোট, ফাইন-টিউনড মডেল হিসাবে দেখা যেতে পারে, যা অসংখ্য এমসিপি (MCP) সরঞ্জাম বোঝে এবং প্রতিটি কথোপকথনের জন্য সঠিকগুলো বেছে নেয়।

কিছু পরিস্থিতিতে প্রসঙ্গের উপর ভিত্তি করে সরঞ্জামগুলোকে গতিশীলভাবে সামঞ্জস্য করা প্রয়োজন হতে পারে।

মুক্ত কথোপকথন এবং ব্যবসার সমস্যা

এমসিপি (MCP) কোনো পূর্বনির্ধারিত প্রবাহ ছাড়াই সাধারণ, মুক্ত কথোপকথন সিস্টেমগুলোর জন্য উপযুক্ত। তবে, এটি প্রতিটি ব্যবসার সমস্যার জন্য একটি আকার-ফিট-সব সমাধান নয়। এটি ল্যাংচেইনের (LangChain) মতো ফ্রেমওয়ার্কগুলোকে প্রতিস্থাপন করার উদ্দেশ্যে নয়।

এমসিপির (MCP) বিকল্প, একটি উন্মুক্ত সম্প্রদায়-চালিত মান, হলো খণ্ডিত, মালিকানাধীন এবং বিক্রেতা-লকড প্রোটোকল। ত্রুটিপূর্ণ তবে বিকাশমান একটি মান কোনো মান না থাকার চেয়ে ভালো।

এমসিপিকে (MCP) দেখার সেরা উপায় হলো API-এর চারপাশে ক্লায়েন্ট র্যাপার তৈরি করা স্বতন্ত্র ডেভেলপার থেকে API সরবরাহকারী বা সম্প্রদায়-রক্ষণাবেক্ষণ করা র্যাপার তৈরি করার দিকে একটি পরিবর্তন হিসাবে দেখা। এটি এনপিএম (NPM) বা পাইপির (PyPi) অনুরূপ একটি বৃহৎ টুলবক্স সরবরাহ করে। তবে, অর্কেস্ট্রেশন, সুরক্ষা এবং ব্যবহারের সংজ্ঞা এখনও প্রয়োজন।

ল্যাংচেইনের (Langchain) পরবর্তী প্রজন্ম এই বৃহত্তর টুলচেস্ট থেকে উপকৃত হবে, তবে এখনও উদ্ভাবনের প্রয়োজন রয়েছে।

ব্যবহারকারী-নির্দিষ্ট সরঞ্জাম

কিছু ক্ষেত্রে, সরঞ্জামগুলো ব্যবহারকারীর ডেটার জন্য নির্দিষ্ট হতে পারে, যেমন আপলোড করা সিএসভি (CSV) ফাইলগুলো স্লাইস এবং ম্যানিপুলেট করার সরঞ্জাম।

একটি প্রায়শই উপেক্ষিত সমস্যা হলো এমসিপি (MCP) মডেলের প্রসঙ্গটিকে অতিরিক্ত বিকল্প দিয়ে ভিড় করতে পারে। অপচয়মূলক টোকেন ব্যবহার এবং অনিয়মিত মডেল আচরণ এড়াতে অগ্রাধিকার এবং মেটাডেটা প্রকাশ অত্যন্ত গুরুত্বপূর্ণ।

মান এবং বিকাশমান প্রযুক্তি

নতুন মান সময়ের সাথে সাথে আবির্ভূত হয় এবং যেহেতু মানগুলো সত্যিই গুরুত্বপূর্ণ ছিল তার পর থেকে অনেক সময় কেটে গেছে, তাই লোকেরা ভুলে গেছে যে তারা কীভাবে বিকাশ করে।

এলএলএম (LLM) ক্লায়েন্টগুলোতে ‘সরঞ্জাম’ যোগ করার জন্য এলোমেলো ডেভেলপারদের থেকে ছোট সার্ভার প্রোগ্রাম ডাউনলোড করা ঝুঁকিপূর্ণ হতে পারে।

উত্থাপিত সমস্যাগুলো বৈধ সমস্যা, যা এমসিপি (MCP) ইকোসিস্টেমকে মোকাবেলা করতে হবে। কিছু সমাধান এমসিপি (MCP) স্পেকের মধ্যে থাকবে, অন্যরা বাহ্যিক হবে।

ক্লড কোড এবং বাস্তব-বিশ্ব ব্যবহার

এমসিপির (MCP) সাফল্য সম্পর্কে বিপরীত মতামত রয়েছে। কেউ কেউ এমসিপির (MCP) সাথে সংহত কোম্পানিগুলোর গল্প শুনেছেন, আবার কেউ কেউ ব্যবহারকারীদের কাছ থেকে শুনেছেন যারা এটিকে হতাশাজনক মনে করেছেন।

এটি প্রচার এবং প্রাথমিক গ্রহণের দুর্বলতা তুলে ধরে।

কিছু ডেভেলপার মনে করেন যে বেশিরভাগ ব্যবহারের ক্ষেত্রে HTTP API এমসিপির (MCP) চেয়ে উন্নত। তারা যুক্তি দেন যে ‘সরঞ্জাম’ ব্যবহার ক্ষমতা এবং কার্যকারিতার জন্য API এন্ডপয়েন্টগুলোতে নেমে আসে।

API ডিফল্টরূপে স্ব-বর্ণনাকারী নয়, REST এবং HATEOAS সমর্থকদের তাদের পদ্ধতিগুলো প্রদর্শনের জন্য একটি সুযোগ হাতছাড়া করা হয়েছে।

ল্যাংচেইন (LangChain) বিকল্প হিসাবে এমসিপি (MCP)?

এমসিপিকে (MCP) একটি ‘ল্যাংচেইন (LangChain) গন্ধ’ হিসাবে বর্ণনা করা হয়েছে - একটি জরুরি সমস্যার সমাধান না করা, অতিরিক্ত বিমূর্ত হওয়া এবং এর সুবিধাগুলো ব্যাখ্যা করতে অসুবিধা হওয়া।

সম্ভবত এটিকে ‘এন্ড অফ লাইন’ বলতে হবে এবং ওয়ানাবি হ্যাকারদের গেম গ্রিডে নির্বাসন দিতে হবে!

একটি মূল প্রশ্ন হলো ‘সাধারণ’ চ্যাটবট দৃষ্টান্তটি টিকে থাকবে কিনা। নিজস্ব সরঞ্জাম সহ বিশেষ অ্যাপ্লিকেশনগুলোর এমসিপির (MCP) প্রয়োজন নাও হতে পারে।

বিপরীতে, এলএলএমগুলো (LLM) আরও সক্ষম হওয়ার সাথে সাথে বাহ্যিক সরঞ্জামগুলোর প্রয়োজন কম হতে পারে। এলএলএম (LLM) যখন সরাসরি ছবি সম্পাদনা করতে পারে, তখন আপনি কেন ফটোশপ চালানোর জন্য একটি এমসিপি (MCP) চান?

বৈজ্ঞানিক কল্পকাহিনী রোবট সহকারী স্বপ্ন বাস্তবায়িত নাও হতে পারে এবং বিশেষ ভাষা ম্যানিপুলেশন সরঞ্জামগুলো আরও বেশি দরকারী হতে পারে।

ব্যবহারকারী বেস এবং সুরক্ষা সচেতনতা

এমসিপির (MCP) ব্যবহারকারী বেসে কম প্রযুক্তি-সচেতন ব্যক্তি রয়েছেন, যা সুরক্ষা সমস্যাগুলোকে বিশেষভাবে প্রাসঙ্গিক করে তোলে। সুরক্ষা সেরা অনুশীলন সম্পর্কে সচেতনতা বাড়ানো অত্যন্ত গুরুত্বপূর্ণ।

ওপেনআরপিসির (OpenRPC) উপর ভিত্তি করে এক্সঅপস (Xops), যার জন্য ফলাফলের স্কিমা সংজ্ঞায়িত করা প্রয়োজন, আউটপুট কীভাবে ইনপুটগুলোর সাথে সংযুক্ত হয় তা পরিকল্পনা করতে সহায়তা করে, জটিল কর্মপ্রবাহের জন্য নির্ভরযোগ্যতা উন্নত করে।

সময়ের সাথে সাথে প্রযুক্তি বিকশিত এবং স্থিতিশীল হওয়ার সম্ভাবনা রয়েছে।

রিডান্ডেন্সি এবং ক্লাউড অবকাঠামো

কেউ কেউ ওপেনএপিআই (OpenAPI) মানের উপর এমসিপি (MCP) ব্যবহারের লাভ নিয়ে প্রশ্ন তোলেন, এটিকে অতিরিক্ত হিসাবে দেখেন।

একটি ওপেনএপিআই (OpenAPI) সিস্টেমে কল করার জন্য এলএলএম (LLM) কী ব্যবহার করবে? এটি শেলের সাথে কীভাবে আবদ্ধ হবে? এলএলএমের (LLM) হোস্ট সেটি কীভাবে পরিচালনা করবে?

এলএলএমগুলোকে (LLM) সরঞ্জাম কল করার জন্য এমসিপি (MCP) একটি কাঠামোগত উপায় সরবরাহ করে।

এমসিপি (MCP) সার্ভারগুলো ইতিমধ্যে HTTP সার্ভার।

এমসিপির (MCP) সবচেয়ে বড় সুবিধাটি অ্যাপ্লিকেশন ডেভেলপারদের জন্য নয়, ওপেনএআইয়ের (OpenAI) মতো এলএলএম (LLM) সরবরাহকারীদের জন্য।

এলএলএমগুলো (LLM) সরঞ্জামবিহীন মস্তিষ্ক এবং সরঞ্জাম কলিং তাদের ক্ষমতা দেয়। তবে, সাধারণ API-এর সাথে, এলএলএম (LLM) সরবরাহকারীদের সেই সরঞ্জামগুলোতে অ্যাক্সেস নেই। এমসিপি (MCP) তাদের অ্যাক্সেস দেয়, তাদের এআইয়ের (AI) প্রবেশদ্বার হিসাবে স্থাপন করে।

সিএলআই (CLI) বনাম এপিআই (API)

এলএলএমগুলোকে (LLM) যেহেতু স্বাভাবিক ভাষায় প্রশিক্ষণ দেওয়া হয়েছে এবং সিএলআই (CLI) একটি সাধারণ মানুষের পাঠযোগ্য এবং লেখার যোগ্য সমাধান, তাই সিএলআই (CLI) সরাসরি ব্যবহার করবেন না কেন?

এমসিপি (MCP) খুব দ্রুত আবির্ভূত হয়েছে এবং পরিপক্ক হওয়ার জন্য সময়ের প্রয়োজন। এটির একটি প্রচলিত মান সংস্থা দ্বারা যাচাইয়ের অভাব রয়েছে এবং প্রচার দ্বারা চালিত হয়।

বাস্তব-বিশ্বের অ্যাপ্লিকেশনগুলোর অভাব রয়েছে।

এমসিপির (MCP) মূল অ্যাপ্লিকেশন

এমসিপি (MCP) ক্লড ডেস্কটপ এবং বিশেষ এআই (AI) চ্যাট অ্যাপ্লিকেশন, কোড অটোমেশন সরঞ্জাম এবং এজেন্ট/এলএলএম (LLM) অটোমেশন ফ্রেমওয়ার্কে ব্যবহৃত হয়।

এটি আরেকটি তাড়াহুড়ো করা প্রযুক্তি, যা সম্ভবত পরবর্তী প্রচারযোগ্য সংক্ষিপ্ত শব্দ আসার সাথে সাথে বাতিল করা হবে।

ভাষা মডেল সরঞ্জাম কলিং প্রোটোকল দুই ধরনের: যেগুলোর সম্পর্কে লোকেরা অভিযোগ করে এবং যেগুলো কেউ ব্যবহার করে না।

অ্যানথ্রোপিক এই ‘মান’ একটি শূন্যস্থানে তৈরি করেছে, যার ফলে সুরক্ষা সমস্যা দেখা দিয়েছে।

জেসন-আরপিসি ২.০ (JSON-RPC 2.0)

এমসিপি (MCP) জেসন-আরপিসি ২.০ (JSON-RPC 2.0)-এর উপর ভিত্তি করে তৈরি করা হয়েছে, একটি হালকা ওজনের প্রোটোকল, যা JSON ব্যবহার করে ক্লায়েন্ট এবং সার্ভারের মধ্যে যোগাযোগ করতে দেয়।

এটি একটি নির্দিষ্ট ইকোসিস্টেমের জন্য ডিজাইন করা একটি কেন্দ্রীভূত স্পেকের মতো মনে হয়, যা এটি অর্জন না করেই সার্বজনীনতার দাবি করে।

এমসিপি (MCP) দরকারী জিনিস করার জন্য যথেষ্ট শক্তিশালী, যা সুরক্ষা উদ্বেগ বাড়ায়।

এটি একটি পরিপক্ক মান নয় এবং সুরক্ষিত থাকার জন্য ডিজাইন করা হয়নি।

সুপারিশ বিদ্যমান থাকলেও সেগুলো কার্যকর বা প্রয়োগ করা হয় না।

ল্যাংচেইন (Langchain) এবং সরঞ্জাম কলিং

ল্যাংচেইন (Langchain) এমন অনেক ফ্রেমওয়ার্কের মধ্যে একটি, যা ‘সরঞ্জাম কলিং’ প্যাটার্ন প্রয়োগ করে।

এমসিপি (MCP) হলো একটি স্পেক, যা সরঞ্জাম কলিং, টেমপ্লেটেড ইনপুট, বাতিলকরণ, অগ্রগতি ট্র্যাকিং এবং সরঞ্জাম সার্ভারের স্টেটফুলনেস সহ বাহ্যিক তথ্য কীভাবে একটি ভাষা মডেলের প্রসঙ্গ উইন্ডোতে প্রবেশ করে তা অন্তর্ভুক্ত করে।

এটি বিবরণগুলো মানক করতে সহায়তা করে যাতে যেকোনো সহকারী/ইন্টিগ্রেশন কম্বো সামঞ্জস্যপূর্ণ হয়।

এমসিপির (MCP) বৈধ সমস্যা থাকলেও সমালোচকদের তাদের যুক্তিসমূহ পরিমার্জন করা উচিত।

প্রমাণীকরণ অত্যন্ত গুরুত্বপূর্ণ এবং প্রাথমিক সংস্করণ থেকে বাদ দেওয়া উচিত হয়নি।

অত্যধিক জটিলতা রয়েছে।