मुख्य सामग्री पर जाएं
MCP कॉलर पहचान

जानें कि आपका MCP server कौन कॉल कर रहा है

आपका MCP server उन AI clients के लिए tools उपलब्ध कराता है जिन्हें आप नियंत्रित नहीं करते। Proof of Actor आपको बताता है कि हर call के पीछे क्या है, कौन-सा evidence इसे समर्थन देता है, और आपको प्रति tool policies तय करने देता है।

Early Access प्राप्त करेंयह कैसे काम करता है, देखें
Toshendra Sharma

द्वारा Toshendra Sharmaसंस्थापक और CEO, AgentCredia · Updated November 13, 2026

आपके tools ऐसे callers के लिए खुले हैं जिन्हें आप देख नहीं सकते

एक MCP server आपके product को AI clients के लिए usable बनाता है। यह tools, resources और prompts expose करता है जिन्हें assistants और agents discover और call कर सकते हैं, और Model Context Protocol specification में वर्णित अनुसार hosts, clients और servers के बीच JSON-RPC 2.0 messages का उपयोग करता है। यही कारण है कि टीमें इन्हें बनाती हैं: वे आपके product को उन workflows के भीतर रखते हैं जहाँ AI agents पहले से काम कर रहे होते हैं।

इसका मतलब यह भी है कि आपके server को ऐसे clients से calls मिलती हैं जिन्हें आपने नहीं बनाया और जिन्हें आप सीधे observe नहीं कर सकते। एक ही tool को स्थानीय रूप से परीक्षण करने वाला developer, signed-in व्यक्ति की ओर से काम करने वाला desktop assistant, रातभर चलने वाला autonomous agent, या आपके server की कमजोरियाँ जाँचने वाली कोई चीज़ invoke कर सकती है। protocol आपको बताता है कि कौन-सा tool call हुआ और किन arguments के साथ। लेकिन अपने-आप यह नहीं बताता कि call के पीछे किस तरह का actor है या आपको उस पर कितना भरोसा करना चाहिए।

MCP server caller identification इस कमी को पूरा करता है। Proof of Actor हर tool call में evidence-backed actor result जोड़ता है, ताकि आपका server यह informed निर्णय ले सके कि किसे क्या मिलता है। समस्या पर गहराई से पढ़ने के लिए, who is calling your MCP server पढ़ें, और teams इसे कैसे लागू करती हैं, यह देखने के लिए MCP servers use case देखें।

शब्दों पर एक नोट। "Caller identity" का cloud infrastructure में भी एक प्रसिद्ध अर्थ है। उदाहरण के लिए, AWS STS GetCallerIdentity उस IAM user या role के बारे में विवरण लौटाता है जिसकी credentials का उपयोग operation को call करने के लिए किया जाता है। यह बताता है कि कौन-सी cloud credential ने call की। इस page पर 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 को इसलिए call कर सकता है क्योंकि user ने उससे ऐसा कहा, या वह autonomously काम कर सकता है। इन मामलों का treatment अलग होना चाहिए।
  • वे अपना परिचय स्वयं देते हैं। MCP lifecycle specification में client अपने initialize request में name और version के साथ एक clientInfo object भेजता है। यह declaration उपयोगी context है, लेकिन यह proof नहीं है।
  • tools का impact बहुत अलग-अलग होता है। एक search tool और एक tool जो records delete करता है, एक ही policy साझा नहीं करने चाहिए।

अच्छी MCP caller identification को इन चारों का सम्मान करना चाहिए।

Proof of Actor MCP callers की पहचान कैसे करता है

आपके server से signals

आपका MCP integration हर call के लिए उपलब्ध context Proof of Actor को देता है: client के declared details, transport और request context, कोई भी cryptographic request signatures जो client प्रदान करता है, जैसे RFC 9421 में परिभाषित HTTP Message Signatures, और जिस tool को call किया जा रहा है। हर signal को उसके स्रोत के साथ label किया जाता है।

आधार के साथ classification

