MCP কলাৰ চিনাক্তকৰণ

আপোনাৰ MCP server-লৈ কোন কল কৰিছে জানক

আপোনাৰ MCP server-এ আপুনি নিয়ন্ত্ৰণ নকৰা AI client-সমূহৰ বাবে tools উন্মুক্ত কৰে। Proof of Actor-এ প্ৰতিটো call-ৰ পিছত কি আছে, কোন evidence-এ তাক সমৰ্থন কৰে, আৰু আপোনাক প্ৰতিটো tool-ৰ বাবে policy নিৰ্ধাৰণ কৰিবলৈ দিয়ে সেইটো দেখুৱায়.

Early Access লওক ই কেনেকৈ কাম কৰে অন্বেষণ কৰক

দ্বাৰা Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

আপোনাৰ tools এনে caller-সমূহৰ বাবে খোলা যাক আপুনি দেখা নাপায়

এটা MCP server-এ আপোনাৰ product-টো AI client-সমূহৰ বাবে usable কৰি তোলে। ই tools, resources আৰু prompts উন্মুক্ত কৰে যিবোৰ assistants আৰু agents-এ discover কৰি call কৰিব পাৰে, Model Context Protocol specification-ত বৰ্ণনা কৰা মতে hosts, clients আৰু servers-ৰ মাজত JSON-RPC 2.0 messages ব্যৱহাৰ কৰি। ঠিক এই কাৰণেই teams-এ এইবোৰ build কৰে: তেওঁলোকে আপোনাৰ product-টো সেই workflows-ৰ ভিতৰত ৰাখে য'ত AI agents ইতিমধ্যে কাম কৰি আছে।

ইয়াৰ অৰ্থ এইটোও যে আপোনাৰ server-এ এনে clients-ৰ পৰা calls পায় যিবোৰ আপুনি build কৰা নাই আৰু সোজাকৈ observe কৰিব নোৱাৰে। এটা single tool-এ local-ভাৱে test কৰা developer-এ, signed-in person-ৰ হৈ কাম কৰা desktop assistant-এ, ৰাতি দীঘল task চলোৱা autonomous agent-এ, বা আপোনাৰ server-ৰ দুর্বলতা probe কৰা কিবা এটাৰ দ্বাৰাও invoke হ'ব পাৰে। protocol-এ আপোনাক কয় কোন tool call কৰা হৈছিল আৰু কোন arguments-সহ। কিন্তু, নিজে নিজে, ই আপোনাক নকয় call-ৰ পিছত কেনেধৰণৰ actor আছে বা আপুনি তাক কিমান বিশ্বাস কৰিব লাগে।

MCP server caller identification-এ সেই gap পূৰণ কৰে। Proof of Actor-এ প্ৰতিটো tool call-লৈ evidence-backed actor result যোগ কৰে, যাতে আপোনাৰ server-এ কোনে কি পায় সেই বিষয়ে informed decision ল'ব পাৰে। সমস্যা-টোৰ গভীৰ দৃষ্টিৰ বাবে who is calling your MCP server পঢ়ক, আৰু teams-এ ইয়াক কেনেকৈ apply কৰে তাৰ বাবে MCP servers use case চাওক।

terms-সম্পৰ্কে এটা টোকা। "Caller identity"-ৰ cloud infrastructure-তো এটা সুপৰিচিত অৰ্থ আছে। উদাহৰণস্বৰূপে, AWS STS GetCallerIdentity-এ operation call কৰিবলৈ ব্যৱহৃত IAM user বা role-সম্পৰ্কে বিবৰণ দিয়ে। সেয়া কোন cloud credential-এ call কৰিছে সেইটো উত্তৰ দিয়ে। এই পৃষ্ঠাত MCP server caller identification-এ এটা ভিন্ন প্ৰশ্নৰ উত্তৰ দিয়ে: আপোনাৰ MCP server-লৈ এটা tool call-ৰ পিছত কেনেধৰণৰ actor, Human, Human + AI, Agent বা Unknown, আছে, আৰু সেই উত্তৰক কোন evidence সমৰ্থন কৰে।

