MCP আর্কিটেকচার: ডায়াগ্রামসহ পূর্ণাঙ্গ কারিগরি বিশ্লেষণ

MCP আর্কিটেকচার হলো মৌলিক কম্পোনেন্ট ও যোগাযোগের নিয়মের সেই সমষ্টি, যা MCP (Model Context Protocol)-কে সম্ভব করে তোলে। MCP একটি ওপেন-সোর্স স্ট্যান্ডার্ড, আর MCP আর্কিটেকচার হলো সেই অন্তর্নিহিত অবকাঠামো, যার ওপর এটি চলে।

যেকোনো MCP আর্কিটেকচারে তিনটি মূল কম্পোনেন্ট থাকে এবং সেগুলোকে ঘিরেই এটি তৈরি হয়: একটি হোস্ট, একটি ক্লায়েন্ট এবং একটি সার্ভার। MCP-এর যোগাযোগ কাঠামোকে প্রায়ই একটি ডেটা লেয়ার ও একটি ট্রান্সপোর্ট লেয়ার নিয়ে গঠিত বলে বর্ণনা করা হয়। ডেটা লেয়ার হলো মেসেজ কীভাবে ফরম্যাট করা হবে তার নিয়মের সমষ্টি (MCP রিকোয়েস্ট JSON-RPC 2.0-এ পাঠানো হয়)। ট্রান্সপোর্ট লেয়ার সেই মেসেজগুলো বহন করে এবং বাহ্যিক সংযোগের জন্য Streaming HTTP ব্যবহার করে।

MCP আর্কিটেকচার হলো একটি সার্ভার ফ্রেমওয়ার্ক, যা Model Context Protocol বাস্তবায়ন করে। Model Context Protocol হলো AI মডেলকে টুলের সঙ্গে যুক্ত করার একটি ওপেন স্ট্যান্ডার্ড, যা ডেটাবেসের মতো রিসোর্স এবং ইনপুট কনটেক্সট বাড়ায় এমন প্রম্পটের সঙ্গেও সংযোগ ঘটায়। এগুলোকে একত্রে “প্রিমিটিভ” বলা হয়। শেষ পর্যন্ত, MCP আর্কিটেকচার LLM-কে কোন টুল উপলব্ধ তা খুঁজে বের করতে এবং ওয়ার্কফ্লো চালাতে দেয়, আর এর জন্য ক্লায়েন্টের দিকে নিয়মিত আপডেটের প্রয়োজন হয় না।

MCP আর্কিটেকচারের ডায়াগ্রাম: একটি AI অ্যাপ্লিকেশন একটি MCP সার্ভারের সঙ্গে রিকোয়েস্ট আদান-প্রদান করে, আর সার্ভারটি টুল, রিসোর্স ও প্রম্পট সরবরাহ করে।

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

হোস্ট অ্যাপ্লিকেশনের লোকাল সিস্টেমে বা কোনো বাহ্যিক প্রোভাইডারের কাছ থেকে উপলব্ধ টুল, প্রম্পট ও রিসোর্স খুঁজে বের করা ও কল করার একটি উপায় MCP LLM-কে দেয়।

টুলের ক্ষেত্রে, যেগুলো বাহ্যিক ফাংশনালিটিতে অ্যাক্সেস দেয়, ডিসকভারি প্রক্রিয়ায় হোস্ট কোন টুল উপলব্ধ তা জানতে MCP সার্ভারে একটি tools/list কল করে। এরপর LLM (বা কিছু ক্ষেত্রে হোস্ট) উপলব্ধ টুলগুলোর বর্ণনা পড়ে প্রয়োজন অনুযায়ী সেগুলোর রিকোয়েস্ট করতে পারে। প্রম্পট ও রিসোর্সের ক্ষেত্রেও একই ধরনের প্রক্রিয়া ব্যবহৃত হয়।

MCP আর্কিটেকচারের কম্পোনেন্টগুলোর ডায়াগ্রাম: একটি LLM, একটি অর্কেস্ট্রেটর ও একটি ক্লায়েন্টসহ একটি হোস্ট দুটি ধাপে—প্রথমে ডিসকভারি, তারপর রিকোয়েস্ট—একটি MCP সার্ভারের সঙ্গে সংযুক্ত হয়, আর MCP সার্ভারটি টুল, রিসোর্স ও প্রম্পট উন্মুক্ত করে।

