MHS ও MCP এক নয়—এজেন্ট কোন পথে যন্ত্র ও ডেটা পায়

Model Hardware Standard (MHS) ও Model Context Protocol (MCP) পরস্পরের বিকল্প নয়। MCP এআই অ্যাপ্লিকেশনের সঙ্গে ডেটা উৎস ও সফটওয়্যার টুলের সংযোগ মানসম্মত করে; MHS প্রোগ্রামযোগ্য ভৌত যন্ত্রের জন্য ড্রাইভার, যন্ত্রটির কার্যগত অর্থ এবং বলবৎ নিরাপত্তা-সীমা প্রকাশ করে।

তাই একই agent architecture-এ দুটির স্থান আলাদা হলেও তারা একসঙ্গে কাজ করতে পারে। ডেটাবেস, নথি বা সফটওয়্যার API যুক্ত করতে MCP ব্যবহার করা যায়; microscope, liquid handler বা robotic arm চালাতে MHS-এর device layer প্রয়োজন হতে পারে, আর সেই MHS driver-কে এজেন্টের সামনে আনার একটি ঐচ্ছিক control path হতে পারে MCP। MHS এখনো সীমিত research preview—পরিপক্ব, সর্বজনীন production standard নয়।

দায়িত্বের সীমানাতেই মূল পার্থক্য

MCP-এর কাজ হলো host application, client ও server-এর মধ্যে context এবং capability আদান-প্রদানের সাধারণ পথ তৈরি করা। Anthropic-এর MCP পরিচিতি একে data source ও AI-powered tool-এর মধ্যে নিরাপদ, দ্বিমুখী সংযোগ তৈরির open standard হিসেবে সংজ্ঞায়িত করে। একটি MCP server resource, prompt বা executable tool প্রকাশ করতে পারে; host-এর ভেতরের client সেই server-এর সঙ্গে সংযোগ ধরে রাখে।

MHS-এর প্রশ্ন আরও ভৌত ও যন্ত্রনির্দিষ্ট: কোনো device কী করতে পারে, তার কোন command কী অর্থ বহন করে এবং operation কোন সীমার মধ্যে থাকতে হবে? MHS research preview-এর বিবরণ অনুযায়ী, এর standardized driver read ও write ধরনের primitive, device discovery এবং natural-language tag থেকে তৈরি reference information ব্যবহার করে। ওই reference-এ যন্ত্র কী পরিমাপ করতে পারে, কোন parameter বদলানো যায় এবং কোন safety limit বলবৎ হবে—এসব রাখা যায়; MCP, CLI ও code file হলো hardware control-এর তিনটি পথ।

ফলে MCP কোনো MHS operation-কে tool হিসেবে এজেন্টের কাছে পৌঁছে দিতে পারে, কিন্তু নিজে robotic arm-এর ওজন, microscope stage-এর চলাচলসীমা বা liquid handler-এর বৈধ parameter নির্ধারণ করে না। উল্টো দিকে, MHS কোনো CRM, document store বা সাধারণ business API সংযোগের সার্বজনীন data protocol নয়।

দুটি flow পাশাপাশি রাখলে স্তরগুলো স্পষ্ট হয়

ভৌত যন্ত্রের পথটি সংক্ষেপে এমন: programmable device → vendor interface → MHS driver → MCP/CLI/code → agent harness। Device ও তার vendor interface বাস্তব operation সম্পাদন করে। MHS driver ভিন্ন ভিন্ন interface-কে মানসম্মত command ও reference information-এর আবরণে আনে, যাতে agent যন্ত্রটির ক্ষমতা ও সীমা বুঝতে পারে।

এরপর control mechanism নির্বাচন করা হয়। কথোপকথনভিত্তিক orchestration-এ driver operation MCP tool হিসেবে প্রকাশ করা যেতে পারে। দীর্ঘ বা দ্রুত deterministic sequence-এর ক্ষেত্রে driver command code file-এ সাজানো যায়, যাতে প্রতিটি ধাপে model-এর online reasoning-এর অপেক্ষা না করতে হয়। CLI মানুষ বা automation script-এর জন্য আরেকটি সরাসরি পথ।

ডেটা ও সফটওয়্যার টুলের পথ আলাদা: data source বা tool → MCP server → MCP client → host/agent → model। Server capability প্রকাশ করে, client একটি নির্দিষ্ট server-এর session পরিচালনা করে এবং host ঠিক করে কোন context বা action model-এর কাছে যাবে। এখানে device driver বা physical interlock থাকা MCP-এর আবশ্যিক অংশ নয়।

MCP connection কী দেয়—এবং কী দেয় না

MCP specification-এর 2025-06-18 revision base protocol, lifecycle management, HTTP transport-এর authorization framework এবং server ও client feature-কে পৃথক component হিসেবে নির্ধারণ করেছে। Base protocol ও lifecycle সব implementation-এর জন্য বাধ্যতামূলক; অন্য component প্রয়োজন অনুযায়ী যোগ করা যায়। Client-server message-কে JSON-RPC 2.0 অনুসরণ করতে হয়।

