મુખ્ય સામગ્રી પર જાઓ
MCP કોલર ઓળખ

તમારા MCP સર્વરને કોણ કૉલ કરી રહ્યું છે તે જાણો

તમારો MCP server એવા AI clients માટે tools ખુલ્લા કરે છે જેને તમે નિયંત્રિત કરતા નથી. Proof of Actor તમને જણાવે છે કે દરેક કૉલ પાછળ શું છે, કયો પુરાવો તેને આધાર આપે છે, અને તમને દરેક tool માટે policies નક્કી કરવા દે છે.

પ્રારંભિક ઍક્સેસ મેળવોતે કેવી રીતે કાર્ય કરે છે તે અન્વેષણ કરો
Toshendra Sharma

દ્વારા Toshendra Sharmaસ્થાપક અને CEO, AgentCredia · Updated November 13, 2026

તમારા tools એવા callers માટે ખુલ્લા છે જેને તમે જોઈ શકતા નથી

મ MCP server તમારા productને AI clients માટે ઉપયોગી બનાવે છે. તે એવા tools, resources અને prompts ખુલ્લા કરે છે જેને assistants અને agents શોધી અને કૉલ કરી શકે છે, અને જે Model Context Protocol specificationમાં વર્ણવ્યા મુજબ hosts, clients અને servers વચ્ચે JSON-RPC 2.0 messagesનો ઉપયોગ કરે છે. ટીમો તેમને આ જ કારણસર બનાવે છે: તેઓ તમારા productને તે workflowsમાં મૂકે છે જ્યાં AI agents પહેલેથી જ કામ કરી રહ્યા છે.

આનો અર્થ એ પણ થાય છે કે તમારા serverને એવા clients તરફથી calls મળે છે જેને તમે બનાવ્યા નથી અને સીધા જોઈ શકતા નથી. એક જ tool local રીતે પરીક્ષણ કરતા developer, sign-in કરેલા વ્યક્તિની તરફથી કાર્ય કરતી desktop assistant, રાત્રભર લાંબું task ચલાવતો autonomous agent, અથવા તમારા serverની કમજોરીઓ શોધતો કંઈક દ્વારા invoke થઈ શકે છે. protocol તમને કયો tool called થયો અને કયા arguments સાથે, તે જણાવે છે. તે પોતે જ તમને call પાછળ કયા પ્રકારનો actor છે અથવા તેને કેટલો trust કરવો જોઈએ તે જણાવતું નથી.

MCP server caller identification આ ખોટ પૂરે છે. Proof of Actor દરેક tool callમાં evidence-backed actor result ઉમેરે છે, જેથી તમારો server કોને શું આપવું તે વિશે જાણકારીપૂર્વક નિર્ણય લઈ શકે. સમસ્યાની વધુ ઊંડાણથી સમજ માટે તમારા MCP serverને કોણ કૉલ કરી રહ્યું છે વાંચો, અને teams તેને કેવી રીતે લાગુ કરે છે તે માટે MCP servers use case જુઓ.

terms વિશે નોંધ. "Caller identity"નો cloud infrastructureમાં પણ સુસ્થાપિત અર્થ છે. ઉદાહરણ તરીકે AWS STS GetCallerIdentity operation કૉલ કરવા માટે જે IAM user અથવા roleનાં credentials વપરાયાં છે તેની વિગતો આપે છે. તે કયો cloud credential call કરી રહ્યો છે તે જવાબ આપે છે. આ પૃષ્ઠ上的 MCP server caller identification એક અલગ પ્રશ્નનો જવાબ આપે છે: તમારા MCP server પર tool call પાછળ Human, Human + AI, Agent અથવા Unknownમાંથી કયો પ્રકારનો actor છે, અને તે જવાબને કયો પુરાવો આધાર આપે છે.

MCP callers કેમ અલગ છે

MCP callers policy માટે મહત્વ ધરાવતી રીતે browser visitors અને પરંપરાગત API clientsથી અલગ છે.

  • તેઓ લગભગ હંમેશા automated હોય છે. પ્રશ્ન "human કે bot?"થી ઓછો અને "કયો agent, કેવી રીતે કાર્યરત, કયા પુરાવા સાથે?" વધુ છે.
  • તેઓ ઘણી વખત વ્યક્તિની તરફથી કાર્ય કરે છે. assistant તમારી toolને userએ કહ્યાથી call કરી શકે છે, અથવા સ્વાયત્ત રીતે કાર્ય કરી શકે છે. આ કેસોને અલગ રીતે treat કરવું જોઈએ.
  • તેઓ પોતાનું વર્ણન કરે છે. MCP lifecycle specificationમાં client clientInfo objectને નામ અને version સાથે તેના initialize requestમાં મોકલે છે. તે declaration ઉપયોગી સંદર્ભ છે, પરંતુ તે proof નથી.
  • Toolsની અસર બહુ અલગ હોઈ શકે છે. search tool અને records delete કરતો tool એક જ policy શેર ન કરવી જોઈએ.