এটি সফটওয়্যার ডেভেলপমেন্টে এতদিনের প্রচলিত কাস্টম API-ভিত্তিক আর্কিটেকচার থেকে আলাদা, যেখানে অ্যাপের বাইরের ফাংশনালিটি কল করতে নির্দিষ্ট সংযোগ ও নিখুঁতভাবে ফরম্যাট করা রিকোয়েস্ট ব্যবহার করতে হতো।

হোস্ট অ্যাপ্লিকেশন হলো কেন্দ্রীয় অর্কেস্ট্রেশন প্ল্যাটফর্ম, যা একটি LLM-এর সঙ্গে সংযুক্ত থাকে। Perplexity ও Claude Desktop-এর মতো সুপরিচিত টুল একটি MCP সিস্টেমে হোস্ট হিসেবে কাজ করতে পারে।

একটি সাধারণ ওয়ার্কফ্লোতে ব্যবহারকারী চ্যাট ইন্টারফেসের মাধ্যমে একটি প্রশ্ন করেন। এরপর হোস্টের অর্কেস্ট্রেটর কম্পোনেন্ট প্রশ্নটির সঙ্গে কনটেক্সট যোগ করে এবং কোন কোন MCP প্রিমিটিভ উপলব্ধ, তা সেগুলোর সক্ষমতার বর্ণনাসহ LLM-কে জানায়।

ক্লায়েন্ট হলো AI অ্যাপ্লিকেশনের একটি সফটওয়্যার কম্পোনেন্ট। হোস্ট বা LLM-এর নির্দেশনা অনুযায়ী অভ্যন্তরীণ ও বাহ্যিক MCP সার্ভারের সঙ্গে ক্লায়েন্টের যোগাযোগের জন্য MCP একটি স্ট্যান্ডার্ড ইন্টারফেস দেয়। এর কাজ হলো সংযোগ স্থাপন করা, JSON-RPC মেসেজ ফরম্যাট করা, রিকোয়েস্ট পাঠানো এবং রেসপন্স গ্রহণ করা।

“MCP হোস্ট” ও “MCP ক্লায়েন্ট” শব্দ দুটি কখনো কখনো একটির জায়গায় আরেকটি ব্যবহার করা হয়। তবে এই পার্থক্যটি কাজের, কারণ Perplexity-এর মতো একটি হোস্ট একই সময়ে একাধিক MCP ক্লায়েন্ট অর্কেস্ট্রেট করতে পারে। একটি জটিল AI ওয়ার্কফ্লোতে কয়েক ডজন, এমনকি কয়েকশো আলাদা MCP সার্ভারে অ্যাক্সেসের প্রয়োজন হতে পারে, এবং প্রতিটির জন্য আলাদা সংযোগ ব্যবহৃত হবে।

Perplexity-এর মতো একটি MCP হোস্টের ডায়াগ্রাম, যা তিনটি MCP ক্লায়েন্ট অর্কেস্ট্রেট করছে; প্রতিটি ক্লায়েন্ট নিজস্ব একটি MCP সার্ভারের সঙ্গে সংযুক্ত, যেমন একটি ডেটাবেস, ফাইল বা একটি বাহ্যিক API।

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

MCP সার্ভার তিন ধরনের প্রিমিটিভে অ্যাক্সেস দিতে পারে:

