MCP कॉलर ओळख

तुमच्या MCP server ला कोण कॉल करत आहे ते जाणून घ्या

तुमचा MCP server तुम्ही नियंत्रित न केलेल्या AI clients साठी tools उघडतो. Proof of Actor तुम्हाला प्रत्येक call च्या मागे काय आहे, त्याला कोणते evidence आधार देतात, हे सांगते, आणि प्रति tool policies ठरवू देते.

लवकर प्रवेश मिळवा ते कसे कार्य करते ते अन्वेषित करा

लेखक Toshendra Sharmaसंस्थापक आणि CEO, AgentCredia · Updated November 13, 2026

तुमची tools तुम्हाला न दिसणाऱ्या callers साठी खुली आहेत

एक MCP server तुमचे product AI clients साठी वापरण्यायोग्य बनवतो. तो tools, resources आणि prompts उघडतो, जे assistants आणि agents hosts, clients आणि servers मधील JSON-RPC 2.0 messages वापरून शोधू आणि call करू शकतात, जसे Model Context Protocol specification मध्ये वर्णन केले आहे. म्हणूनच teams ते तयार करतात: ते तुमचे product अशा workflows मध्ये ठेवतात जिथे AI agents आधीच काम करत असतात.

याचा अर्थ असा की तुमच्या server ला अशा clients कडून calls येतात जे तुम्ही तयार केलेले नाहीत आणि ज्यांचे तुम्ही थेट निरीक्षण करू शकत नाही. एकच tool local testing करणाऱ्या developer कडून, signed-in व्यक्तीच्या वतीने काम करणाऱ्या desktop assistant कडून, रात्रभर दीर्घ task चालवणाऱ्या autonomous agent कडून, किंवा तुमच्या server मधील कमजोरी शोधणाऱ्या एखाद्या स्रोताकडून invoke होऊ शकतो. protocol तुम्हाला कोणते tool call झाले आणि कोणत्या arguments सह झाले ते सांगतो. पण तो स्वतःहून call च्या मागे कोणत्या प्रकारचा actor आहे किंवा त्यावर तुम्ही किती विश्वास ठेवावा हे सांगत नाही.

MCP server caller identification ती पोकळी भरते. Proof of Actor प्रत्येक tool call ला evidence-backed actor result जोडते, जेणेकरून तुमचा server कोणाला काय द्यायचे याबद्दल माहितीपूर्ण निर्णय घेऊ शकेल. समस्येचा सखोल आढावा हवा असल्यास who is calling your MCP server वाचा, आणि teams ते कसे वापरतात हे पाहण्यासाठी 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 च्या मागे Human, Human + AI, Agent किंवा Unknown यापैकी कोणता actor आहे, आणि त्या उत्तराला कोणते evidence आधार देते.

MCP callers वेगळे कशामुळे असतात

MCP callers policy च्या दृष्टीने महत्त्वाच्या अशा प्रकारांनी browser visitors आणि पारंपरिक API clients पेक्षा वेगळे असतात.

ते जवळजवळ नेहमी automated असतात. प्रश्न "human की bot?" इतका नाही, तर "कोणता agent, कसे वागत आहे, आणि कोणत्या evidence सह?" असा असतो.
ते अनेकदा एखाद्या व्यक्तीच्या वतीने काम करतात. assistant तुमचे tool वापरत असेल कारण वापरकर्त्याने तसे सांगितले, किंवा तो स्वायत्तपणे काम करत असेल. या प्रकरणांवर वेगळे treatment आवश्यक आहे.
ते स्वतःबद्दल माहिती देतात. MCP lifecycle specification नुसार client ने clientInfo object मध्ये नाव आणि version देऊन आपला initialize request पाठवायचा असतो. हे declaration उपयुक्त context आहे, पण ते proof नाही.
Tools चा impact खूप वेगळा असतो. search tool आणि records delete करणारे tool यांना एकच policy लागू होऊ नये.

चांगली MCP caller identification या चारही गोष्टींचा आदर करायला हवी.

Proof of Actor MCP callers कसे ओळखते

तुमच्या server मधील signals

तुमचे MCP integration प्रत्येक call साठी उपलब्ध context Proof of Actor ला देते: client चे घोषित तपशील, transport आणि request context, client ने दिलेले कोणतेही cryptographic request signatures, जसे RFC 9421 मध्ये परिभाषित केलेले HTTP Message Signatures, आणि कॉल होणारे tool. प्रत्येक signal त्याच्या source सोबत label केलेला असतो.

आधारासह classification

Proof of Actor चार classes पैकी एक परत करते, Human, Human + AI, Agent किंवा Unknown, आणि निकालाचा basis देखील देते:

verified जेव्हा cryptographic check, जसे प्रकाशित key विरुद्ध request signature, पास होतो;
declared जेव्हा client किंवा तुमच्या application ने ते सांगितलेले असते, जसे session मधील client name;
inferred जेव्हा निकाल calls मधील patterns वर आधारित असतो;
unknown जेव्हा evidence निर्धारणास समर्थन देत नाही.