સારો MCP caller identification આ ચારેય બાબતોનું ધ્યાન રાખે છે.

Proof of Actor MCP callersને કેવી રીતે ઓળખે છે

તમારા serverમાંથી signals

તમારી MCP integration દરેક call માટે ઉપલબ્ધ context Proof of Actorને આપે છે: clientની declared વિગતો, transport અને request context, client દ્વારા પૂરા પાડવામાં આવેલી કોઈપણ cryptographic request signatures, જેમ કે RFC 9421માં વ્યાખ્યાયિત HTTP Message Signatures, અને જે tool call થઈ રહ્યો છે તે. દરેક signalને તે ક્યાંથી આવ્યું છે તે મુજબ label કરવામાં આવે છે.

આધાર સાથે classification

Proof of Actor ચાર classesમાંથી એક આપે છે, Human, Human + AI, Agent અથવા Unknown, સાથે પરિણામનો આધાર:

  • verified જ્યારે cryptographic check, જેમ કે published key સામે request signature, pass થાય;
  • declared જ્યારે client અથવા તમારી applicationએ તે જણાવ્યું હોય, જેમ કે sessionમાં client name;
  • inferred જ્યારે પરિણામ callsની pattern પર આધારિત હોય;
  • unknown જ્યારે પુરાવો નિર્ણયને સમર્થન ન આપતો હોય.

Declared client name ક્યારેય verification તરીકે રજૂ કરવામાં આવતો નથી. જ્યારે પુરાવો નબળો હોય, ત્યારે result Unknown રહે છે, confident guess નથી, અને તમારો 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 કરે છે, કેટલી વાર, કયા પુરાવા સાથે, અને તે સમય સાથે કેવી રીતે બદલાય છે તે જુઓ. એવા tools ઓળખો જે મુખ્યત્વે Unknown callersને આકર્ષે છે, એવા clients જે behaviour બદલે છે, અને verifiable identity ધરાવતા callsનો હિસ્સો જુઓ.

Route

દરેક tool અને દરેક risk tier માટે policies લખો. સામાન્ય patterns:

  • Low-impact tools જેમ કે search અથવા read-only lookups: standard rate limit સાથે વ્યાપક રીતે allow કરો.
  • Moderate-impact tools જેમ કે drafts બનાવવું: verified અને declared callersને allow કરો, Unknownને rate-limit કરો.
  • High-impact tools જેમ કે data delete કરવું, settings બદલવી અથવા userની તરફથી messages મોકલવા: તમારી સૌથી મજબૂત authorizationની જરૂર રાખો, અને જ્યાં caller Unknown હોય અથવા સ્વાયત્ત રીતે કાર્ય કરી રહ્યો હોય ત્યાં confirmation અથવા review ઉમેરો.

protecting sensitive actions without blocking agents માર્ગદર્શિકા બતાવે છે કે આ 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 નથી. valid signature બતાવતું નથી કે session પાછળના વ્યક્તિએ ખાસ આ action માટે authority સોંપી હતી. delegated authority અને agent authorization વિશે વધુ વાંચો. Proof of Actor પહેલા પ્રશ્ન માટે તમારા serverને વધુ સારો સંદર્ભ આપે છે જેથી બીજા અને ત્રીજા પ્રશ્નના જવાબ વધુ જાણકારીપૂર્વક આપી શકાય.

ફક્ત client નામ પર વિશ્વાસ કેમ ન કરવો?

કારણ કે કોઈપણ client કોઈપણ નામ મોકલી શકે છે. declared nameને proof તરીકે માનવું imitationને આમંત્રણ આપે છે: hostile clientને ફક્ત popular assistantનું નામ નકલ કરવું પડે. Proof of Actor નામને declared evidence તરીકે નોંધે છે, તેને ઉપલબ્ધ વધુ મજબૂત પુરાવા સાથે જોડે છે, અને તમને આધાર જણાવે છે. પછી તમારો policy verified callersને ફક્ત પોતે declare કરનારા callers કરતાં વધુ છૂટ આપી શકે છે, અને જ્યારે બંનેમાંથી કંઈ લાગુ ન પડે ત્યારે તમારી Unknown fallback લાગુ કરી શકે છે.

Observation modeથી શરૂઆત કરો

તમારા MCP serverમાં Proof of Actor install કરવાથી કોઈ tool કેવી રીતે respond કરે છે તે બદલાતું નથી. results record થાય છે જેથી તમે જોઈ શકો કે તમારા toolsને કોણ call કરે છે, પુરાવો કેટલો મજબૂત છે, અને કયા સ્થાનોએ policies મદદરૂપ થશે. જ્યારે તમે વિશ્વાસ અનુભવો, ત્યારે એક high-impact tool પર policy enable કરો, outcomes જુઓ, અને પછી વિસ્તાર કરો. How It Works સમગ્ર flow આવરી લે છે, અને Detection & Limitations સમજાવે છે કે દરેક પ્રકારનો પુરાવો શું સ્થાપિત કરી શકે છે અને શું નહીં.