MCP caller-সমূহ কিয় ভিন্ন

MCP caller-সমূহ browser visitor আৰু traditional API client-সমূহৰ পৰা policy-ৰ বাবে গুৰুত্বপূৰ্ণ উপায়ত ভিন্ন।

সাধাৰণতে সিহঁত প্ৰায় সদায় automated। প্ৰশ্নটো "মানুহ নে bot?"-তকৈ কম, আৰু "কোন agent, কেনেকৈ কাম কৰি আছে, কোন evidence-সহ?"-ত বেছি।
সিহঁতে বহুত সময়ত এটা person-ৰ হৈ কাম কৰে। এটা assistant-এ আপোনাৰ tool call কৰিব পাৰে কাৰণ user-এ তাক কৰিবলৈ কৈছে, বা ই স্বয়ংক্ৰিয়ভাৱে কাম কৰিব পাৰে। সেই case-সমূহৰ treatment পৃথক হোৱা উচিত।
সিহঁতে নিজকে describe কৰে। MCP lifecycle specification-এ client-এ নিজৰ clientInfo object-ত name আৰু version পাঠাবলৈ কয় initialize request-ত। সেই declaration উপযোগী context, কিন্তু ই declaration, proof নহয়।
tools-ৰ impact বহুত ভিন্ন। এটা search tool আৰু records delete কৰা এটা tool-এ একেটা policy share কৰা উচিত নহয়।

ভাল MCP caller identification-এ এই চাৰিওটা মানি চলিব লাগিব।

Proof of Actor-এ MCP caller-সমূহ কেনেকৈ চিনাক্ত কৰে

আপোনাৰ server-ৰ পৰা signals

আপোনাৰ MCP integration-এ প্ৰতিটো call-ৰ বাবে উপলব্ধ context Proof of Actor-লৈ দিয়ে: client-ৰ declared details, transport আৰু request context, client-এ দিয়ে কোনো cryptographic request signature, যেনে RFC 9421-ত সংজ্ঞায়িত HTTP Message Signatures, আৰু call কৰা tool। প্ৰতিটো signal-ত ইয়াৰ উৎস লেবেল কৰা হয়।

basis-সহ classification

Proof of Actor-এ চাৰিটা class-ৰ এটাত ফলাফল দিয়ে, Human, Human + AI, Agent বা Unknown, আৰু result-ৰ basis-সহ:

verified যেতিয়া কোনো cryptographic check, যেনে published key-ৰ বিৰুদ্ধে request signature, pass কৰে;
declared যেতিয়া client বা আপোনাৰ application-এ সেয়া ক'লে, যেনে session-ত client name;
inferred যেতিয়া result call-সমূহৰ pattern-ৰ ওপৰত নিৰ্ভৰ কৰে;
unknown যেতিয়া evidence-এ determination সমৰ্থন নকৰে।

declared client name কেতিয়াও verification হিচাপে উপস্থাপন কৰা নহয়। evidence পাতল হ'লে result Unknown হিচাপে থাকে, confident guess নহয়, আৰু আপোনাৰ server-এ স্পষ্টভাৱে জানে ই কি লৈ কাম কৰি আছে।

আপোনাৰ tools-এ ব্যৱহাৰ কৰিব পৰা result

actor result tool call-ৰ সৈতে একেলগে আহে, আপোনাৰ server-ৰ logic-ৰ বাবে প্ৰস্তুত হৈ। observation mode-ত আপুনি ইয়াক record কৰে। আপুনি প্ৰস্তুত হ'লে, আপোনাৰ tool-level policy-সমূহে ইয়াৰ ওপৰত কাম কৰে।

আপোনাৰ team-এ কি পায়: Detect, Understand, Route

Detect

প্ৰতিটো tool call-ত উপলব্ধ caller evidence capture কৰক আৰু verified, declared আৰু inferred evidence পৃথকে ৰাখক।

