MCP ਕਾਲਰ ਪਹਿਚਾਣ

ਜਾਣੋ ਕਿ ਤੁਹਾਡੇ MCP server ਨੂੰ ਕੌਣ ਕਾਲ ਕਰ ਰਿਹਾ ਹੈ

ਤੁਹਾਡਾ MCP server ਉਹਨਾਂ AI clients ਲਈ tools ਉਪਲਬਧ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਉੱਤੇ ਤੁਹਾਡਾ ਨਿਯੰਤਰਣ ਨਹੀਂ ਹੁੰਦਾ। Proof of Actor ਤੁਹਾਨੂੰ ਹਰ call ਦੇ ਪਿੱਛੇ ਕੀ ਹੈ, ਉਸਨੂੰ ਕਿਹੜਾ evidence ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਹਰ tool ਲਈ ਨੀਤੀਆਂ ਸੈੱਟ ਕਰਨ ਦੀ ਸਹੂਲਤ ਦਿੰਦਾ ਹੈ।

ਅਗਾਊਂ ਪਹੁੰਚ ਲਵੋ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਵੇਖੋ

ਦੁਆਰਾ Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

ਤੁਹਾਡੇ tools ਉਹਨਾਂ callers ਲਈ ਖੁੱਲ੍ਹੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਦੇਖ ਨਹੀਂ ਸਕਦੇ

ਇੱਕ MCP server ਤੁਹਾਡੇ product ਨੂੰ AI clients ਲਈ ਵਰਤਣਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ tools, resources ਅਤੇ prompts ਉਪਲਬਧ ਕਰਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਨੂੰ assistants ਅਤੇ agents ਖੋਜ ਸਕਦੇ ਹਨ ਅਤੇ call ਕਰ ਸਕਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ Model Context Protocol specification ਵਿੱਚ ਵਰਣਨ ਕੀਤੇ ਅਨੁਸਾਰ hosts, clients ਅਤੇ servers ਵਿਚਕਾਰ JSON-RPC 2.0 messages ਵਰਤ ਕੇ। ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ teams ਇਹਨਾਂ ਨੂੰ ਬਣਾਉਂਦੀਆਂ ਹਨ: ਇਹ ਤੁਹਾਡੇ product ਨੂੰ ਉਹਨਾਂ workflows ਦੇ ਅੰਦਰ ਲਿਆਉਂਦੇ ਹਨ ਜਿੱਥੇ AI agents ਪਹਿਲਾਂ ਤੋਂ ਕੰਮ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ।

ਇਸਦਾ ਮਤਲਬ ਇਹ ਵੀ ਹੈ ਕਿ ਤੁਹਾਡੇ server ਨੂੰ ਉਹਨਾਂ clients ਤੋਂ calls ਮਿਲਦੀਆਂ ਹਨ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਬਣਾਏ ਅਤੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਸਿੱਧੇ ਤੌਰ 'ਤੇ observe ਨਹੀਂ ਕਰ ਸਕਦੇ। ਇੱਕੋ tool ਨੂੰ ਲੋਕਲ ਤੌਰ 'ਤੇ test ਕਰਦਾ developer, signed-in person ਲਈ ਕੰਮ ਕਰਦਾ desktop assistant, ਰਾਤ ਭਰ ਚੱਲਣ ਵਾਲਾ autonomous agent, ਜਾਂ ਤੁਹਾਡੇ server ਦੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਪਰਖਣ ਵਾਲੀ ਕੋਈ ਚੀਜ਼ call ਕਰ ਸਕਦੀ ਹੈ। protocol ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜਾ tool call ਹੋਇਆ ਅਤੇ ਕਿਹੜੇ arguments ਨਾਲ। ਪਰ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ call ਦੇ ਪਿੱਛੇ ਕਿਸ ਕਿਸਮ ਦਾ actor ਹੈ ਜਾਂ ਤੁਹਾਨੂੰ ਉਸ 'ਤੇ ਕਿੰਨਾ trust ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

