Business Owner-এর জন্য MCP: একই ভাষায় Connection, প্রতি ধাপে Permission

Demo-তে assistant-কে stock question-এর উত্তর দিতে দেখে owner চান সোমবারের মধ্যে orders, inventory ও accounting-ও যুক্ত হোক। Operations lead-এর প্রশ্ন আলাদা: branch manager জিজ্ঞেস করলে assistant আসলে কোন branch-এর record দেখতে পারবে?

Retailer-টি কাল্পনিক, কিন্তু software কেনার আগে এই আলোচনাই দরকার। Common connection format integration-এর কাজ কমাতে পারে; company permission ঠিক করে দেওয়া, সব উত্তর সঠিক করা বা data স্থানীয় রাখা তার একার কাজ নয়। MCP—Model Context Protocol—দুটি program-এর সাধারণ ভাষা; সীমা বেছে নিতে হয় মানুষকেই।

এটি operations-AI সিরিজের দ্বিতীয় লেখা। প্রথম পর্বে agent-এর উপযুক্ত কাজ, তৃতীয় পর্বে approval ও audit evidence। নিচের connection বুঝতে code লাগবে না।

একই ভাষা, তিনটি আলাদা দায়িত্ব

AI application অন্য program-এর capability কীভাবে খুঁজে ব্যবহার করবে, MCP সেটি বর্ণনা করে। পরিচিত plug-এর shape ভাবুন: compatibility-তে কাজে আসে, কিন্তু কে device ব্যবহার করবেন বা কী data দেখাবে, shape একা তা ঠিক করে না।

Host হলো মানুষ যে assistant application ব্যবহার করেন। তার client component MCP server-এর সঙ্গে কথা বলে। Server অনুমোদিত request-কে business system-এর existing operation-এ রূপ দেয়। এটি software-এর ভূমিকা; আলাদা physical machine হতেই হবে না। এক host একাধিক server-এ যুক্ত হতে পারে।

Server resources (URI দিয়ে চিহ্নিত context), tools (ডাকা যায় এমন function) এবং prompts (পুনর্ব্যবহারযোগ্য message template) দিতে পারে। Stock lookup read-only tool-ও হতে পারে; “tool” মানেই write নয়, “resource” মানেই non-sensitive নয়। Prompt template access policy নয়। Actual host/server কোন feature support করে দেখুন; তিনটিই আছে ধরে নেবেন না।

Reusable Component আর Permission Path এক হিসাব নয়

ধরুন তিন assistant application ও তিন business system। সরল bespoke design-এ নয়টি pair-specific integration থাকতে পারে। MCP একই protocol-এর কাজ বারবার না করে reusable host/client support ও server interface দেয়—ধারণাগতভাবে তিন যোগ তিন component।

প্রতি assistant সব system ব্যবহার করলে এখনও তিন × তিন = নয়টি logical access path configure ও authorise করতে হবে। “ছয়টি reusable component” মানে “ছয়টি live connection” নয়। Infrastructure share বা system একত্র হতে পারে; সব adapter বানানোর পরিশ্রমও সমান নয়। এটি design-এর উদাহরণ, guaranteed saving নয়।

Business mapping, unit, identifier, validation ও downstream API-এর কাজ থাকবেই। Operation-এর authoritative rule তার owning system-এ রাখুন; screen, API ও MCP একই rule ব্যবহার করুক। Host ও model provider-এরও security দায়িত্ব আছে; MCP সব rule জাদুর মতো এক gateway-তে নিয়ে আসে না।

একটি Stock Question, পুরো Company Data নয়

শিক্ষামূলক উদাহরণে manager Store 2-এর stock পড়তে পারেন, অন্য store-এর margin বা payroll নয়। তিনি জানতে চান নিজের location-এর bottle এখন কত বিক্রি করা যায়। Host permitted stock lookup চালায়; server data দেওয়ার আগে identity, scope, store ও field access দেখে।

Snapshot-এর সময়ে physical on-hand 50, এর মধ্যে quality hold-এ 5। Approved 45-এর 20 আগে থেকেই reserved। তাই current free approved stock 50 − 5 − 20 = 25। এই উদাহরণে category-গুলো পরস্পর overlap করে না। System-এর “available” figure-এ hold/reservation আগেই বাদ থাকলে আবার বাদ দেবেন না।

উত্তরে location, unit, status-এর ভিত্তি ও evidence time থাকবে। Database-এ আছে বলেই customer address বা supplier cost পাঠাবে না। Free 25 unit একটি snapshot; delivery promise বা future-demand forecast নয়। পরের order-এই availability বদলাতে পারে।

Manager অন্য store-এর restricted figure চাইলে retrieval-এর আগেই deny হবে। Restricted record model context, cache বা log-এ যাওয়ার পরে শুধু final sentence filter করা দেরি হয়ে যায়। পরে draft purchase order চাইলে সেটি আলাদা permission ও workflow; stock question-এর উত্তর দেওয়ার অধিকার কেনার অনুমতি নয়।

Identity, Consent ও Business Rights আলাদা Check

Protected remote HTTP connection-এর জন্য supplier-এর সঙ্গে MCP authorisation specification দেখুন। এতে OAuth-based framework আছে। Protocol level-এ authorisation optional; তার মানে private ERP data anonymous করে দেওয়া নয়। Local stdio process-এ HTTP OAuth flow নির্ধারিত পদ্ধতি নয়; credential ও operating-system access আলাদাভাবে নিয়ন্ত্রণ করতে হবে।