Understand

কোন client-এ কোন tool call কৰে, কিমানবাৰ, কোন evidence-সহ, আৰু সেইটো সময়ৰ সৈতে কেনেকৈ সলনি হয় দেখক। প্ৰধানকৈ Unknown caller আকৰ্ষণ কৰা tool, আচৰণ সলনি কৰা client, আৰু verifiable identity থকা call-ৰ ভাগ চিনাক্ত কৰক।

Route

প্ৰতিটো tool আৰু risk tier-অনুসৰি policy লিখক। সাধাৰণ pattern-সমূহ:

Low-impact tools যেনে search বা read-only lookup: broadly allow কৰক, এটা standard rate limit-সহ।
Moderate-impact tools যেনে drafts create কৰা: verified আৰু declared caller-সমূহ allow কৰক, Unknown-এ rate-limit কৰক।
High-impact tools যেনে data delete কৰা, settings সলনি কৰা বা user-ৰ হৈ messages পঠোৱা: আপোনাৰ strongest authorization required কৰক, আৰু caller Unknown বা স্বয়ংক্ৰিয়ভাৱে কাম কৰি থাকিলে confirmation বা review যোগ কৰক।

protecting sensitive actions without blocking agents-ৰ guide-এ এই tier-সমূহ কেনেকৈ design কৰিব দেখুৱায়।

Identity evidence, credentials আৰু authorization পৃথক

MCP security-য়ে তেতিয়া সৰ্বাধিক ভাল কাম কৰে যেতিয়া তিনিটা প্ৰশ্ন পৃথক হৈ থাকে:

Identity evidence: কোন ধৰণৰ client call কৰিছে, আৰু কি তাৰ proof? Proof of Actor-এ এইটো দিয়ে।
Credentials: কোন account বা token-সহ এই call কৰা হৈছে? আপোনাৰ MCP server-ৰ authentication-এ এইটো দিয়ে। MCP authorization specification-এ authorization optional কৰে আৰু HTTP-based transports-ৰ বাবে OAuth 2.1-ৰ ওপৰত ভিত্তি কৰে, MCP server-এ access token validate কৰা resource server হিচাপে কাম কৰে।
Authorization: এই caller-এ, এই arguments-সহ, এই account-ৰ বাবে, এই tool ব্যৱহাৰ কৰিব পাৰিবনে? আপোনাৰ permission model-এ এইটো দিয়ে।

এটা recognized client স্বয়ংক্ৰিয়ভাৱে authorized নহয়। এটা valid signature-এ session-ৰ পিছত থকা person-এ এই specific action-ৰ বাবে authority delegate কৰিছিল নে নাই তাক দেখুৱায় নোৱাৰে। delegated authority আৰু agent authorization-ৰ বিষয়ে অধিক পঢ়ক। Proof of Actor-এ প্ৰথম প্ৰশ্নৰ বাবে আপোনাৰ server-লৈ ভাল context দিয়ে যাতে দ্বিতীয় আৰু তৃতীয় প্ৰশ্নৰ উত্তৰ অধিক informed হয়।

কেৱল client name-ৰ ওপৰত বিশ্বাস কিয় নকৰিব?

কাৰণ যিকোনো client-এ যিকোনো name পঠাব পাৰে। declared name-এ proof হিচাপে আচৰণ কৰিলে imitation-ৰ দুৱাৰ খুলে: hostile client-এ কেৱল এটা popular assistant-ৰ name copy কৰিলেই হয়। Proof of Actor-এ name-টো declared evidence হিচাপে record কৰে, যি stronger evidence আছে তাৰ সৈতে combine কৰে, আৰু আপোনাক basis কয়। তাৰ পাছত আপোনাৰ policy-এ verified caller-সমূহক কেৱল নিজকে declare কৰা caller-সমূহতকৈ বেছি স্বাধীনতা দিব পাৰে, আৰু কোনোটোৱেই fit নকৰিলে আপোনাৰ Unknown fallback apply কৰিব পাৰে।