MCP server ਕਾਲਰ ਪਹਿਚਾਣ ਇਸ ਖਾਲੀ ਥਾਂ ਨੂੰ ਭਰਦੀ ਹੈ। Proof of Actor ਹਰ tool call ਵਿੱਚ ਇੱਕ evidence-backed actor result ਜੋੜਦਾ ਹੈ, ਤਾਂ ਜੋ ਤੁਹਾਡਾ server ਇਹ ਜਾਣ ਕੇ ਫੈਸਲਾ ਕਰ ਸਕੇ ਕਿ ਕਿਸਨੂੰ ਕੀ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਮੱਸਿਆ ਦੀ ਡੂੰਘੀ ਸਮਝ ਲਈ who is calling your MCP server ਪੜ੍ਹੋ, ਅਤੇ MCP servers use case ਵੇਖੋ ਕਿ teams ਇਸਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਦੀਆਂ ਹਨ।

ਸ਼ਬਦਾਂ ਬਾਰੇ ਇੱਕ ਨੋਟ। "Caller identity" ਦਾ cloud infrastructure ਵਿੱਚ ਵੀ ਇੱਕ ਜਾਣਿਆ-ਪਛਾਣਿਆ ਅਰਥ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ, AWS STS GetCallerIdentity ਉਸ IAM user ਜਾਂ role ਦੇ ਵੇਰਵੇ ਵਾਪਸ ਕਰਦਾ ਹੈ ਜਿਸਦੇ credentials ਨਾਲ operation call ਕੀਤੀ ਗਈ ਸੀ। ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ cloud credential ਨੇ call ਕੀਤੀ। ਇਸ ਪੰਨੇ ਉੱਤੇ MCP server ਕਾਲਰ ਪਹਿਚਾਣ ਇੱਕ ਵੱਖਰਾ ਸਵਾਲ ਸुलਝਾਉਂਦੀ ਹੈ: ਤੁਹਾਡੇ MCP server ਨੂੰ ਹੋ ਰਹੀ tool call ਦੇ ਪਿੱਛੇ Human, Human + AI, Agent ਜਾਂ Unknown ਵਰਗਾ ਕਿਹੜਾ actor ਹੈ, ਅਤੇ ਉਸ ਜਵਾਬ ਨੂੰ ਕਿਹੜਾ evidence support ਕਰਦਾ ਹੈ।

MCP callers ਵੱਖਰੇ ਕਿਉਂ ਹਨ

MCP callers policy ਲਈ ਮਹੱਤਵਪੂਰਨ ਤਰੀਕਿਆਂ ਵਿੱਚ browser visitors ਅਤੇ traditional API clients ਤੋਂ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ।

ਇਹ ਲਗਭਗ ਹਮੇਸ਼ਾਂ automated ਹੁੰਦੇ ਹਨ। ਸਵਾਲ "human ਜਾਂ bot?" ਤੋਂ ਘੱਟ ਅਤੇ "ਕਿਹੜਾ agent, ਕਿਵੇਂ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਕਿਹੜੇ evidence ਨਾਲ?" ਵੱਧ ਹੁੰਦਾ ਹੈ।
ਇਹ ਅਕਸਰ ਕਿਸੇ person ਦੀ ਥਾਂ ਕੰਮ ਕਰਦੇ ਹਨ। ਇੱਕ assistant ਤੁਹਾਡੇ tool ਨੂੰ ਇਸ ਲਈ call ਕਰ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ user ਨੇ ਉਸਨੂੰ ਅਜਿਹਾ ਕਰਨ ਲਈ ਕਿਹਾ ਸੀ, ਜਾਂ ਇਹ ਆਪਣੇ ਆਪ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ। ਇਹਨਾਂ ਮਾਮਲਿਆਂ ਦਾ ਇਲਾਜ ਵੱਖਰਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇਹ ਆਪਣੇ ਆਪ ਨੂੰ ਵਰਣਨ ਕਰਦੇ ਹਨ। MCP lifecycle specification ਵਿੱਚ client ਆਪਣੇ clientInfo object ਵਿੱਚ name ਅਤੇ version ਭੇਜਦਾ ਹੈ, ਆਪਣੇ initialize request ਵਿੱਚ। ਇਹ declaration ਉਪਯੋਗ context ਦਿੰਦੀ ਹੈ, ਪਰ ਇਹ proof ਨਹੀਂ ਹੈ।
Tools ਦੇ impact ਵਿੱਚ ਬਹੁਤ ਵੱਡਾ ਅੰਤਰ ਹੁੰਦਾ ਹੈ। ਇੱਕ search tool ਅਤੇ ਇੱਕ ਅਜਿਹਾ tool ਜੋ records delete ਕਰਦਾ ਹੈ, ਇੱਕੋ policy ਨਹੀਂ ਸਾਂਝਾ ਕਰਨਾ ਚਾਹੀਦਾ।

