پرش به مستندات
سرور MCP

به چه چیزهایی دسترسی دارد

مرز صادقانه.

نقش شما تعیین می‌کند چه ابزارهایی وجود دارند

سرور به‌جای شما عمل می‌کند، روی اتصالی که فعال کرده‌اید. هیچ حساب سرویس جداگانه‌ای در کار نیست و هیچ دسترسی‌ای فراتر از دسترسی خودتان. از وقتی نقش‌ها آمده‌اند، دسترسی‌ای فراتر از نقش شما هم در کار نیست. فهرست ابزاری که به یک کلاینت داده می‌شود از روی اجازه‌هایی ساخته می‌شود که در فضای کاری فعال دارید، پس کلاینتِ کسی که نقش Viewer دارد اصلاً sendEmail، createRule یا sendWithTemplate را فهرست نمی‌کند.

این چیزی قوی‌تر از رد کردن فراخوانی است. ابزاری که در فهرست نیست، ابزاری نیست که مدل دربارهٔ آن استدلال کند، فضای کانتکست را مصرف نمی‌کند، و نمی‌شود به نام کسی تلاشش کرد و بعد بابتش عذرخواهی کرد. همچنین یعنی کلاینتی که خالی به نظر می‌رسد معمولاً نشانهٔ اجازه‌ای است که ندارید، نه قابلیتی که این سرور ندارد، و whoAmI دقیقاً برای همین هست که این را به شما بگوید.

ثبت و فراخوانی دو دروازه‌اند و تنها دومی واقعاً نگه می‌دارد. فهرست یک‌بار ساخته می‌شود، هنگام باز شدن نشست، و setActiveConnection می‌تواند آن نشست را به صندوقی ببرد که در آن اجازهٔ کمتری دارید، پس فهرست ذاتاً کهنه است و پروتکل هیچ راهی برای پس گرفتن یک ابزار در میانهٔ نشست ندارد. بنابراین هر ابزار دروازه‌دار پیش از اجرا، نقش شما را دوباره روی اتصال فعلی حل می‌کند. ثبت، ادب است؛ فراخوانی، مرز.

یک رد کردن هر دو نیمه را نام می‌برد، مانند Refused (missing_permission): your role in this mailbox is Viewer, which does not include “Send email”، تا یک عامل بتواند آن را برای کسی که برایش کار می‌کند توضیح دهد و دست بردارد، نه اینکه خطایی مبهم را آن‌قدر دوباره امتحان کند تا کسی تسلیم شود. نقشی که یک مدیر در میانهٔ باز بودن نشست عوض کند هم به همین شکل، در همان فراخوانی بعدی، خودش را نشان می‌دهد.

نشانی‌ها محور دیگرند و هیچ‌یک از این‌ها بر آن‌ها اثر ندارد. نقش می‌گوید چه کاری مجازید بکنید؛ نشانی‌هایی که به شما داده شده می‌گویند روی کدام صندوق‌ها، و هر دو باید هم‌داستان باشند تا پیامی بیرون برود.

خودِ توکن هنوز بدون اسکوپ است

آنچه تغییر نکرده، خودِ اعطای دسترسی است. توکنی که یک برنامه می‌گیرد به هر چیزی که نقشتان اجازه می‌دهد می‌رسد، نه به زیرمجموعه‌ای که هنگام تأیید برگزیده باشید، پس تأیید یک کلاینت یعنی تأیید آن برای هر کاری که در آن فضای کاری می‌توانید بکنید. پیش از اعطای هر چیزی به شما نشان داده می‌شود چه چیزی درخواست می‌دهد، و Account → Connected apps بعداً آن را حذف می‌کند و هر توکنی را که دارد و تأیید پشتش را پاک می‌کند، اما گزینهٔ «فقط خواندنی، برای این برنامه» ساخته نشده است.

پس سقف یک کلاینت MCP همان سقف خودِ شماست. تنگ کردن کاری که یک برنامه می‌تواند بکند یعنی تنگ کردن نقش کسی که آن را وصل کرده، که کار او را در خودِ برنامه هم تنگ می‌کند. شکل صادقانهٔ امروزِ ماجرا همین است، و دلیل اینکه اسکوپ جداگانه برای هر اعطا هنوز ارزش ساختن دارد.

واژگان از پیش مشترک است: اجازه‌های یک نقش و اسکوپ‌های یک کلید API از یک الفبا برداشته می‌شوند، و همین است که اختیار یک کلید را برابر اشتراک آن دو محاسبه‌پذیر می‌کند. اسکوپ MCP برای هر اعطا هم وقتی بیاید با همان واژگان بیان خواهد شد.