observation mode-ত আৰম্ভ কৰক

আপোনাৰ MCP server-ত Proof of Actor install কৰিলেও কোনো tool-এ কেনেকৈ respond কৰে সেয়া সলনি নহয়। result record কৰা হয় যাতে আপুনি দেখিব পাৰে কোনে আপোনাৰ tool call কৰে, evidence কিমান strong, আৰু ক'ত policy-য়ে সহায় কৰিব। আপুনি confident হ'লে, এটা single high-impact tool-ত policy enable কৰক, outcome চাওক, তাৰ পাছত বিস্তাৰ কৰক। How It Works-এ সম্পূৰ্ণ flow সামৰি লয়, আৰু Detection & Limitations-এ প্ৰতিটো evidence type-এ কি establish কৰিব পাৰে আৰু কি নোৱাৰে তাক ব্যাখ্যা কৰে।

MCP servers আৰু APIs চলোৱা team-সমূহৰ বাবে নিৰ্মিত

Proof of Actor আপোনাৰ existing authentication, rate limiting আৰু logging-ৰ সৈতে server-ৰ ভিতৰত থাকে। integrations প্ৰতিটো founding team-ৰ সৈতে hands-on ভাবে deliver কৰা হয়, যাতে setup-টো আপোনাৰ transport, hosting আৰু tool design-ৰ সৈতে মানানসই হয়। MCP Servers আৰু APIs use case-সমূহে দেখুৱায় এই একে approach-টো কেনেকৈ আপোনাৰ tools আৰু আপোনাৰ API-ৰ ওপৰত প্ৰয়োগ হয়।

আপুনি উন্মুক্ত কৰা প্ৰতিটো tool-ৰ বিষয়ে সোধাৰ বাবে প্ৰশ্ন

tool-level policy লিখাৰ আগতে, আপোনাৰ MCP server-এ উন্মুক্ত কৰা প্ৰতিটো tool এটা চুটি checklist-সহ পুনৰালোচনা কৰাটো সহায়ক:

এই tool-এ কি সলনি কৰিব পাৰে? Read-only tool আৰু data modify কৰা, messages পঠোৱা বা billing-ত প্ৰভাৱ পেলোৱা tool-সমূহৰ treatment পৃথক হওয়া উচিত।
ই কাকৰ বাবে? কিছুমান tool signed-in person-ৰ হৈ কাম কৰা assistants-ৰ বাবে; আন কিছুমান autonomous workflow-ৰ বাবে। expected caller-এ উপযুক্ত policy shape কৰে।
এটা ভুলৰ খৰচ কিমান হ'ব? ভুল search result সস্তা। ভুল deletion সস্তা নহয়। প্ৰতিটো tool-কে এটা risk tier-লৈ map কৰক।
কোন evidence প্ৰয়োজন হোৱা উচিত? declared client যথেষ্ট নে, বা tool-এ verified identity আৰু আপোনাৰ strongest authorization প্ৰয়োজন নেকি সিদ্ধান্ত লওক।
Unknown-ত কি হ'ব? প্ৰতিটো tool-ৰ বাবে এটা explicit fallback বাছক: allow, rate-limit, user-এ confirm কৰিবলৈ ক'ব, বা review-লৈ route কৰক।
ই কাম কৰিছে বুলি আপুনি কেনেকৈ জানিব? কিবা enforce কৰাৰ আগতে observation mode-ত আপুনি কোন outcome-সমূহ লক্ষ্য কৰিব সেয়া নিৰ্ধাৰণ কৰক।

প্ৰতিটো tool-ৰ বাবে এইবোৰ এটা বাৰ উত্তৰ দিলে caller identification-টো স্পষ্ট, testable rule-লৈ ৰূপান্তৰিত হয়, আৰু আপোনাৰ server-ৰ behaviour সংহত কৰা clients-সমূহক বুজাবলৈ সহজ হয়।

founding developer program-ত যোগদান কৰক

