Mcp
احراز هویت MCP#
کلاینت‌های MCP با همان اعتبارنامه یکپارچه‌سازی تجارت که در API HTTP به کار می‌رود احراز هویت می‌کنند. هیچ کلید MCP جداگانه، هیچ جریان OAuth و هیچ حساب هر-کلاینت وجود ندارد.
این اعتبارنامه تعیین‌کننده تجارت، کارمند، صلاحیت‌ها، شعبه‌ها و سهمیه است.
ساختن اعتبارنامه برای MCP#
- تنظیمات > یکپارچه‌سازی‌های API را باز کنید.
- یک اعتبارنامه با نام کلاینت بسازید، برای مثال
Claude Desktop. - صلاحیت‌هایی را که دستیار نیاز دارد انتخاب کنید. برای پرسش‌های عمومی تجارت، هر پنج صلاحیت خواندن را انتخاب کنید.
- کل تجارت را برگزینید، یا به شعبه‌ای که دستیار باید ببیند محدودش کنید.
- سرّ را در پیکربندی کلاینت کپی کنید.
کلاینتی که فقط باید به پرسش‌های فروش پاسخ دهد، تنها sales:read لازم دارد. اعطای همه‌چیز «برای احتیاط» دایره‌ی آنچه دستیار می‌تواند فاش کند را گسترش می‌دهد.
پیکربندی کلاینت#
| تنظیم | مقدار |
|---|---|
| URL | https://<app-host>/mcp/business |
| سرصفحه | Authorization: Bearer <token> |
| سرصفحه | Accept: application/json, text/event-stream |
| سرصفحه | Content-Type: application/json |
| سرصفحه اختیاری | X-Business-Branch: <branch-id> |
توکن را در field سرّ کلاینت یا یک متغیر محیطی نگهداری کنید. آن را در پرامپت، پیام چت یا فایل پیکربندی مشترک نچسبانید.
نگاشت صلاحیت‌ها#
| صلاحیت | ابزار | مجوز صفحه لازم |
|---|---|---|
products:read | products | inventory.products.read |
stock:read | stock | inventory.branches.read |
purchases:read | purchases | purchase.purchases.read |
orders:read | orders | sale.orders.read |
sales:read | sales | sale.sales.read |
فراخوانی ابزار زمانی شکست می‌خورد که صلاحیت روی اعتبارنامه نباشد یا نقش زنده‌ی کارمند دیگر آن صفحه را ندهد. هر دو بررسی لازم‌اند، دقیقاً مانند API HTTP.
بازبررسی زنده#
هر درخواست MCP این موارد را دوباره می‌سنجد:
- اعتبارنامه فعال است و به کاربر همان توکن تعلق دارد.
- تجارت وجود دارد و فعال است.
- کاربر هنوز عضویت کارمندی در تجارت دارد.
- کارمند هنوز مجوز صفحه‌ی پشت صلاحیت ابزار را دارد.
- شعبه درخواست‌شده داخل دامنه اعتبارنامه است.
اگر کارمند اخراج، منتقل یا تنزل یابد، فراخوانی بعدی ابزار شکست می‌خورد. فراتر از خودِ اعتبارنامه، چیزی برای لغو دستی وجود ندارد.
دامنه شعبه در گفت‌وگوها#
| دامنه اعتبارنامه | رفتار |
|---|---|
| کل تجارت | می‌تواند هر شعبه فعال را بخواند؛ برای باریک‌تر کردن branch_id می‌فرستد |
| یک شعبه اعطاشده | شعبه خودکار حل می‌شود؛ branch_id اختیاری است |
| چند شعبه اعطاشده | branch_id یا X-Business-Branch لازم است |
زیرا ممکن است دستیار درباره شعبه‌ای بپرسد که شما منظورتان نبوده، سرصفحه را روی شعبه‌ای که کلاینت باید استفاده کند، ثابت کنید. این دامنه را صریح می‌سازد و از 422 branch_required در میان یک گفت‌وگو جلوگیری می‌کند.
لغو و گردش#
| اقدام | اثر بر کلاینت MCP |
|---|---|
| گردش سرّ | کلاینت باید با سرّ تازه به‌روز شود؛ توکن کهنه از کار می‌ایستد |
| لغو | هر فراخوانی ابزار با 401 شکست می‌خورد تا اعتبارنامه تازه پیکربندی شود |
| تغییر صلاحیت | ابزارهای متأثر شکست می‌خورند؛ دیگران به کار ادامه می‌دهند |
| تغییر دامنه شعبه | فراخوانی‌های بیرون از دامنه با 403 شکست می‌خورند |
گردش‌ها را در یک پنجره نگهداری برنامه‌ریزی کنید؛ هیچ دوره بخشایشی که هر دو سرّ در آن کار کنند وجود ندارد.
رهنمودهای امنیتی#
- برای هر کلاینت هوش مصنوعی یک اعتبارنامه مستقل استفاده کنید، نه اشتراکی.
- تنها صلاحیت‌های لازم برای هدف دستیار را اعطا کنید.
- آن را به کوچک‌ترین مجموعه شعبه‌ای که معقول است محدود کنید.
- توکن را در مخزن اسرار کلاینت نگه دارید، نه در قالب پرامپت.
last_used_atو رویدادهای درخواست را منظم مرور کنید.- هنگام بازنشسته شدن یک لپ‌تاپ، کانتینر یا پروفایل کلاینت، اعتبارنامه را لغو کنید.