declared client name कधीही verification म्हणून सादर केला जात नाही. evidence अपुरे असल्यास निकाल Unknown असतो, आत्मविश्वासपूर्ण अंदाज नाही, आणि तुमच्या server ला नेमके काय हाताळत आहे ते कळते.

तुमची tools वापरू शकतील असा result

actor result tool call सोबत येतो, तुमच्या server च्या logic साठी तयार. observation mode मध्ये तुम्ही तो record करता. तुम्ही तयार झाल्यावर तुमचे tool-level policies त्यावर कृती करतात.

तुमच्या टीमला काय मिळते: Detect, Understand, Route

Detect

प्रत्येक tool call वर उपलब्ध caller evidence capture करा आणि verified, declared आणि inferred evidence वेगळे ठेवा.

Understand

कोणते clients कोणती tools call करतात, किती वेळा, कोणत्या evidence सह, आणि ते वेळेनुसार कसे बदलते ते पहा. प्रामुख्याने Unknown callers आकर्षित करणारी tools, वर्तन बदलणारे clients, आणि verifiable identity घेऊन येणाऱ्या calls चा वाटा शोधा.

Route

प्रत्येक tool आणि प्रत्येक risk tier साठी policies लिहा. सामान्य patterns:

Low-impact tools जसे search किंवा read-only lookups: broadly allow करा, standard rate limit सह.
Moderate-impact tools जसे drafts तयार करणे: verified आणि declared callers allow करा, Unknown ला rate-limit करा.
High-impact tools जसे data delete करणे, settings बदलणे, किंवा user च्या वतीने messages पाठवणे: तुमची strongest authorization आवश्यक ठेवा, आणि caller Unknown असेल किंवा autonomously काम करत असेल तेव्हा confirmation किंवा review जोडा.

protecting sensitive actions without blocking agents या guide मध्ये हे tiers कसे डिझाइन करायचे ते दाखवले आहे.

Identity evidence, credentials आणि authorization वेगळे आहेत

MCP security तेव्हा सर्वात चांगली काम करते जेव्हा तीन प्रश्न वेगळे ठेवले जातात:

Identity evidence: कोणत्या प्रकारचा client कॉल करत आहे, आणि त्याचा पुरावा काय? Proof of Actor हे प्रदान करते.
Credentials: हा call कोणत्या account किंवा token ने केला गेला? तुमच्या MCP server चे authentication हे प्रदान करते. MCP authorization specification authorization वैकल्पिक ठेवते आणि HTTP-based transports साठी ते OAuth 2.1 वर आधारित करते, ज्यामध्ये MCP server resource server म्हणून access tokens validate करतो.
Authorization: हा caller हे tool, या arguments सह, या account साठी वापरू शकतो का? तुमची permission model हे प्रदान करते.

recognised client आपोआप authorized होत नाही. वैध signature याचा अर्थ session मागील व्यक्तीने या विशिष्ट action साठी अधिकार सोपवला होता असे सिद्ध होत नाही. delegated authority आणि agent authorization बद्दल अधिक वाचा. Proof of Actor तुमच्या server ला पहिल्या प्रश्नासाठी चांगला context देते, त्यामुळे दुसऱ्या आणि तिसऱ्या प्रश्नांची उत्तरे अधिक माहितीपूर्ण होतात.

फक्त client name वर विश्वास का ठेवू नये?

कारण कोणताही client कोणतेही नाव पाठवू शकतो. घोषित नावाला proof मानल्यास imitation ला प्रोत्साहन मिळते: hostile client ला फक्त लोकप्रिय assistant चे नाव कॉपी करावे लागते. Proof of Actor नाव declared evidence म्हणून नोंदवते, ते उपलब्ध stronger evidence सोबत एकत्र करते, आणि तुम्हाला basis सांगते. मग तुमची policy verified callers ना declared callers पेक्षा अधिक मोकळीक देऊ शकते, आणि दोन्ही लागू नसतील तेव्हा तुमचा Unknown fallback वापरू शकते.

observation mode मध्ये सुरू करा

तुमच्या MCP server मध्ये Proof of Actor बसवल्याने कोणतेही tool कसे respond करते ते बदलत नाही. परिणाम record केले जातात, जेणेकरून कोण तुमची tools call करते, evidence किती मजबूत आहे, आणि policy कुठे उपयुक्त ठरेल हे तुम्ही पाहू शकता. तुम्ही confident झाल्यावर, एकाच high-impact tool वर policy enable करा, outcomes पहा, आणि मग विस्तार करा. How It Works संपूर्ण flow कव्हर करते, आणि Detection & Limitations प्रत्येक प्रकारचे evidence काय स्थापित करू शकते आणि काय नाही ते स्पष्ट करते.