Proof of Actor चार classes में से एक लौटाता है, Human, Human + AI, Agent या Unknown, साथ ही परिणाम का basis भी:

  • verified जब कोई cryptographic check, जैसे published key के विरुद्ध request signature, सफल हो;
  • declared जब client या आपका application उसे stated करे, जैसे session में client name;
  • inferred जब परिणाम calls में मौजूद patterns पर आधारित हो;
  • unknown जब evidence किसी determination का समर्थन न करे।

Declared client name को कभी verification के रूप में प्रस्तुत नहीं किया जाता। जब evidence कमज़ोर हो, तो परिणाम Unknown होता है, न कि एक आत्मविश्वासी अनुमान, और आपका server ठीक-ठीक जानता है कि वह किसके साथ काम कर रहा है।

ऐसा परिणाम जिसे आपके tools उपयोग कर सकें

actor result tool call के साथ आता है, और आपके server की logic के लिए तैयार रहता है। observation mode में आप इसे record करते हैं। जब आप तैयार हों, आपकी tool-level policies उस पर action लेती हैं।

आपकी team को क्या मिलता है: Detect, Understand, Route

Detect

हर tool call पर उपलब्ध caller evidence capture करें और verified, declared तथा inferred evidence को अलग रखें।

Understand

देखें कि कौन-से clients कौन-से tools को call करते हैं, कितनी बार, किस evidence के साथ, और समय के साथ यह कैसे बदलता है। ऐसे tools पहचानें जो अधिकतर Unknown callers आकर्षित करते हैं, बदलते व्यवहार वाले clients, और उन calls का हिस्सा जिनमें verifiable identity होती है।

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 भेजना: अपनी सबसे मजबूत authorization आवश्यक करें, और जहाँ caller Unknown हो या autonomously काम कर रहा हो, वहाँ confirmation या review जोड़ें।

protecting sensitive actions without blocking agents पर guide दिखाती है कि इन tiers को कैसे design करें।

Identity evidence, credentials और authorization अलग हैं

MCP security सबसे अच्छा तब काम करती है जब तीन प्रश्न अलग रहें:

  1. Identity evidence: कौन-सा client call कर रहा है, और इसे क्या साबित करता है? Proof of Actor यह प्रदान करता है।
  2. Credentials: यह call किस account या token के साथ की गई है? आपका MCP server का authentication यह प्रदान करता है। MCP authorization specification authorization को optional बनाता है और HTTP-based transports के लिए इसे OAuth 2.1 पर आधारित करता है, जिसमें MCP server एक resource server के रूप में काम करता है जो access tokens validate करता है।
  3. Authorization: क्या यह caller इस tool को, इन arguments के साथ, इस account के लिए उपयोग कर सकता है? आपका permission model यह प्रदान करता है।

एक recognized client अपने-आप authorized client नहीं होता। एक valid signature यह नहीं दिखाता कि session के पीछे वाले व्यक्ति ने इस specific action के लिए authority delegate की थी। delegated authority और agent authorization के बारे में अधिक पढ़ें। Proof of Actor पहले प्रश्न के लिए आपके server को बेहतर context देता है, ताकि दूसरे और तीसरे प्रश्न के उत्तर अधिक informed हों।

सिर्फ client name पर भरोसा क्यों न करें?

क्योंकि कोई भी client कोई भी name भेज सकता है। declared name को proof मानना imitation को आमंत्रित करता है: एक hostile client को बस किसी लोकप्रिय assistant का name कॉपी करना होता है। Proof of Actor उस name को declared evidence के रूप में record करता है, उसे मौजूद किसी भी मजबूत evidence के साथ जोड़ता है, और आपको उसका basis बताता है। फिर आपकी policy verified callers को केवल declared callers से अधिक छूट दे सकती है, और जहाँ दोनों में से कोई लागू न हो, वहाँ आपका Unknown fallback लागू कर सकती है।

observation mode में शुरू करें