ਚੰਗੀ MCP caller ਪਹਿਚਾਣ ਨੂੰ ਇਹਨਾਂ ਚਾਰੇ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਪੈਂਦਾ ਹੈ।

Proof of Actor MCP callers ਦੀ ਪਹਿਚਾਣ ਕਿਵੇਂ ਕਰਦਾ ਹੈ

ਤੁਹਾਡੇ server ਤੋਂ signals

ਤੁਹਾਡੀ MCP integration ਹਰ call ਲਈ ਉਪਲਬਧ context Proof of Actor ਨੂੰ ਦਿੰਦੀ ਹੈ: client ਦੇ declared ਵੇਰਵੇ, transport ਅਤੇ request context, ਕੋਈ ਵੀ cryptographic request signatures ਜੋ client ਦਿੰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ RFC 9421 ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ HTTP Message Signatures, ਅਤੇ ਜੋ tool call ਹੋ ਰਿਹਾ ਹੈ। ਹਰ signal ਉੱਥੇ label ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਿੱਥੋਂ ਇਹ ਆਇਆ ਹੈ।

basis ਨਾਲ classification

Proof of Actor ਚਾਰ classes ਵਿੱਚੋਂ ਇੱਕ ਵਾਪਸ ਕਰਦਾ ਹੈ, Human, Human + AI, Agent ਜਾਂ Unknown, ਨਾਲ ਹੀ result ਲਈ basis:

verified ਜਦੋਂ ਇੱਕ cryptographic check, ਜਿਵੇਂ ਕਿ published key ਦੇ ਖਿਲਾਫ request signature, pass ਹੋ ਜਾਂਦਾ ਹੈ;
declared ਜਦੋਂ client ਜਾਂ ਤੁਹਾਡੀ application ਨੇ ਇਹ ਕਿਹਾ ਹੋਵੇ, ਜਿਵੇਂ session ਵਿੱਚ client name;
inferred ਜਦੋਂ result calls ਦੇ patterns 'ਤੇ ਆਧਾਰਿਤ ਹੋਵੇ;
unknown ਜਦੋਂ evidence determination ਨੂੰ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ।

ਇੱਕ declared client name ਨੂੰ ਕਦੇ ਵੀ verification ਵਜੋਂ ਪੇਸ਼ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ। ਜਦੋਂ evidence ਘੱਟ ਹੁੰਦਾ ਹੈ, result Unknown ਰਹਿੰਦਾ ਹੈ ਨਾ ਕਿ ਇੱਕ confident guess, ਅਤੇ ਤੁਹਾਡਾ server ਬਿਲਕੁਲ ਜਾਣਦਾ ਹੈ ਕਿ ਉਹ ਕਿਸ ਚੀਜ਼ ਨਾਲ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ।

ਇੱਕ result ਜਿਸਨੂੰ ਤੁਹਾਡੇ tools ਵਰਤ ਸਕਦੇ ਹਨ

actor result tool call ਦੇ ਨਾਲ ਆਉਂਦਾ ਹੈ, ਤੁਹਾਡੇ server ਦੀ logic ਲਈ ਤਿਆਰ। observation mode ਵਿੱਚ ਤੁਸੀਂ ਇਸਨੂੰ record ਕਰਦੇ ਹੋ। ਜਦੋਂ ਤੁਸੀਂ ਤਿਆਰ ਹੋ, ਤੁਹਾਡੀਆਂ tool-level policies ਇਸ 'ਤੇ ਕਾਰਵਾਈ ਕਰਦੀਆਂ ਹਨ।

