سرورهای متمرکز MCP راهکار نهایی برای رفع سردرگمی عامل‌های هوش مصنوعی

تصور کنید یک برنامه‌نویس برای اتوماسیون شرکتش، تمام ۳۰۰ نقطه اتصال (Endpoint) یک API قدیمی را به یک عامل هوش مصنوعی می‌دهد؛ نتیجه‌ای که می‌گیرد نه یک دستیار هوشمند، بلکه مدلی است که بیشتر از آنکه مسئله را حل کند، در انتخاب ابزار درست سردرگم می‌شود. در حالی که یک تیم بک‌اند، یک API عظیم با ۳۰۰ نقطه اتصال را به عنوان یک محصول کامل می‌بیند، یک کلاینت هوش مصنوعی تنها لیستی دلهره‌آور از نام ابزارها، توصیفات و طرحواره‌های ورودی (Input Schemas) را مشاهده می‌کند. تبدیل مستقیم چنین API به یک سرور پروتکل زمینهٔ مدل (MCP)، آن را به جای یک دارایی، به یک بدهی تبدیل می‌کند؛ زیرا گزینه‌های بیش از حد، مدل را مجبور می‌کند تا تلاش بیشتری برای انتخاب ابزار صرف کند تا برای حل درخواست کاربر.

این تضاد طراحی، یعنی تبدیل مستقیم یک API حجیم به یک سرور MCP — شبیه به دادن یک دفترچه تلفن ۱۰ هزار صفحه‌ای به کسی که فقط می‌خواهد شمارهٔ یک pizzaria را پیدا کند — اکنون به یکی از بزرگ‌ترین گلوگاه‌های توسعه تبدیل شده است. طبق گزارش‌های منتشر شده در ۱۳ سپتامبر ۲۰۲۶، بسیاری از سازمان‌ها هنگام تلاش برای پل زدن میان APIهای قدیمی REST و چارچوب‌های عامل‌محور (Agentic Frameworks) با این مشکل مواجه شدند. مشکل اصلی این است که APIها بر اساس تاریخچه محصول رشد می‌کنند؛ آن‌ها مسیرهای قدیمی برای سازگاری با نسخه‌های پیشین، مسیرهای مخصوص مدیران (Admin-only)، مسیرهای عیب‌یابی داخلی و نقاط اتصالی که برای صفحات خاص فرانت‌اند ایجاد شده‌اند را در خود جای می‌دهند. این امر یک رابط «پُر نویز» برای مدل‌های زبانی بزرگ (LLM) ایجاد می‌کند.

یک عامل پشتیبانی را تصور کنید که از یک ابزار هوش مصنوعی استفاده می‌کند. اگر سرور به‌طور هم‌زمان ابزارهای get_customer ،get_customer_by_id ،fetch_customer ،list_customers ،search_customers ،admin_get_customer ،get_customer_summary و get_customer_details را اکسپوز کند، مدل باید حدس بزند کدام‌یک ایمن‌تر است، کدام‌یک فیلدهای درست را برمی‌گرداند و کدام‌یک با قصد کاربر مطابقت دارد. این ابهام منجر به فراخوانی‌های اشتباه، افزایش نرخ تلاش مجدد (Retry Rates)، کندی زمان پاسخ‌دهی و دشوارتر شدن فرآیند عیب‌یابی می‌شود.

گروه‌بندی بر اساس گردش‌کار کاربر

به نقل از راهنمای منتشر شده در dev.to، اولین گام برای کاهش نویز ابزارها، تغییر دیدگاه از «محورِ نقطه اتصال» به «محورِ گردش‌کار» است. توسعه‌دهندگان نباید بپرسند «چه APIهایی داریم؟»، بلکه باید بپرسند «این سرور MCP قرار است با کدام وظیفه کاربر کمک کند؟»

برای یک محصول SaaS، این یعنی تقسیم یک سرور غول‌پیکر به سطوح متمرکز بر اساس گروه‌های گردش‌کار خاص:

• سرور MCP پشتیبانی: متمرکز بر بافت پشتیبانی مشتری. ابزارها شامل get_customer ،list_customer_tickets ،get_ticket و list_customer_subscriptions است.
• سرور MCP صورت‌حساب: متمرکز بر صورت‌حساب و جست‌وجوی فاکتورها. ابزارها شامل list_customer_invoices ،get_invoice و get_subscription است.
• سرور MCP مدیریت: متمرکز بر مدیریت فضای کاری. ابزارها شامل get_workspace_settings و update_workspace_setting است.
• سایر گروه‌های احتمالی: تحقیق حساب‌های فروش، به‌روزرسانی‌های مدیریت پروژه، گزارش‌های تحلیلی و عملیات توسعه‌دهندگان (DevOps).

این جداسازی تضمین می‌کند که یک عامل پشتیبانی به‌طور تصادفی ابزارهای پرخطر مدیریتی مثل rotate_api_key ،delete_customer ،create_invoice_adjustment ،update_workspace_permissions یا run_internal_report را مشاهده یا فعال نکند.

هرس کردن و پالایش مجموعه ابزارها