টুল: এগুলো মূলত বাহ্যিক সফটওয়্যার ফাংশনালিটি। প্রচলিত API-ভিত্তিক পদ্ধতির কথা ভাবলে, একটি ওয়েব অ্যানালিটিক্স অ্যাপ্লিকেশন কোনো বাহ্যিক সার্ভারে ফরম্যাট করা রিকোয়েস্ট পাঠিয়ে ডেটা সংগ্রহ করতে পারে। MCP আর্কিটেকচারে কোনো প্রোভাইডারের সব থার্ড-পার্টি ফাংশনালিটি একটি মাত্র সংযোগের মাধ্যমে উপলব্ধ থাকে, এবং রিকোয়েস্ট তৈরি হয় স্ট্যান্ডার্ড ফরম্যাটিং নিয়ম মেনে।
রিসোর্স: রিসোর্স হলো এমন ডেটা সোর্স, যা শুধু পড়ার উপযোগী (read-only) কনটেক্সট দেয়। ডেটাবেস স্কিমা এর একটি ভালো উদাহরণ। MCP সার্ভার হোস্টের জন্য উপলব্ধ বিভিন্ন তথ্যসূত্র উন্মুক্ত করে। হোস্ট যদি ডেটাবেসে কোয়েরি করে, যেমন LLM-এর তৈরি SQL সার্চের মাধ্যমে, তবে সেটিকে একটি টুল রিকোয়েস্ট হিসেবে গণ্য করা হয়।
প্রম্পট: এগুলো পুনরায় ব্যবহারযোগ্য প্রম্পট টেমপ্লেট, যা LLM-কে নির্দিষ্ট কাজ সম্পাদনে সহায়তা করে। একজন ব্যবহারকারী বা হোস্ট টুলের বদলে প্রম্পট কল করে, কারণ কোনো কাজ সম্পন্ন করতে আগে থেকে তৈরি নির্দেশনার প্রয়োজন হয়। প্রায়ই হোস্ট অ্যাপ্লিকেশনের পূর্বনির্ধারিত কাজগুলো, যেমন “কোড রিভিউ” বা “ডেটা বিশ্লেষণ” অপশন, প্রম্পট হিসেবে সংরক্ষিত থাকে, যা ব্যবহারকারী বেছে নিতে পারেন।

এটিও উল্লেখ করার মতো যে MCP ও API পরস্পর-বর্জনশীল প্রযুক্তি নয়। MCP সার্ভার এমন API কল উন্মুক্ত করতে পারে, যা কোনো ডিসকভারি রিকোয়েস্টের জবাবে উপলব্ধ হয়। মূল বিষয় হলো, এগুলো রক্ষণাবেক্ষণের দায়িত্ব MCP প্রোভাইডারের, ক্লায়েন্টের নয়।

MCP আর্কিটেকচারে ডেটা লেয়ার হলো সেই নিয়মের সমষ্টি, যা রিকোয়েস্ট, রেসপন্স ও নোটিফিকেশন কীভাবে ফরম্যাট করা হবে তা নির্ধারণ করে। মেসেজের স্ট্যান্ডার্ড ভাষা হলো JSON-RPC।

সব MCP আর্কিটেকচার একটি মৌলিক প্রক্রিয়া অনুসরণ করে: (১) হোস্টের মাধ্যমে ইনিশিয়ালাইজেশন ও ডিসকভারি, (২) MCP সার্ভারের রেসপন্স, এবং (৩) হোস্টের একটি কল (কখনো কখনো LLM এটি নির্ধারণ করে); প্রতিটি ধাপ একটি আলাদা JSON মেসেজ নির্দেশ করে।

MCP ডেটা লেয়ারের ডায়াগ্রাম: একজন ব্যবহারকারী হোস্ট অ্যাপ্লিকেশনে একটি প্রম্পট পাঠান, যেখানে LLM MCP ক্লায়েন্টের সঙ্গে কাজ করে; ক্লায়েন্ট MCP সার্ভারে (টুল, রিসোর্স, প্রম্পট) একটি রিকোয়েস্ট পাঠায় এবং একটি ফলাফল পায়, আর হোস্ট ব্যবহারকারীকে একটি রেসপন্স ফেরত দেয়।

চলুন দুটি উদাহরণের মাধ্যমে দেখি টুল ডিসকভারি কীভাবে কাজ করে (এগুলো রিসোর্স বা প্রম্পটের ক্ষেত্রেও প্রযোজ্য হতে পারে):