ਤੁਹਾਡੀ 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 ਲਈ ਨੀਤੀਆਂ ਲਿਖੋ। ਆਮ 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 ਸਭ ਤੋਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਤਦ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤਿੰਨ ਸਵਾਲ ਵੱਖਰੇ ਰਹਿੰਦੇ ਹਨ:

Identity evidence: ਕਿਹੜਾ client call ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਇਹ ਕੀ ਸਾਬਤ ਕਰਦਾ ਹੈ? ਇਹ Proof of Actor ਦਿੰਦਾ ਹੈ।
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 ਕਰਦਾ ਹੈ।
Authorization: ਕੀ ਇਹ caller ਇਸ tool ਨੂੰ, ਇਹਨਾਂ arguments ਨਾਲ, ਇਸ account ਲਈ ਵਰਤ ਸਕਦਾ ਹੈ? ਇਹ ਤੁਹਾਡਾ permission model ਦਿੰਦਾ ਹੈ।

ਇੱਕ recognized client ਆਪਣੇ ਆਪ ਵਿੱਚ authorized client ਨਹੀਂ ਹੁੰਦਾ। ਇੱਕ valid signature ਇਹ ਨਹੀਂ ਦਿਖਾਉਂਦੀ ਕਿ session ਦੇ ਪਿੱਛੇ ਮੌਜੂਦ person ਨੇ ਇਸ ਖਾਸ action ਲਈ authority delegate ਕੀਤੀ ਸੀ। delegated authority ਅਤੇ agent authorization ਬਾਰੇ ਹੋਰ ਪੜ੍ਹੋ। Proof of Actor ਤੁਹਾਡੇ server ਨੂੰ ਪਹਿਲੇ ਸਵਾਲ ਲਈ ਬਿਹਤਰ context ਦਿੰਦਾ ਹੈ, ਤਾਂ ਜੋ ਦੂਜੇ ਅਤੇ ਤੀਜੇ ਲਈ ਤੁਹਾਡੇ ਜਵਾਬ ਵਧੇਰੇ ਜਾਣਕਾਰੀ-ਅਧਾਰਿਤ ਹੋਣ।

ਸਿਰਫ client name 'ਤੇ trust ਕਿਉਂ ਨਾ ਕੀਤਾ ਜਾਵੇ?

ਕਿਉਂਕਿ ਕੋਈ ਵੀ client ਕੋਈ ਵੀ name ਭੇਜ ਸਕਦਾ ਹੈ। ਇੱਕ declared name ਨੂੰ proof ਮੰਨਣਾ imitation ਨੂੰ ਸੱਦਾ ਦਿੰਦਾ ਹੈ: ਇੱਕ hostile client ਨੂੰ ਸਿਰਫ ਇੱਕ popular assistant ਦਾ name copy ਕਰਨਾ ਪੈਂਦਾ ਹੈ। Proof of Actor name ਨੂੰ declared evidence ਵਜੋਂ ਦਰਜ ਕਰਦਾ ਹੈ, ਇਸਨੂੰ ਜਿਤਨਾ ਵੀ stronger evidence ਮੌਜੂਦ ਹੋਵੇ ਉਸ ਨਾਲ ਮਿਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਨੂੰ basis ਦੱਸਦਾ ਹੈ। ਫਿਰ ਤੁਹਾਡੀ policy verified callers ਨੂੰ ਉਹਨਾਂ callers ਨਾਲੋਂ ਵੱਧ ਛੂਟ ਦੇ ਸਕਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨੇ ਸਿਰਫ ਆਪਣੇ ਆਪ ਨੂੰ declare ਕੀਤਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਕੋਈ ਵੀ ਲਾਗੂ ਨਾ ਹੋਵੇ ਤਾਂ ਆਪਣਾ Unknown fallback ਵਰਤ ਸਕਦੀ ਹੈ।