Sign-in user শনাক্ত করে; consent client-এর access অনুমোদন করে; scope token সীমিত করে; application rule বলে এই user এই record পড়তে বা action approve করতে পারবেন কি না। OAuth নিজে সব ERP role, record filter বা approval rule কপি করে দেয় না। প্রতি call-এ effective access user rights, delegated tool scope ও current policy মানবে।

Token audience/resource validation, প্রযোজ্য ক্ষেত্রে PKCE, secure storage, expiry, revocation ও user-disable check কীভাবে হয় জানতে চান। কোনোটি stolen credential বা compromised host-এর বিরুদ্ধে সর্বজনীন ঢাল নয়। Shortcut হিসেবে এক service-এর token অন্য সম্পর্কহীন service-এ passthrough করবেন না। Unattended কাজের limited service identity, owner ও review চাই; নীরবে manager সেজে নয়।

Local MCP server executable software। Trusted publisher ও controlled version বেছে নিন; কোন file, credential ও network destination পায় বুঝুন। “আমার laptop-এ চলে” security certificate নয়।

Connect করার আগে Data-এর পথ আঁকুন

Server ERP-এর পাশে চললেও host/model অন্য জায়গায় চলতে পারে। Host ঠিক করে returned context-এর কোন অংশ model বা service-এ যাবে; প্রতিটি byte আপনাআপনি পাঠাতেই হবে এমন নয়। Prompt, result, cache, log, support access, subprocessor, retention ও training terms-সহ actual পথ দেখুন।

সবচেয়ে কম প্রয়োজনীয় field, অনুমোদিত record ও approved model destination ব্যবহার করুন। Customer text, internal note ও supplier file-এ hostile instruction থাকতে পারে; company-এর ভেতরে থাকলেই document authority নয়। Tool description বা read-only hint-ও safe implementation-এর প্রমাণ নয়। Model ভুল request করলেও application check কার্যকর থাকতে হবে।

নিচের সীমাগুলো vendor-কে দেখাতে বলুন। Audit evidence ঘটনা বুঝতে সাহায্য করে; log আছে বলেই ঘটনা বন্ধ হয় না। Sensitive data redact ও access control করুন; সব raw argument/result অনির্দিষ্টকাল জমাবেন না।

সীমা	Vendor-এর কাছে যে প্রমাণ চাইবেন
Identity ও Record	ID দিয়েও manager অন্য store-এর restricted record আনতে পারবেন না
Data Minimisation	Stock response-এ private cost, address বা অপ্রাসঙ্গিক field নেই
Action Control	Draft-এ hidden reservation/send নেই; execution-এ proper approval লাগে
Failure Recovery	Unknown committed result মেলানো হয়; retry-তে duplicate নয়
Evidence ও Revocation	সীমিত, redacted audit; ঘোষিত disable/revocation policy-তে access বন্ধ

Version জিজ্ঞেস করুন, Scaling-এর নিশ্চয়তা কিনবেন না

এই review-এ official 2026-07-28 specification দেখা হয়েছে; এর core request self-contained। আগের revision-এ connection-scoped session ছিল। দুই প্রান্তে actual revision, transport, optional feature, compatibility test ও update owner কী—জানুন।

Protocol stateless হলেই purchase workflow stateless হয় না, shared business data-ও বাদ যায় না। Authentication, capacity, database consistency, operation reference ও long-running কাজের design লাগবেই। Version দেখিয়েই load balancer বাড়ালে ERP নিরাপদে scale করবে বলা যায় না।

প্রথম Connection এত ছোট রাখুন, যেন যাচাই করা যায়

এক manager, এক location ও একটি কাজের lookup বেছে নিন। Allowed field, evidence freshness, provider destination ও owner লিখুন। Empty, stale ও ambiguous case-সহ source system-এর সঙ্গে উত্তর মেলান। Menu লুকানো দেখেই নয়, forbidden record সরাসরি চাইলে কী হয় দেখুন।

Document-এর ভেতর instruction, expired/revoked access, বদলে যাওয়া tool definition ও provider outage পরীক্ষা করুন। Write tool যোগ করার আগে exact-version approval, সত্যিকারের inert draft এবং commit-এর পর timeout দেখুন। Bounded backoff/retry-এর আগে existing operation reconcile করুন; duplicate commitment আটকান, uncertain outcome-এর owner রাখুন। Denied/invalid request বারবার retry নয়।

Test ও business value যুক্তিযুক্ত হলেই access বাড়ান, চার সপ্তাহ পেরিয়েছে বলে নয়। StoreConsole demo আলোচনার workflow দেখায়; আপনার installation-এর নির্দিষ্ট MCP host, version বা permission enabled থাকার প্রমাণ নয়।

Retailer-এর সোমবারের ভালো ফল সহজ: manager নিজের store-এ timestamp-সহ 25 free approved bottle যাচাই করতে পারেন, অন্য সবার data টানতে পারেন না। MCP দুই program-কে request বুঝিয়েছে; tested access policy সেই উত্তরটি উপযুক্ত করেছে।

পর্যালোচনা: 5 নভেম্বর 2026। Anichur Rahaman StoreConsole-এর নির্মাতা। Retailer, stock quantity ও connection count শিক্ষামূলক উদাহরণ।