MCP Registry چیست و چگونه یک MCP Server معتبر پیدا کنیم؟
رجیستری رسمی MCP برای کشف Serverهای عمومی ساخته شده است، اما ثبت‌شدن در Registry به‌تنهایی تضمین امنیت نیست. سازوکار کشف، Sub-registry و چک‌لیست ارزیابی را بخوانید.
با رشد MCP، پیدا کردن Serverها به یک مسئله مستقل تبدیل شد. نام یک Server، Package، Endpoint، روش نصب و Metadata باید به‌شکل استاندارد قابل کشف باشند. رجیستری رسمی MCP برای همین نیاز ایجاد شده است.
اما Registry فهرست اعتماد نیست. وجود یک Server در Registry به این معنا نیست که برای سازمان شما امن، پایدار یا مناسب است. کشف اولین مرحله است؛ Vetting مرحله جداگانه‌ای است.
MCP Registry چیست؟
پروژه MCP در سپتامبر ۲۰۲۵ رجیستری رسمی را به‌عنوان منبع اصلی کشف Serverهای عمومی معرفی کرد. Registry و OpenAPI والد آن متن‌باز هستند و امکان ساخت Sub-registry سازگار را فراهم می‌کنند.
Registry چه مشکلی را حل می‌کند؟
- شناسه و Metadata استاندارد برای Server
- کشف Package یا روش توزیع
- کاهش فهرست‌های پراکنده و نام‌های مبهم
- امکان ساخت ابزارهای جست‌وجو و نصب
- پایه مشترک برای Sub-registryهای عمومی یا خصوصی
Registry چه چیزی را تضمین نمی‌کند؟
- امنیت کامل کد
- درست‌بودن همه Toolها
- عدم Prompt Injection
- کیفیت نگهداری یا SLA
- تناسب Scope با سازمان شما
- رعایت الزامات حریم خصوصی
- اعتماد به ناشر فقط بر اساس نام
Public و Private Sub-registry
Registry رسمی روی Serverهای عمومی تمرکز دارد. سازمان می‌تواند Sub-registry بسازد و فقط مواردی را وارد کند که معیارهای داخلی مانند ناشر مجاز، مجوز نرم‌افزار، Region، نوع Authentication یا Risk Review را پاس کرده‌اند.
تفاوت Registry با Catalog وصلک
Registry برای کشف و توزیع عمومی است. کاتالوگ وصلک یک فهرست محصولی و کنترل‌شده از کانکتورها، Toolها، وضعیت انتشار و سیاست‌های اجرایی است. یک Server عمومی می‌تواند ورودی بررسی باشد، اما نباید بدون تطبیق با مدل هویت و مجوز وصلک فعال شود.
فرآیند ارزیابی یک Server
۱. ناشر و مخزن
هویت ناشر، مخزن کد، Releaseها، Issueها و سابقه نگهداری را بررسی کنید. شباهت نام با یک برند رسمی کافی نیست.
۲. روش توزیع
Package، Container یا Remote Endpoint باید قابل ردیابی و Versioned باشد. نصب مستقیم دستور ناشناس از اینترنت برای محیط سازمانی مناسب نیست.
۳. Tool Catalog
فهرست Toolها، Schema، Read/Write بودن و Destination هر عملیات را بخوانید. Toolهای عمومی مثل execute یا request بدون Allowlist دامنه ریسک بالاتری دارند.
۴. Authentication و Authorization
روش OAuth، API Key، Token TTL، Scope و Revocation را بررسی کنید. Server باید مجوز را در سمت خودش اجرا کند.
۵. داده و حریم خصوصی
چه داده‌ای ارسال، ذخیره یا Log می‌شود؟ آیا Prompt، نتیجه Tool یا Secret در سرویس ثالث نگهداری می‌شود؟
۶. امنیت شبکه
Redirect، SSRF، TLS، Allowed Host و دسترسی به شبکه خصوصی باید مشخص باشند.
۷. عملیات نوشتنی
Confirmation، Idempotency، Dry Run و Rollback را ارزیابی کنید. Tool مخرب بدون این کنترل‌ها برای استفاده عمومی مناسب نیست.
۸. به‌روزرسانی و Supply Chain
نسخه را Pin کنید، Signature یا Digest را بررسی کنید و تغییر Toolها را قبل از Upgrade بازبینی کنید.
چک‌لیست سریع
- ناشر قابل تأیید است
- کد یا مستندات قابل بررسی است
- نسخه مشخص و قابل Pin دارد
- Toolهای عمومی و مبهم ندارد
- Scope حداقلی است
- Secret در گفتگو قرار نمی‌گیرد
- Write Action تأیید و Idempotency دارد
- Log و سیاست داده روشن است
- مسیر Update و Rollback مشخص است
Remote Server یا Local Package؟
Remote Server نگهداری ساده‌تری برای کاربر دارد، اما اعتماد بیشتری به زیرساخت ناشر می‌خواهد. Local Package کنترل بیشتری می‌دهد، ولی مسئولیت Patch، Sandbox و Secret با شماست.
برای ChatGPT چه نکته‌ای مهم است؟
OpenAI تأکید می‌کند تنها به MCP Serverهای مورد اعتماد وصل شوید. Admin Workspace باید Server و Actionها را پیش از Publish بررسی کند و تغییرات بعدی را خودکار نپذیرد.
چرا ابزارهای جدید MCP نباید خودکار فعال شوند؟
منابع رسمی
جمع‌بندی
Registry پیدا کردن Server را استاندارد می‌کند، نه اعتماد را. برای محیط سازمانی، بهترین الگو استفاده از Registry به‌عنوان منبع کشف و نگهداری یک Catalog یا Sub-registry تأییدشده با معیارهای داخلی است.