MCP servers અને APIs ચલાવતી teams માટે બનાવેલું

Proof of Actor તમારા existing authentication, rate limiting અને logging સાથે તમારા serverની અંદર કામ કરે છે. integrations દરેક founding team સાથે hands-on રીતે આપવામાં આવે છે, જેથી setup તમારા transport, hosting અને tool design સાથે સુસંગત રહે. MCP Servers અને APIs use cases બતાવે છે કે એ જ approach તમારા tools અને તમારા APIમાં કેવી રીતે લાગુ પડે છે.

તમે ખુલ્લા કરેલા દરેક tool વિશે પૂછવાના પ્રશ્નો

tool-level policies લખતાં પહેલાં, તમારા MCP server ખુલ્લા કરેલા દરેક toolને ટૂંકી checklist સાથે સમીક્ષવું ઉપયોગી છે:

  • આ tool શું બદલી શકે છે? read-only tools અને data modify કરનારા, messages મોકલનારા અથવા billingને અસર કરનારા tools અલગ treatmentના હકદાર છે.
  • આ કોના માટે છે? કેટલાક tools sign-in કરેલા વ્યક્તિની તરફથી કાર્ય કરતી assistants માટે હોય છે; અન્ય autonomous workflows માટે. અપેક્ષિત caller યોગ્ય policy ઘડે છે.
  • ભૂલનો ખર્ચ કેટલો પડશે? ખોટું search result સસ્તું પડે છે. ખોટું deletion નહીં. દરેક toolને risk tierમાં map કરો.
  • કયો પુરાવો જરૂરી હોવો જોઈએ? નક્કી કરો કે declared client પૂરતો છે કે toolને verified identity સાથે તમારી સૌથી મજબૂત authorizationની જરૂર છે.
  • Unknown પર શું થશે? દરેક tool માટે explicit fallback પસંદ કરો: allow, rate-limit, userને confirm કરવા પૂછો, અથવા review માટે route કરો.
  • તે કામ કરે છે તે તમને કેવી રીતે ખબર પડશે? તમે કંઈ enforce કરો તે પહેલાં observation modeમાં કયા outcomes જોશો તે નક્કી કરો.

દરેક tool માટે આ પ્રશ્નોના જવાબ caller identificationને સ્પષ્ટ, testable rulesમાં ફેરવે છે, અને તમારા serverનું behaviour તેની સાથે 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 ચલાવો છો અને જાણવું છે કે તેને કોણ કૉલ કરી રહ્યું છે, તો early access માટે અરજી કરો. અમને તમારા server, તમે ખુલ્લા કરતા 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
પરિણામ પાછળના signals, જેથી તમારી team કારણ જોઈ શકે.

observation mode માં શરૂ કરો: પરિણામોને તમારા logsની બાજુમાં નોંધો અને તમે policy પસંદ કરો ત્યાં સુધી કંઈ બદલશો નહીં. Node.js integration guide વાંચો

વારંવાર પૂછાતા પ્રશ્નો

MCP serverને caller identificationની જરૂર શા માટે પડે છે?

MCP servers એવા AI clients માટે tools ખુલ્લા કરે છે જે લોકોની તરફથી કાર્ય કરે છે અથવા સ્વાયત્ત રીતે ચાલે છે. tool call પાછળ કયો પ્રકારનો caller છે તે જાણવાથી તમે ઓછા અસરવાળા tools મુક્તપણે મંજૂર કરી શકો છો અને વધુ અસરવાળા tools માટે વધુ કડક શરતો રાખી શકો છો.

MCP sessionમાં client નામ શું verification ગણાય?

ના. client નામ client દ્વારા કરાયેલી declaration છે. Proof of Actor તેને declared evidence તરીકે નોંધે છે અને તેને cryptographically verified identityથી અલગ રાખે છે.

શું caller identification MCP authorizationને બદલે છે?

ના. caller identity evidence, call માટે વપરાયેલ credential, અને callerને શું કરવાની મંજૂરી છે તે અલગ પ્રશ્નો છે. Proof of Actor પહેલા માટે સંદર્ભ ઉમેરે છે અને authorization તમારા server પર છોડી દે છે.

શું Proof of Actor tool callsને block કરશે?

ફક્ત તમારી policies એવું કહે ત્યારે જ. દરેક integration observation modeમાં શરૂ થાય છે, અને તમે તૈયાર હો ત્યારે tool-level policies ચાલુ કરો છો.

હું તેને કેવી રીતે અજમાવી શકું?

early access માટે અરજી કરો. પસંદ કરાયેલ founding developer teamsને સહમતિ મુજબના usage limitsની અંદર up to 12 months free મળી શકે છે, સાથે hands-on integration support પણ મળશે.

તમારા app નો ઉપયોગ કોણ કરે છે તે જાણો.

Founding developers ના નાના સમૂહ માટે private beta.

પ્રારંભિક ઍક્સેસ મેળવોકિંમત જુઓ

પહેલાં વાત કરવી પસંદ કરો છો? સ્થાપકો સાથે વાત કરો