MCP servers आणि APIs चालवणाऱ्या teams साठी तयार

Proof of Actor तुमच्या existing authentication, rate limiting आणि logging सोबत तुमच्या server मध्ये बसते. founding team सोबत प्रत्येक integration hands-on पद्धतीने दिले जाते, त्यामुळे setup तुमच्या transport, hosting आणि tool design ला बसतो. MCP Servers आणि APIs use cases दाखवतात की हाच approach तुमच्या tools आणि तुमच्या API वर कसा लागू होतो.

तुम्ही उघड केलेल्या प्रत्येक tool बद्दल विचारायचे प्रश्न

tool-level policies लिहिण्यापूर्वी, तुमचा MCP server ज्या प्रत्येक tool ला expose करतो त्याचे या लहान checklist सह review करणे उपयुक्त ठरते:

हे tool काय बदलू शकते? read-only tools आणि data modify करणारी, messages पाठवणारी किंवा billing वर परिणाम करणारी tools वेगळे treatment deserve करतात.
हे कोणासाठी आहे? काही tools signed-in व्यक्तीच्या वतीने काम करणाऱ्या assistants साठी असतात; इतर autonomous workflows साठी. expected caller योग्य policy ठरवतो.
चूक झाल्यास किंमत किती? चुकीचा search result स्वस्त असतो. चुकीचे deletion नाही. प्रत्येक tool ला risk tier शी जोडा.
कोणते evidence आवश्यक असावे? declared client पुरेसा आहे का, की tool ला verified identity plus तुमची strongest authorization आवश्यक आहे ते ठरवा.
Unknown वर काय होईल? प्रत्येक tool साठी explicit fallback निवडा: allow, rate-limit, user ला confirm करायला सांगा, किंवा review कडे route करा.
ते काम करत आहे हे तुम्हाला कसे कळेल? काहीही enforce करण्यापूर्वी observation mode मध्ये कोणते outcomes पहायचे ते ठरवा.

प्रत्येक tool साठी हे एकदा उत्तरल्याने caller identification स्पष्ट, testable rules मध्ये बदलते, आणि ते integrated clients ना तुमच्या server चे behavior समजावून सांगणे सोपे करते.

founding developer program मध्ये सहभागी व्हा

Proof of Actor private beta मध्ये आहे. निवडलेल्या founding development teams ना agreed usage limits मध्ये 12 months पर्यंत free access, आणि tool-level policies design करताना आमच्या engineers कडून direct support मिळू शकतो.

जर तुम्ही MCP server चालवत असाल आणि कोण त्याला call करत आहे हे जाणून घ्यायचे असेल, तर apply for early access. तुमच्या server बद्दल, तुम्ही expose करत असलेल्या 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: result मागचे signals, जेणेकरून तुमची team कारण पाहू शकेल.

observation mode मध्ये सुरुवात करा: results तुमच्या logs च्या शेजारी नोंदवा आणि तुम्ही policy निवडेपर्यंत काहीही बदलू नका. Node.js integration guide वाचा

वारंवार विचारले जाणारे प्रश्न

MCP server ला caller identification का हवे?

MCP servers अशा AI clients साठी tools उघडतात जे लोकांच्या वतीने कार्य करतात किंवा स्वायत्तपणे चालतात. tool call च्या मागे कोणत्या प्रकारचा caller आहे हे जाणून घेतल्याने तुम्ही कमी-प्रभावी tools मुक्तपणे allow करू शकता आणि जास्त-प्रभावी tools साठी अधिक आवश्यकता ठेवू शकता.

MCP session मधील client name ही verification आहे का?

नाही. client name हे client ने केलेले declaration आहे. Proof of Actor ते declared evidence म्हणून नोंदवते आणि cryptographically verified identity पासून वेगळे ठेवते.

Caller identification, MCP authorization ची जागा घेते का?

नाही. caller identity evidence, वापरलेले credential, आणि caller ला काय करण्याची परवानगी आहे हे वेगळे प्रश्न आहेत. Proof of Actor पहिल्या प्रश्नासाठी context जोडते आणि authorization तुमच्या server कडे सोडते.

Proof of Actor tool calls block करेल का?

फक्त तुमच्या policies तसे सांगत असतील तरच. प्रत्येक integration observation mode मध्ये सुरू होते, आणि तुम्ही तयार झाल्यावर tool-level policies enable करता.

मी ते कसे वापरून पाहू शकतो?

early access साठी अर्ज करा. निवडलेल्या founding developer teams ना agreed usage limits मध्ये 12 months पर्यंत free access, तसेच hands-on integration support मिळू शकते.

तुमचे app कोण वापरत आहे ते जाणून घ्या.

founding developers च्या छोट्या गटासाठी private beta.

लवकर प्रवेश मिळवा किमती पहा

आधी बोलणे पसंत आहे? founders शी बोला