LLM জেনারেশনের আগে টুল খুঁজে বের করা: হোস্ট MCP ক্লায়েন্ট চালু করে, যা একটি tools/list রিকোয়েস্ট (MCP সার্ভারের উপলব্ধ টুলের তালিকা) পাঠায়। জেনারেশন প্রক্রিয়ার সময় LLM এটি পর্যালোচনা করে এবং নির্ধারণ করে কোনো নির্দিষ্ট টুল, রিসোর্স বা প্রম্পট প্রয়োজন কি না।
LLM-কে সার্চ চালানোর অপশন দেওয়া: একটি এজেন্টিক সিস্টেমে হোস্ট কনটেক্সট ইনপুটে search-tools-এর মতো একটি ডিসকভারি অপশন যোগ করে, এবং প্রয়োজনে LLM একটি সার্চের রিকোয়েস্ট করতে পারে।

টুল, যেগুলো মোটামুটিভাবে বাহ্যিক অ্যাপ্লিকেশনের ফাংশনালিটি, সাধারণত LLM বা হোস্ট বেছে নেয়। রিসোর্স ও প্রম্পট সাধারণত ব্যবহারকারীর অনুরোধে বা হোস্টের মাধ্যমে রিকোয়েস্ট করা হয়।

একটি কাল্পনিক নোটস অ্যাপ্লিকেশন থেকে MCP সার্ভারে পাঠানো একটি tools/list রিকোয়েস্ট দেখতে এমন:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

এই উদাহরণে “id”:101 একটি ID দিয়ে রিকোয়েস্টটিকে শনাক্ত করে, যাতে ক্লায়েন্ট রেসপন্সগুলো মেলাতে পারে, আর “params” ফিল্ডে ক্লায়েন্ট সম্পর্কে অতিরিক্ত তথ্য থাকে, যেমন ক্লায়েন্টের নাম (notes-app-client) ও সক্ষমতা।

জবাবে MCP সার্ভার টুল ডেফিনিশন ফেরত দেবে, যাতে উপলব্ধ টুলগুলোর নাম ও সংশ্লিষ্ট বিবরণ থাকে। উদাহরণস্বরূপ, তালিকায় একটি add-task টুল থাকতে পারে, যা নোটস অ্যাপ্লিকেশনকে সংযুক্ত কোনো টাস্ক ম্যানেজমেন্ট বা ক্যালেন্ডার অ্যাপ্লিকেশনে টাস্ক তৈরি করতে এবং প্রতিটি টাস্কের জন্য একটি শিরোনাম ও অগ্রাধিকার নির্ধারণ করতে দেয়।

একটি রিকোয়েস্ট দেখতে এমন হতে পারে:

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

“method” ফিল্ড MCP সার্ভারকে জানায় যে এটি একটি টুল কল, “name” নির্দিষ্ট করে কোন টুল কল করতে হবে, আর “arguments” প্রয়োজনীয় ইনপুট সরবরাহ করে।

ক্লায়েন্ট ও MCP সার্ভারের মধ্যকার সংযোগে ডেটা লেয়ার যদি হয় কী, তবে ট্রান্সপোর্ট লেয়ার হলো কীভাবে। এটি নির্ধারণ করে মেসেজ কোন পথে চলবে: নির্দিষ্ট চ্যানেল এবং রিকোয়েস্ট ও রেসপন্স কীভাবে পৌঁছে দেওয়া হবে তা নিয়ন্ত্রণকারী নিয়মাবলি।

MCP-এর দুটি ট্রান্সপোর্ট পাথ রয়েছে:

স্ট্যান্ডার্ড ইনপুট/আউটপুট: MCP সার্ভার যখন হোস্ট অ্যাপের একই লোকাল এনভায়রনমেন্টে চলে, তখন এটি ব্যবহৃত হয়। ক্লায়েন্ট JSON রিকোয়েস্টটি সার্ভারের স্ট্যান্ডার্ড ইনপুটে লেখে। সার্ভার সেটি পড়ে, অনুরোধ করা অপারেশনটি সম্পাদন করে এবং রেসপন্সটি স্ট্যান্ডার্ড আউটপুটে লেখে।
Streamable HTTP: MCP সার্ভার যখন হোস্ট অ্যাপ্লিকেশনের বাইরে চলে, তখন MCP ক্লায়েন্ট HTTP POST ব্যবহার করে সার্ভারে রিকোয়েস্ট পাঠায়। সার্ভার হয় একটি একক JSON মেসেজ দিয়ে, নয়তো একটি Server-Sent Events (SSE) স্ট্রিম দিয়ে রেসপন্স করে—এটি একটি স্থায়ী “লিসেনিং” চ্যানেল, যার মাধ্যমে সার্ভার সময়ের সঙ্গে একাধিক মেসেজ ফেরত পাঠাতে পারে।