Observation mode ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੋ

ਤੁਹਾਡੇ MCP server ਵਿੱਚ Proof of Actor install ਕਰਨ ਨਾਲ ਕੋਈ ਵੀ tool ਆਪਣਾ response ਦੇਣ ਦਾ ਤਰੀਕਾ ਨਹੀਂ ਬਦਲਦਾ। Results record ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਵੇਖ ਸਕੋ ਕਿ ਤੁਹਾਡੇ tools ਨੂੰ ਕੌਣ call ਕਰਦਾ ਹੈ, evidence ਕਿੰਨਾ ਮਜ਼ਬੂਤ ਹੈ, ਅਤੇ ਨੀਤੀਆਂ ਕਿੱਥੇ ਮਦਦ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਜਦੋਂ ਤੁਹਾਨੂੰ ਭਰੋਸਾ ਹੋ ਜਾਵੇ, ਇੱਕ high-impact tool 'ਤੇ policy enable ਕਰੋ, 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 ਤਰੀਕੇ ਨਾਲ ਦਿੱਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਜੋ setup ਤੁਹਾਡੇ transport, hosting ਅਤੇ tool design ਨਾਲ ਮੇਲ ਖਾਏ। MCP Servers ਅਤੇ APIs use cases ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਇਹੀ approach ਤੁਹਾਡੇ tools ਅਤੇ ਤੁਹਾਡੀ API 'ਤੇ ਕਿਵੇਂ ਲਾਗੂ ਹੁੰਦੀ ਹੈ।

ਹਰ tool ਬਾਰੇ ਪੁੱਛਣ ਵਾਲੇ ਸਵਾਲ

Tool-level policies ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ, ਆਪਣੇ MCP server ਵੱਲੋਂ ਉਪਲਬਧ ਹਰ tool ਨੂੰ ਇੱਕ ਛੋਟੀ checklist ਨਾਲ review ਕਰਨਾ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ:

ਇਹ tool ਕੀ ਬਦਲ ਸਕਦਾ ਹੈ? Read-only tools ਅਤੇ ਉਹ tools ਜੋ data modify ਕਰਦੇ ਹਨ, messages ਭੇਜਦੇ ਹਨ ਜਾਂ billing ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ, ਵੱਖਰੇ ਇਲਾਜ ਦੇ ਹੱਕਦਾਰ ਹਨ।
ਇਹ ਕਿਸ ਲਈ ਹੈ? ਕੁਝ tools signed-in person ਦੀ ਥਾਂ 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 ਕਰੋ।
ਤੁਹਾਨੂੰ ਕਿਵੇਂ ਪਤਾ ਲੱਗੇਗਾ ਕਿ ਇਹ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ? ਕੋਈ ਵੀ ਚੀਜ਼ enforce ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ observation mode ਵਿੱਚ ਤੁਸੀਂ ਕਿਹੜੇ outcomes 'ਤੇ ਨਜ਼ਰ ਰੱਖੋਗੇ।

ਹਰ tool ਲਈ ਇਹ ਸਵਾਲ ਇੱਕ ਵਾਰ ਦੇ ਜਵਾਬ ਵਿੱਚ caller identification ਨੂੰ ਸਪੱਸ਼ਟ, testable rules ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਤੁਹਾਡੇ server ਦੇ behavior ਨੂੰ ਉਹਨਾਂ clients ਨੂੰ ਸਮਝਾਉਣਾ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ ਜੋ ਇਸ ਨਾਲ integrate ਕਰਦੇ ਹਨ।

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, ਤੁਹਾਡੇ ਵੱਲੋਂ ਉਪਲਬਧ 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 ਦੇ ਨਾਲ record ਕਰੋ ਅਤੇ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਕੋਈ policy ਨਾ ਚੁਣੋ, ਕੁਝ ਵੀ ਨਾ ਬਦਲੋ। Node.js integration guide ਪੜ੍ਹੋ

ਅਕਸਰ ਪੁੱਛੇ ਜਾਂਦੇ ਸਵਾਲ

