MCP vs. API Gateways: They’re Not Interchangeable

MCP در برابر API Gatewayها: آن‌ها قابل جایگزینی با یکدیگر نیستند

Christian Posta — 2025-10-20T15:00:02+00:00

تفاوت‌های بنیادین و اینکه چرا یک دروازه (Gateway) تخصصی MCP برای امنیت، مسیریابی و قابلیت مشاهده (Observability) ضروری است را کشف کنید.

MCP در برابر API Gatewayها: آن‌ها قابل جایگزینی با یکدیگر نیستند

Featued image for: MCP vs. API Gateways: They’re Not Interchangeable

APIها بدون حالت (Stateless) هستند، اما MCP دارای حالت (Stateful) است

  • متد (GET، POST، PUT، DELETE)
  • مسیر (/users/123/orders)
  • هدرها (Authorization: Bearer xyz، Content-Type)
  • پارامترهای کوئری (?limit=10&offset=50)
  • قابلیت‌های پروتکل که بین کلاینت و سرور توافق می‌شوند (اینکه کدام ویژگی‌های اختیاری در دسترس هستند).
  • نتیجه ابزار / زمینه (Context) حاصل از فراخوانی‌ها و پاسخ‌های قبلی ابزار.
  • وضعیت فراخوانی ناهمگام ابزار؛ به‌روزرسانی‌ها / اعلان‌های جریانی (Streaming).
  • وضعیت مربوط به اطلاعات درخواست‌شده از سرور توسط کلاینت.
    POST /mcp
Mcp-Session-Id: session_abc123
Content-Type: application/json

{
  "jsonrpc": "2.0", 
  "method": "tools/call",
  "params": { 
    "name": "database_query",
    "arguments": { /* complex nested structure */ }
  },
  "id": "call_456"
}

آیا می‌توانید از API Gateway خود به عنوان یک MCP Gateway استفاده کنید؟

  • تجزیه بدنه درخواست و پاسخ‌ها (JSON-RPC)، و پیاده‌سازی معناشناسی پروتکل.
  • اعمال تصمیمات خط‌مشی (اجازه/عدم اجازه) روی بخش‌هایی از بدنه (فهرست ابزارها، فراخوانی ابزارها، درخواست‌های منبع و غیره).
  • یک درخواست HTTP POST واحد از سوی یک کلاینت MCP می‌تواند به چندین پاسخ منجر شود که به صورت جریانی (SSE) بازگردانده می‌شوند.
  • نیاز به روشی برای اعمال اجرای خط‌مشی در داخل جریان (Stream).
  • هنگامی که جریان برقرار شد، پروکسی کردن درخواست‌ها از سرور MCP به کلاینت MCP.
  • میانجی‌گری تفاوت‌های بین کلاینت‌های MCP و سرورهای MCP.
  • ارائه یک سرور MCP منطقی واحد به یک کلاینت MCP (سرور MCP مجازی)، که ممکن است در سمت بک‌اند شامل چندین سرور MCP باشد.
  • پروکسی عبور ساده (Passthrough)
  • درک جزئی از پروتکل
  • میانجی‌گری MCP
  • چندپخشی (Multiplexing) در MCP

پروکسی عبور ساده

چه مواردی به خوبی کار می‌کنند:

  • احراز هویت در سطح HTTP (کلیدهای API، توکن‌های OAuth)
  • محدودسازی نرخ (Rate Limiting) پایه به ازای هر کلاینت یا IP
  • خاتمه لایه امنیت انتقال (TLS) و مدیریت گواهی‌نامه‌ها
  • ثبت وقایع (Logging) و معیارهای درخواست/پاسخ