Proof of Actor private beta-ত আছে। নিৰ্বাচিত founding development team-সমূহে agreed usage limits-ৰ ভিতৰত up to 12 months free access লাভ কৰিব পাৰে, tool-level policy design কৰোঁতে আমাৰ engineers-ৰ direct support-সহ।

আপুনি যদি এটা MCP server চলায় আৰু জানিব খোজে কোনে তাক call কৰিছে, apply for early access. আপোনাৰ server, আপুনি উন্মুক্ত কৰা tools আৰু আপুনি সৰ্বাধিক গুৰুত্ব দিয়া calls-ৰ বিষয়ে কওক।

Sources

Model Context Protocol specification (2025-06-18), modelcontextprotocol.io.
MCP lifecycle: initialization and clientInfo, modelcontextprotocol.io.
MCP authorization, modelcontextprotocol.io.
RFC 9421: HTTP Message Signatures, IETF, February 2024.
AWS STS GetCallerIdentity API reference, Amazon Web Services.

ডেভেলপারসকলৰ বাবে

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record

{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}

class: Human, Human + AI, Agent বা Unknown।
basis: প্ৰমাণ কিমান শক্তিশালী: verified, declared, inferred বা unknown।
evidence: ফলাফলৰ পিছৰ signal, যাতে আপোনাৰ দলক কাৰণ দেখা যায়।

observation mode-ত আৰম্ভ কৰক: আপোনাৰ log-ৰ কাষে ফলাফল record কৰক আৰু আপুনি policy বাছি নলৈকে একো সলনি নকৰিব। Node.js integration guide পঢ়ক

সঘনাই সোধা প্ৰশ্নসমূহ

MCP server-এ caller identification কিয় প্ৰয়োজন?

MCP server-সমূহে AI client-সমূহক tools উন্মুক্ত কৰে যিবোৰ মানুহৰ হৈ কাম কৰে বা স্বয়ংক্ৰিয়ভাৱে চলে। tool call-ৰ পিছত কেনেধৰণৰ caller আছে জানিলে আপুনি কম-প্ৰভাবৰ tool-সমূহ মুক্তভাৱে allow কৰিব পাৰে আৰু অধিক-প্ৰভাবৰ tool-সমূহৰ বাবে অধিক requirement ৰাখিব পাৰে.

MCP session-ত client name এটা verification নেকি?

নহয়। client name হৈছে client-এ কৰা এটা declaration। Proof of Actor-এ ইয়াক declared evidence হিচাপে record কৰে আৰু cryptographically verified identity-ৰ পৰা পৃথক ৰাখে.

caller identification-এ MCP authorization-ৰ ঠাই লয় নেকি?

নহয়। caller identity evidence, ব্যৱহৃত credential আৰু caller-এ কি কৰিব পাৰে সেইবোৰ পৃথক প্ৰশ্ন। Proof of Actor-এ প্ৰথমটোৰ বাবে context যোগ কৰে আৰু authorization আপোনাৰ server-ৰ ওপৰত এৰি দিয়ে.

Proof of Actor-এ tool call block কৰিব নেকি?

কেৱল যদি আপোনাৰ policy-সমূহে তেনেকৈ কয়। প্ৰতিটো integration observation mode-ত আৰম্ভ হয়, আৰু আপুনি প্ৰস্তুত হ'লে tool-level policy enable কৰে.

মই ইয়াক কেনেকৈ চেষ্টা কৰিব পাৰোঁ?

early access-ৰ বাবে আবেদন কৰক। নিৰ্বাচিত founding developer team-সমূহে agreed usage limits-ৰ ভিতৰত up to 12 months free লাভ কৰিব পাৰে, hands-on integration support-সহ.

আপোনাৰ app ক কোনে ব্যৱহাৰ কৰিছে জানক।

এটা সৰু founding developer দলৰ বাবে private beta।

Early Access লওক মূল্য তালিকা চাওক

আগতে কথা পাতিবলৈ পচন্দ কৰেনে? Founding team-ৰ সৈতে কথা পাতক