अपने MCP server में Proof of Actor install करने से किसी tool का response बदलता नहीं है। results record किए जाते हैं, ताकि आप देख सकें कि आपके tools को कौन call करता है, evidence कितना मजबूत है, और कहाँ policies मदद करेंगी। जब आप आश्वस्त हों, तो किसी एक high-impact tool पर policy सक्षम करें, outcomes देखें, फिर विस्तार करें। How It Works पूरे flow को कवर करता है, और Detection & Limitations समझाता है कि evidence का हर प्रकार क्या establish कर सकता है और क्या नहीं।

MCP servers और APIs चलाने वाली teams के लिए बनाया गया

Proof of Actor आपके server के भीतर आपकी मौजूदा authentication, rate limiting और logging के साथ बैठता है। Integrations हर founding team के साथ hands-on deliver की जाती हैं, ताकि setup आपके transport, hosting और tool design के अनुरूप हो। MCP Servers और APIs use cases दिखाते हैं कि यही approach आपके tools और आपके API पर कैसे लागू होती है।

हर exposed tool के बारे में पूछने योग्य प्रश्न

tool-level policies लिखने से पहले, अपने MCP server द्वारा expose किए गए हर tool को एक छोटी checklist के साथ review करना मदद करता है:

  • यह tool क्या बदल सकता है? Read-only tools और data बदलने, messages भेजने या billing को प्रभावित करने वाले tools के साथ अलग व्यवहार होना चाहिए।
  • यह किसके लिए है? कुछ tools signed-in व्यक्ति की ओर से काम करने वाले assistants के लिए होते हैं; कुछ autonomous workflows के लिए। अपेक्षित caller सही policy तय करता है।
  • किसी गलती की लागत क्या होगी? गलत search result सस्ता है। गलत deletion नहीं। हर tool को एक risk tier में map करें।
  • कौन-सा evidence आवश्यक होना चाहिए? तय करें कि declared client पर्याप्त है या tool को verified identity plus आपकी सबसे मजबूत authorization चाहिए।
  • Unknown पर क्या होगा? हर tool के लिए एक explicit fallback चुनें: allow, rate-limit, user से confirm कराना, या review के लिए route करना।
  • आप कैसे जानेंगे कि यह काम कर रहा है? तय करें कि किसी भी enforcement से पहले observation mode में किन outcomes पर नज़र रखनी है।

हर tool के लिए एक बार इन प्रश्नों के उत्तर देना caller identification को स्पष्ट, testable rules में बदल देता है, और आपके server के व्यवहार को उससे integrate करने वाले clients को समझाना आसान बनाता है।

founding developer program में शामिल हों

Proof of Actor private beta में है। चुनी गई founding development teams agreed usage limits के भीतर up to 12 months free access प्राप्त कर सकती हैं, tool-level policies design करते समय हमारे engineers से direct support के साथ।

यदि आप MCP server चलाते हैं और जानना चाहते हैं कि इसे कौन call कर रहा है, तो apply for early access करें। हमें अपने server, आपके द्वारा expose किए गए tools, और जिन calls की आपको सबसे अधिक चिंता है, उनके बारे में बताएं।

Sources

डेवलपर्स के लिए

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 के पास record करें और जब तक आप कोई policy न चुनें, कुछ न बदलें। Node.js integration guide पढ़ें

अक्सर पूछे जाने वाले प्रश्न

MCP server को caller identification की जरूरत क्यों होती है?

MCP servers उन AI clients के लिए tools उपलब्ध कराते हैं जो लोगों की ओर से काम करते हैं या स्वायत्त रूप से चलते हैं। यह जानना कि tool call के पीछे किस तरह का caller है, आपको कम-impact tools को खुलकर allow करने और high-impact 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 सक्षम करते हैं।

मैं इसे कैसे आज़मा सकता हूँ?

early access के लिए apply करें। चुनी गई founding developer teams को agreed usage limits के भीतर up to 12 months free मिल सकते हैं, साथ ही hands-on integration support भी।

जानें कि आपका app कौन उपयोग कर रहा है।

founding developers के छोटे समूह के लिए private beta।

Early Access प्राप्त करेंमूल्य निर्धारण देखें

क्या पहले बात करना पसंद करेंगे? founders से बात करें