অতএব connection তৈরি হওয়া মানেই model সব server-এর সব তথ্য দেখতে পাবে না। Capability negotiation জানায় কোন feature পাওয়া যাচ্ছে, আর host connection permission, context aggregation ও user authorization পরিচালনা করতে পারে। একইভাবে একটি MCP tool call প্রযুক্তিগতভাবে সফল হওয়া প্রমাণ করে না যে তার ফলস্বরূপ physical motion নিরাপদ।

এই সীমাটি hardware architecture-এ গুরুত্বপূর্ণ। MCP application ও connection boundary-তে access নিয়ন্ত্রণ করতে পারে; MHS driver device semantics ও ঘোষিত safety limit-এর স্তরে কাজ করে। কোনো উচ্চ-ঝুঁকির ব্যবস্থায় driver-level limit-এর পাশাপাশি নির্মাতার interlock, মানব অনুমোদন, emergency stop এবং প্রতিষ্ঠানের operational procedure আলাদা সুরক্ষা হিসেবেই রাখতে হবে। Natural-language metadata একা পূর্ণ safety case নয়।

Overlap আছে tool invocation-এ, dependency বাধ্যতামূলক নয়

দুই standard-এর overlap ঘটে যখন MHS driver-এর operation MCP server-এর tool হিসেবে প্রকাশ করা হয়। তখন “temperature পড়ো” বা “arm নির্দিষ্ট অবস্থানে নাও” ধরনের request MCP session দিয়ে যাতায়াত করতে পারে। MCP request, response ও capability বহন করে; MHS নির্ধারণ করে command-টি বাস্তব যন্ত্রে কী বোঝায় এবং driver কোন সীমা প্রয়োগ করবে।

তবে dependency একমুখী বা বাধ্যতামূলক নয়। MHS MCP ছাড়াও CLI বা code file দিয়ে নিয়ন্ত্রণ দিতে পারে। MCP-ও MHS ছাড়াই database, repository, SaaS API বা software-only function-এর সঙ্গে কাজ করতে পারে। তাই স্থাপত্যগত প্রশ্নটি “একটি না অন্যটি” নয়; বরং physical-device semantics দরকার কি না এবং agent-facing control channel হিসেবে MCP উপযোগী কি না।

আরেকটি পার্থক্য হলো ব্যর্থতার ধরন। MCP স্তরে ব্যর্থতা হতে পারে connection, authorization, schema বা tool execution ঘিরে। Hardware স্তরে একই request অবৈধ range, collision risk, sensor state বা যন্ত্রের বাস্তব অবস্থার কারণে থামতে পারে। এই দুই failure domain আলাদা রাখলে permission error-কে device fault কিংবা successful API response-কে safe physical completion ভেবে নেওয়ার ঝুঁকি কমে।

কোন স্থাপত্যে কোন স্তর লাগবে

• শুধু data বা software tool: MCP server ও client যথেষ্ট হতে পারে। ভৌত device semantics না থাকলে MHS driver যোগ করার কারণ নেই।
• একটি programmable physical device: মানসম্মত operation, discoverability এবং safety metadata-এর জন্য MHS বিবেচ্য। Agent integration দরকার হলে MHS-এর ওপর MCP control path বসতে পারে।
• একাধিক যন্ত্রের orchestration: প্রতিটি device-কে MHS driver দিয়ে প্রকাশ করে agent-facing operation MCP-তে দেওয়া যায়। দ্রুত বা দীর্ঘ deterministic sequence code file-এ রাখা যেতে পারে।
• Programmable interface-হীন hardware: ঘোষিত preview অনুযায়ী বর্তমান MHS এমন যন্ত্রে সরাসরি কাজ করে না। আগে নির্মাতা-সমর্থিত interface বা উপযুক্ত integration layer দরকার।
• উচ্চ-ঝুঁকির physical workflow: MCP authorization, MHS driver limit এবং স্বাধীন physical safeguard-কে পৃথক control হিসেবে নকশা করতে হবে; কোনো একটিকে অন্যটির বিকল্প ধরা যাবে না।

একটি শর্তসাপেক্ষ laboratory architecture-এ agent host experiment database-এর জন্য একটি MCP server এবং MHS driver-এ প্রকাশিত যন্ত্রগুলোর জন্য আরেকটি server ব্যবহার করতে পারে। Model প্রথমটি থেকে protocol ও measurement context পায়, দ্বিতীয়টির tool দিয়ে operation চায়, আর driver device-specific parameter ও safety limit প্রয়োগ করে। সারকথা, MCP capability এজেন্টের কাছে পৌঁছে দেয়; MHS ভৌত capability-টির অর্থ ও সীমা নির্ধারণ করে।