MCP মাল্টি-টেন্যান্ট আর্কিটেকচার হলো এক ধরনের ইমপ্লিমেন্টেশন, যা একসঙ্গে একাধিক ব্যবহারকারীকে (টেন্যান্ট) সেবা দিতে পারে।

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

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

বাস্তবে একটি এন্ড-টু-এন্ড MCP রিকোয়েস্ট দেখতে কেমন? এর আটটি মূল ধাপ রয়েছে, এবং প্রতিটি ধাপে আর্কিটেকচারের একটি আলাদা কম্পোনেন্ট যুক্ত থাকে।

আটটি ধাপে একটি এন্ড-টু-এন্ড MCP রিকোয়েস্টের ফ্লোচার্ট: টুল ডিসকভারি, ব্যবহারকারীর ইনপুট, মডেল প্রসেসিং, টুল নির্বাচন, রিকোয়েস্ট, টুল এক্সিকিউশন, ফলাফল এবং উত্তর তৈরি।

টাস্ক ম্যানেজমেন্ট সার্ভিসের সঙ্গে সংযুক্ত নোটস অ্যাপ্লিকেশনের আগের উদাহরণটি ব্যবহার করে দেখা যাক, বাস্তবে একটি MCP টুল কল দেখতে কেমন:

টুল ডিসকভারি: নোটস অ্যাপ্লিকেশন (হোস্ট) তার MCP ক্লায়েন্ট ব্যবহার করে একটি tools/list রিকোয়েস্টের মাধ্যমে সার্ভারের উপলব্ধ টুলগুলো চায়। সার্ভার সেগুলোর নাম, বর্ণনা ও প্রত্যাশিত ইনপুট ফেরত দেয়, যার মধ্যে add-task টুলের তথ্যও থাকে। আপনি প্রম্পট জমা দেওয়ার আগেই এটি ঘটতে পারে।
ব্যবহারকারীর ইনপুট: আপনি অ্যাপের ভেতরের চ্যাটবটের মাধ্যমে LLM-ভিত্তিক নোটস অ্যাপ্লিকেশনে একটি রিকোয়েস্ট জমা দেন, যেমন, “আমার নতুন খসড়াটি রিভিউ করার জন্য আমার ক্যালেন্ডারে মাঝারি অগ্রাধিকারের একটি টাস্ক তৈরি করো।”
মডেল প্রসেসিং: হোস্ট আপনার রিকোয়েস্ট ও প্রাসঙ্গিক টুল ডেফিনিশনগুলো LLM-এ পাঠায়।
টুল নির্বাচন: LLM একটি কাঠামোবদ্ধ টুল রিকোয়েস্ট তৈরি করে, যাতে টুল ও এর ইনপুট নির্দিষ্ট করা থাকে: add-task, সঙ্গে title: Review the draft ও priority: Medium। হোস্ট যাচাই করে কাজটির অনুমতি আছে কি না এবং রিকোয়েস্টটি MCP ক্লায়েন্টের কাছে পাঠায়, যা একটি JSON-RPC মেসেজ পাঠায়।
রিকোয়েস্ট: MCP ক্লায়েন্ট তার MCP সার্ভারে একটি tools/call রিকোয়েস্ট পাঠায়।
টুল এক্সিকিউশন: নির্দিষ্ট শিরোনাম ও অগ্রাধিকারসহ একটি নতুন টাস্ক তৈরি করতে MCP সার্ভার টাস্ক ম্যানেজমেন্ট অ্যাপ্লিকেশনের API কল করে।
ফলাফল ফেরত: সার্ভার ফলাফলটি MCP ক্লায়েন্টের কাছে ফেরত পাঠায়, যা সেটি হোস্টের কাছে পৌঁছে দেয়। হোস্ট এটি LLM-কে সরবরাহ করা তথ্যের সঙ্গে যোগ করে।
উত্তর তৈরি: LLM ফলাফলটি ব্যবহার করে ব্যবহারকারীর জন্য একটি উত্তর তৈরি করে, যেমন “আমি মাঝারি অগ্রাধিকারসহ খসড়াটি রিভিউ করার একটি টাস্ক তৈরি করেছি।”