محدودیت‌های Gateway در مواجهه با SSE:

  • عدم اجرای خط‌مشی جریانی: دروازه نمی‌تواند رویدادهای منفرد SSE را بررسی یا فیلتر کند.
  • قابلیت مشاهده محدود: عدم امکان ردیابی پیشرفت، تشخیص خطاها یا سنجش تاخیر (Latency) به ازای هر رویداد.
  • نبود مجوزدهی میان‌جریانی: عدم امکان لغو دسترسی یا اعمال خط‌مشی‌ها همزمان با پیشروی جریان.
  • از دست رفتن زمینه نشست (Session): چندین رویداد SSE بخشی از یک عملیات منطقی MCP هستند، اما دروازه آن‌ها را به عنوان تکه‌های مستقل می‌بیند.

پشتیبانی جزئی از پروتکل

چه مواردی امکان‌پذیر می‌شود:

  • درک بهتر درخواست‌های JSON-RPC.
  • اعمال مجوزدهی در سطح ابزار («کاربران بازاریابی نمی‌توانند database_query را فراخوانی کنند»).
  • تبدیل و اعتبارسنجی اولیه درخواست‌ها.
  • پیچیدگی تجزیه پویا: فهرست ابزارهای MCP دارای طول‌های دلخواهی هستند. عبارات JSONPath شما به طور فزاینده‌ای پیچیده و شکننده می‌شوند.
  • سربار عملکرد: سیاست‌های جاوا اسکریپت کندتر از سیاست‌های بومی درگاه (gateway) هستند.
  • بار نگهداری: هر ابزار جدید MCP ممکن است نیازمند به‌روزرسانی سیاست‌های درگاه باشد. تیم زیرساخت شما به توسعه سرور MCP شما وابسته می‌شود.
  • پشتیبانی محدود از استریمing: در حالی که برخی درگاه‌ها از SSE پشتیبانی می‌کنند، اعمال سیاست در میانه‌ی مسیر به طور تصاعدی پیچیده‌تر می‌شود.

میانجی‌گری MCP

  • محافظت در برابر تغییرات نسخه: محافظت از کلاینت MCP در برابر تغییرات ناسازگار هنگام ارتقای سرور MCP.
  • فیلترینگ درخواست: حذف ابزارها از پاسخ‌های کشف (discovery) بر اساس الزامات سازگاری رو به عقب.
  • پاکسازی پاسخ: حذف داده‌های حساس از پاسخ‌های ابزار بر اساس سطوح دسترسی کاربر.
  • تزریق زمینه: افزودن زمینه سازمانی (شناسه کاربر، اطلاعات تننت) به فراخوانی‌های ابزار.
  • مدیریت خطا: تبدیل خطاهای پروتکل MCP به رویدادهای ممیزی سازگار با استاندارد سازمانی.

چندپخشی (Multiplexing) MCP

  • ابزارهای آب‌وهوا از weather-service.internal
  • ابزارهای پایگاه داده از analytics-service.internal
  • ابزارهای ایمیل از notification-service.internal
  • پخش جلسات (Session fan-out): وقتی کلاینتی دستوری برای «tools/list» ارسال می‌کند، درگاه باید از تمام سرورهای بک‌اند استعلام گرفته و نتایج را ادغام کند.
  • مسیریابی درخواست: فراخوانی‌های ابزار باید بر اساس نام ابزار به بک‌اند صحیح هدایت شوند.
  • چندپخشی پاسخ: پاسخ‌های استریم شده از چندین بک‌اند باید در یک استریم SSE واحد ادغام شوند.
  • هماهنگی حالت: شناسه‌های جلسه و مذاکرات پروتکل باید در چندین اتصال بک‌اند مدیریت شوند.
  • مدیریت خطا: خرابی در یک بک‌اند نباید کل جلسه مجازی را مختل کند.

Agentgateway: ساخته شده برای MCP از پایه

نقشه‌های راه، مقالات، منابع و مسیرهای ایجاد شده توسط جامعه برای توسعه‌دهندگان تا به شما کمک کنند مسیر خود را انتخاب کنید و در حرفه خود پیشرفت کنید.

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

منبع: https://thenewstack.io/mcp-vs-api-gateways-theyre-not-interchangeable/