هر نقطه اتصالی نباید به یک ابزار تبدیل شود. بسیاری از آن‌ها صرفاً برای نیازهای فرانت‌اند یا اصلاحات داده‌های خام (Raw Data Patches) وجود دارند که با قصد طبیعی کاربر همخوانی ندارند. ابزارهای ضعیف MCP اغلب به جزئیات پیاده‌سازی اشاره دارند، مثلاً «فراخوانی نقطه اتصال v2»، «اصلاح شیء (Patch object)»، «اجرای اقدام مدیریتی»، «ارسال بدنه داده‌های عمومی» یا «دریافت پیکربندی خام».

اگر توسعه‌دهنده نتواند یک درخواست کاربرِ شفاف بنویسد که منجر به اجرای آن ابزار شود — مثلاً «تیکت‌های باز این مشتری را پیدا کن» یا «فعالیت‌های اخیر حساب را خلاصه کن» — آن نقطه اتصال باید حذف شود.

هم‌پوشانی نقاط اتصال نیز یک تله رایج است. APIهای بزرگ اغلب چندین مسیر برای یک داده دارند، مانند:

• GET /customers/{id}
• GET /customers/{customer_id}/profile
• GET /crm/customers/{id}
• GET /support/customers/{id}

ارائه هر چهار مورد، ابزارهای گیج‌کننده‌ای مثل get_customer ،get_customer_profile ،get_crm_customer و get_support_customer ایجاد می‌کند. توسعه‌دهنده باید تنها موردی را ارائه دهد که شکلی از داده‌ها را برمی‌گرداند که برای آن گردش‌کار خاص مرتبط‌تر است. اگر دو ابزار باید باقی بمانند، باید بر اساس هدف قابل مشاهده برای کاربر نام‌گذاری شوند، مثلاً get_customer_support_profile و get_customer_sales_profile؛ به جای اینکه مدل را مجبور کنند تفاوت بین «crm» و «support» را حدس بزند.

مدیریت پیچیدگی طرحواره (Schema)

بیش‌باریِ ابزارها فقط به تعداد آن‌ها مربوط نیست، بلکه به پیچیدگی ورودی‌های آن‌هاست. کلاینت‌های هوش مصنوعی با ابزارهایی که موارد زیر را می‌پذیرند، دچار مشکل می‌شوند:

• بلوک‌های JSON دلخواه (Arbitrary JSON blobs)
• تعداد زیادی فیلد اختیاری غیرمرتبط
• اشیاء فیلتر گسترده
• رشته‌های پرس‌وجوی خام (Raw query strings)
• بدنه‌های داده‌های عمومی (Generic payloads)
• فیلدهایی که معنای آن‌ها به یک فیلد پنهان دیگر وابسته است

برای حل این مشکل، راهنما پیشنهاد می‌کند یک ابزار جامع مثل update_customer به ابزارهای کوچک‌تر و مبتنی بر قصد (Intent-based) تقسیم شود:

• update_customer_billing_email
• update_customer_support_status
• update_customer_account_owner

این ابزارهای کوچک‌تر راحت‌تر توصیف، تست و با مجوزهای خاص ایمن می‌شوند. قانون کلی این است: هرگاه اقدامات دارای مجوزها، اثرات جانبی یا قصدهای متفاوتی هستند، ابزار را تقسیم کنید.

امنیت و رویکرد لیست سفید (Allowlist)

عملیات حساس هرگز نباید با سرورهای عمومی ترکیب شوند. این موارد شامل حذف داده‌ها، به‌روزرسانی‌های دسته‌جمعی، خروجی گرفتن (Export)، تغییرات صورت‌حساب، تغییر مجوزها، ایجاد کلید API، مدیریت کلاینت‌های OAuth، لغو حساب، جعل هویت مدیر (Admin Impersonation)، وظایف نگهداری داخلی و ارسال اعلان‌ها است. این لایه از دسترسی، در واقع مرز امنیتی جدیدی را در پروتکل MCP تعریف می‌کند که مدیریت صحیح آن برای جلوگیری از حملاتی مانند تزریق پرامپت ضروری است.

برای این ابزارهای حساس، توسعه‌دهندگان باید موارد زیر را تعریف کنند:

• چه کسی می‌تواند ابزار را فراخوانی کند و کدام محدوده اعتبارنامه (Credential Scope) مورد نیاز است.
• آیا مرحله تأیید لازم است و کدام رکوردها می‌توانند تغییر کنند.
• آیا اقدام قابل بازگشت است و چگونه در لاگ‌ها ظاهر می‌شود.
• چگونه فراخوانی‌های غیرمجاز تست شوند و اشتباهات چگونه بازگردانی (Rollback) شوند.

برای جلوگیری از «نشت» (Leakage) — جایی که نقاط اتصال جدید API به‌طور خودکار اکسپوز می‌شوند — توصیه می‌شود از «لیست سفید» به جای «لیست سیاه» استفاده شود. لیست سیاه ریسکی است زیرا نقاط اتصال جدید ممکن است به‌طور پیش‌فرض وارد سطح دسترسی شوند. یک لیست سفید صراحتاً عملیات اکسپوز شده را تعریف می‌کند، مانند:

• support_context: GET /v1/customers/{customer_id} ،GET /v1/tickets ،GET /v1/tickets/{ticket_id} ،POST /v1/tickets/{ticket_id}/notes
• billing_lookup: GET /v1/invoices ،GET /v1/invoices/{invoice_id} ،GET /v1/subscriptions/{subscription_id}
• admin_controls: GET /v1/workspaces/{workspace_id}/settings ،PATCH /v1/workspaces/{workspace_id}/settings

تست انتخاب ابزار

تست تک‌تک ابزارها برای مجموعه‌های بزرگ کافی نیست. توسعه‌دهندگان باید «انتخاب ابزار» را با استفاده از پرامپت‌هایی که کاربران واقعی را شبیه‌سازی می‌کنند، تست کنند، مانند:

• «تیکت‌های باز برای مشتری cus_123 را پیدا کن.»
• «آخرین فاکتور پرداخت‌نشده برای مشتری cus_123 را نشان بده.»
• «تیکت tick_456 را به وضعیت حل‌شده تغییر بده.»
• «آیا می‌توانی این مشتری را حذف کنی؟»

هنگام تست، بررسی کنید که آیا کلاینت ابزارهای مشابه را با هم اشتباه می‌گیرد، برای IDهای گم‌شده درخواست می‌کند یا از اقدامات پرخطر بدون تأیید اجتناب می‌کند. لاگ‌های سرور باید برای بررسی نام ابزار، وضعیت، تأخیر (Latency) و اندازه پاسخ بازبینی شوند. اگر عامل به‌طور مداوم ابزار اشتباه را انتخاب می‌کند، راهکار در مهندسی پرامپت نیست، بلکه در کاهش تعداد ابزارها، تغییر نام آن‌ها یا بهبود توصیفات است.

توصیفات باید صریح باشند. یک توصیف بد مانند «دریافت مشتری» باید با این عبارت جایگزین شود: «پروفایل پشتیبانی یک مشتری را با استفاده از ID مشتری دریافت می‌کند. قبل از بررسی تیکت‌ها یا وضعیت اشتراک از این ابزار استفاده کنید». به همین ترتیب، «به‌روزرسانی تیکت» باید به «تغییر وضعیت یک تیکت پشتیبانی پس از تأیید وضعیت جدید توسط کاربر» تبدیل شود. توصیفات باید به این پاسخ دهند که چه زمانی از ابزار استفاده شود، چه ورودی لازم است، چه چیزی برمی‌گرداند و آیا اثرات جانبی دارد یا خیر.

ساده‌سازی با 0mcp

ابزارهایی مثل 0mcp این فرآیند را تسهیل می‌کنند و به تیم‌ها اجازه می‌دهند تعاریف Swagger، OpenAPI یا Postman را وارد کرده و به‌صورت گزینشی انتخاب کنند کدام توابع به قابلیت‌های MCP تبدیل شوند. این مرحله انتخاب حیاتی است؛ هدف انتشار هر مسیری نیست، بلکه انتخاب عملیات مفید و پالایش نام‌ها و توصیفات آن‌هاست.

0mcp در حال حاضر از سرورهای HTTP میزبانی‌شده (Hosted Streamable) پشتیبانی می‌کند و نه سرورهای محلی stdio. برای بهینه‌سازی این زیرساخت، استفاده از پراکسی‌های Smart MCP می‌تواند با مکانیزم Hot-Swap، نیاز به ری‌استارت مداوم عامل‌ها هنگام تغییر ابزارها را حذف کند. احراز هویت API موجود همچنان از طریق API Key، Bearer token یا OAuth pass-through استفاده می‌شود.

این تفکیک معماری تضمین می‌کند که در حالی که سرور MCP رابط را فراهم می‌کند، API اصلی همچنان مالک منطق تجاری، مجوزها، مرزهای مستاجر (Tenant Boundaries)، صفحه‌بندی (Pagination)، محدودیت‌های نرخ (Rate Limits) و منطق اعتبارسنجی باقی بماند. یک گردش‌کار MCP میزبانی‌شده، فرآیند انتخاب، میزبانی، تست، لاگ‌ها، تحلیل‌ها و مدیریت نسخه را بدون جایگزینی مدل مجوزهای اصلی محصول، آسان‌تر می‌کند.

گام بعدی شما

• اگر سرور MCP دارید، لیست ابزارهای خود را بررسی کنید و هر ابزاری که نام فنی دارد (مثلاً شامل کلمه Patch یا v2 است) را حذف یا بازنویسی کنید.
• ابزارهای جامع (Generic) را به ابزارهای هدفمند (Intent-based) تقسیم کنید تا نرخ خطای استنتاج کاهش یابد.
• برای هر ابزار، یک توصیف دو جمله‌ای بنویسید که دقیقاً بگوید «چه زمانی» و «چرا» باید از آن استفاده شود.

اما مدیریت این ابزارها در مقیاس سازمانی چالش‌های امنیتی جدیدی ایجاد می‌کند — به تحلیل ما درباره‌ی حفاظ‌های (Guardrails) لایه استنتاج مراجعه کنید.