MCP ও প্রচলিত API আর্কিটেকচার নিয়ে প্রায়ই বিভ্রান্তি হয়, তবে এগুলো একে অপরের পরিপূরক প্রযুক্তি। MCP বিশেষভাবে AI-ভিত্তিক অ্যাপ্লিকেশনের জন্য তৈরি করা হয়েছে। এটি একাধিক হার্ড-কোডেড API সংযোগ বাস্তবায়ন ও পরিচালনার উচ্চ রক্ষণাবেক্ষণের বোঝা দূর করে।

প্রতিটি ফাংশনালিটি প্রোভাইডার বা অভ্যন্তরীণ রিসোর্সের জন্য হোস্ট অ্যাপ্লিকেশনকে একটি মাত্র সংযোগ দিয়ে MCP অতিরিক্ত ভারী কনটেক্সট ইনপুট (সব API তালিকাভুক্ত করা) বা সীমিত API-ভিত্তিক অ্যাপ্লিকেশন স্ক্রিপ্টের সমস্যা দূর করতে সাহায্য করে।

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

চালু হওয়ার পর থেকেই MCP-এর নিরাপত্তা নিয়ে অনেক বিতর্ক হয়েছে। সাধারণভাবে এটিকে একটি নিরাপদ প্রযুক্তি হিসেবে বিবেচনা করা হলেও এর বেশ কিছু নিরাপত্তা ঝুঁকি রয়েছে, যার অনেকগুলো জটিল আর্কিটেকচার ইমপ্লিমেন্টেশনে বেশি প্রকট।

MCP আর্কিটেকচারের সম্ভাব্য দুর্বলতাগুলো হলো:

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

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

MCP ডেভেলপারদের জন্য একটি কার্যকর ও জনপ্রিয় ওপেন স্ট্যান্ডার্ড হিসেবে নিজেকে প্রমাণ করেছে। এটি LLM-ভিত্তিক অ্যাপ্লিকেশনে হার্ড-কোডেড API-এর অনেক সমস্যা দূর করে এবং ডেভেলপারদের কোডিংয়ের বোঝা উল্লেখযোগ্যভাবে কমায়।

সামনের দিনগুলোতে MCP-এর মূল হোস্ট ও সার্ভার আর্কিটেকচার প্রায় নিশ্চিতভাবেই একই থাকবে। ভবিষ্যতের উদ্ভাবনগুলো কেন্দ্রীভূত হবে বহু-ধাপের ওয়ার্কফ্লো জুড়ে উন্নত এজেন্টিক সক্ষমতার ওপর।

এছাড়া, এজেন্টিক ফাংশনালিটিগুলো বাস্তবায়িত হওয়ার সঙ্গে সঙ্গে আরও শক্তিশালী নিরাপত্তা সুরক্ষার প্রয়োজন হবে, এবং AI সিস্টেম আরও বিস্তৃত ও জটিল হয়ে ওঠায় স্কেলযোগ্য আর্কিটেকচারেরও প্রয়োজন হবে, বিশেষ করে ট্রান্সপোর্ট লেয়ারে।

MCP আর্কিটেকচার কী?

MCP আর্কিটেকচারের কম্পোনেন্ট: হোস্ট, ক্লায়েন্ট ও সার্ভার

হোস্ট

ক্লায়েন্ট

সার্ভার

MCP আর্কিটেকচারে ডেটা লেয়ার কী?

MCP আর্কিটেকচারে ট্রান্সপোর্ট লেয়ার কী?

MCP মাল্টি-টেন্যান্ট আর্কিটেকচার কী?

MCP আর্কিটেকচার ডায়াগ্রাম: ধাপে ধাপে ব্যাখ্যা

MCP আর্কিটেকচার প্রচলিত API আর্কিটেকচার থেকে কীভাবে আলাদা?

MCP আর্কিটেকচার কি নিরাপদ?

MCP আর্কিটেকচারের ভবিষ্যৎ কী?