MCP server ਨੂੰ ਕਾਲਰ ਪਹਿਚਾਣ ਦੀ ਲੋੜ ਕਿਉਂ ਹੁੰਦੀ ਹੈ?

MCP servers ਉਹਨਾਂ AI clients ਲਈ tools ਉਪਲਬਧ ਕਰਦੇ ਹਨ ਜੋ ਲੋਕਾਂ ਵੱਲੋਂ ਕਾਰਵਾਈ ਕਰਦੇ ਹਨ ਜਾਂ ਆਪਣੇ ਆਪ ਚਲਦੇ ਹਨ। tool call ਦੇ ਪਿੱਛੇ ਕਿਹੜੇ ਕਿਸਮ ਦਾ caller ਹੈ, ਇਹ ਜਾਣਨ ਨਾਲ ਤੁਸੀਂ ਘੱਟ ਪ੍ਰਭਾਵ ਵਾਲੇ tools ਨੂੰ ਖੁੱਲ੍ਹੇ ਤੌਰ 'ਤੇ allow ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਉੱਚ ਪ੍ਰਭਾਵ ਵਾਲਿਆਂ ਲਈ ਵਧੇਰੇ ਸ਼ਰਤਾਂ ਰੱਖ ਸਕਦੇ ਹੋ।

ਕੀ MCP session ਵਿੱਚ client name ਇੱਕ verification ਹੈ?

ਨਹੀਂ। client name client ਵੱਲੋਂ ਕੀਤੀ ਇੱਕ declaration ਹੁੰਦੀ ਹੈ। Proof of Actor ਇਸਨੂੰ declared evidence ਵਜੋਂ ਦਰਜ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ cryptographically verified identity ਤੋਂ ਵੱਖਰਾ ਰੱਖਦਾ ਹੈ।

ਕੀ ਕਾਲਰ ਪਹਿਚਾਣ MCP authorization ਦੀ ਥਾਂ ਲੈਂਦੀ ਹੈ?

ਨਹੀਂ। ਕਾਲਰ identity evidence, ਵਰਤਿਆ ਗਿਆ credential, ਅਤੇ caller ਕੀ ਕਰ ਸਕਦਾ ਹੈ, ਇਹ ਤਿੰਨ ਵੱਖਰੇ ਸਵਾਲ ਹਨ। Proof of Actor ਪਹਿਲੇ ਲਈ ਸੰਦਰਭ ਜੋੜਦਾ ਹੈ ਅਤੇ authorization ਤੁਹਾਡੇ server 'ਤੇ ਛੱਡ ਦਿੰਦਾ ਹੈ।

ਕੀ Proof of Actor tool calls ਨੂੰ block ਕਰੇਗਾ?

ਕੇਵਲ ਤਦ ਹੀ, ਜੇ ਤੁਹਾਡੀਆਂ ਨੀਤੀਆਂ ਇਸ ਤਰ੍ਹਾਂ ਕਹਿੰਦੀਆਂ ਹਨ। ਹਰ integration observation mode ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਤਿਆਰ ਹੋਵੋ, tool-level policies enable ਕਰਦੇ ਹੋ।

ਮੈਂ ਇਸਨੂੰ ਕਿਵੇਂ ਅਜ਼ਮਾਉਂ?

early access ਲਈ apply ਕਰੋ। ਚੁਣੀਆਂ ਗਈਆਂ founding developer teams agreed usage limits ਦੇ ਅੰਦਰ up to 12 months free ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ hands-on integration support ਵੀ ਮਿਲੇਗੀ।

ਜਾਣੋ ਤੁਹਾਡਾ app ਕੌਣ ਵਰਤ ਰਿਹਾ ਹੈ।

Founding developers ਦੇ ਇੱਕ ਛੋਟੇ group ਲਈ private beta।

ਅਗਾਊਂ ਪਹੁੰਚ ਲਵੋ ਕੀਮਤ ਵੇਖੋ

ਪਹਿਲਾਂ ਗੱਲ ਕਰਨੀ ਪਸੰਦ ਕਰੋਗੇ? founders ਨਾਲ ਗੱਲ ਕਰੋ