چرا ابزارهای جدید MCP نباید خودکار فعال شوند؟
تغییر Tool Schema یا اضافه‌شدن عملیات جدید می‌تواند سطح دسترسی یک App را عوض کند. در این راهنما مدل امن بازبینی، Diff، نسخه‌بندی، Rollout و Rollback را توضیح می‌دهیم.
اتصال یک MCP App در روز اول فقط یک تصمیم فنی نیست؛ یک تصمیم دسترسی است. اگر Server بعداً ابزار جدیدی اضافه کند یا Schema ابزار موجود را تغییر دهد، سطح توانایی App نیز ممکن است عوض شود.
فعال‌شدن خودکار تغییرات، اصل رضایت و حداقل دسترسی را نقض می‌کند. به همین دلیل کلاینت‌های سازمانی باید مجموعه Toolهای تأییدشده را Snapshot کنند و هر تغییر را قبل از انتشار دوباره نشان دهند.
چه چیزهایی ممکن است تغییر کند؟
- اضافه‌شدن یک Tool جدید
- تغییر نام یا توضیح Tool
- اضافه‌شدن پارامتر اجباری
- تغییر نوع یا دامنه یک پارامتر
- تغییر عملیات از Read به Write
- افزایش Scope یا دسترسی مقصد
- تغییر نیاز به Confirmation یا Idempotency
- تغییر رفتار بدون تغییر ظاهری Schema
چرا Tool جدید ریسک دارد؟
فرض کنید App ابتدا فقط گزارش سفارش ارائه می‌کرد و بعد ابزار Refund یا Delete اضافه می‌شود. اگر Tool جدید خودکار فعال شود، Admin بدون تصمیم جدید توانایی مالی یا مخرب را در اختیار مدل گذاشته است.
چرا تغییر Schema مهم است؟
اضافه‌شدن پارامتر اختیاری معمولاً سازگار است، اما تغییر نام فیلد، تبدیل Optional به Required یا تغییر معنای مقدار می‌تواند Tool Callهای قدیمی را خراب یا رفتار را عوض کند.
تغییر توضیح نیز می‌تواند امنیتی باشد
مدل برای انتخاب Tool به نام، توضیح و Schema تکیه می‌کند. تغییر Description ممکن است دامنه استفاده مدل را گسترده‌تر کند، حتی اگر Endpoint همان باشد. بنابراین Diff فقط نباید JSON Schema را ببیند.
مدل Snapshot و Review
- Admin نسخه تأییدشده Tool Catalog را منتشر می‌کند.
- Client از همان Snapshot استفاده می‌کند.
- Server تغییرات را ارائه می‌کند، اما خودکار اعمال نمی‌شوند.
- Admin Refresh را اجرا و Diff را می‌بیند.
- Toolهای جدید پیش‌فرض غیرفعال می‌مانند.
- پس از بازبینی، نسخه جدید برای گروه محدود یا کل Workspace منتشر می‌شود.
OpenAI چگونه این مسئله را مدیریت می‌کند؟
طبق راهنمای رسمی ChatGPT، تغییرات MCP App خودکار فعال نمی‌شوند. Admin می‌تواند Refresh کند؛ Action جدید پیش‌فرض غیرفعال است و تغییر Action موجود به‌صورت Diff نشان داده می‌شود. این رفتار از گسترش بی‌صدای دسترسی جلوگیری می‌کند.
چه چیزهایی در Diff باید دیده شود؟
- نام و شناسه Tool
- توضیح قبلی و جدید
- Schema ورودی و خروجی
- Read، Write یا Destructive بودن
- Scope و Connection موردنیاز
- Confirmation و Idempotency
- محدودیت نرخ و حجم داده
- تغییرات حذف‌شده یا Deprecated
نسخه‌بندی پیشنهادی
تغییر سازگار مانند افزودن فیلد Optional می‌تواند Minor باشد. تغییر ناسازگار در پارامتر یا معنا باید Major تلقی شود. رفتار امنیتی نباید با Patch پنهان شود.
Rollout مرحله‌ای
- تست روی سازمان یا داده آزمایشی
- فعال‌سازی برای گروه کوچک
- مقایسه Error و Audit
- گسترش به اعضای بیشتر
- انتشار کامل پس از بازبینی
- حفظ مسیر Rollback
Toolهای حذف‌شده
حذف Tool باید با دوره Deprecation و پیام روشن انجام شود. Workflowها یا Promptهای ذخیره‌شده ممکن است هنوز به آن وابسته باشند.
کنترل در وصلک
وصلک می‌تواند کاتالوگ کانکتور، وضعیت Tool و Permission اعضا را مستقل نگه دارد. اضافه‌شدن Tool در Provider نباید انتخاب‌های مدیر سازمان را بازنویسی کند. ابزار تازه ابتدا باید طبقه‌بندی و سپس طبق سیاست فعال شود.
چک‌لیست تأیید ابزار جدید
- آیا عملیات فقط خواندنی است؟
- بدترین اثر اجرای اشتباه چیست؟
- چه داده‌ای برمی‌گرداند؟
- آیا ورودی می‌تواند Destination را تغییر دهد؟
- آیا Tool نیازمند Approval است؟
- آیا تکرار درخواست امن است؟
- آیا Log کافی وجود دارد؟
- آیا Tool در سرویس مقصد نیز مجوز را بررسی می‌کند؟
- آیا مستندات و Runbook آماده‌اند؟
هنگام ناسازگاری چه رخ می‌دهد؟
اگر Snapshot کلاینت با Server سازگار نباشد، Call ممکن است خطا بدهد. خطا نباید بهانه‌ای برای فعال‌کردن خودکار نسخه جدید باشد؛ Admin باید تغییر را بازبینی کند.
منبع رسمی
Developer mode and MCP apps in ChatGPT
جمع‌بندی
به‌روزرسانی Tool Catalog همانند به‌روزرسانی یک فهرست منو نیست؛ تغییر در سطح اختیارات است.
مدل امن، تغییر را Freeze، Diff، Review و سپس Rollout می‌کند. این فرآیند شاید یک مرحله بیشتر داشته باشد، اما از گسترش ناخواسته Scope و عملیات پرریسک جلوگیری می‌کند.
