اودو سالهاست XML-RPC و یک لایهی REST دارد؛ هر توسعهدهندهای میتواند با آنها اسکریپت بنویسد. سؤال منطقی این است: اگر API از قبل وجود داشت، MCP (Model Context Protocol) دقیقاً چه چیزی را حل کرد؟ جواب کوتاه: API سنتی برای یک برنامهنویس که مستندات را میخواند طراحی شده، نه برای یک مدل زبانی که باید در لحظهی گفتوگو تصمیم بگیرد کدام تابع را با کدام آرگومان صدا بزند.
مشکل اول: کشفپذیری (Discovery)
یک برنامهنویس مستندات API را میخواند و کد مینویسد — یکبار، آفلاین. یک مدل زبانی در وسط گفتوگو باید بفهمد چه ابزاری موجود است، ورودیاش چیست و چه زمانی مناسب استفاده است. MCP این را با یک متد استاندارد (tools/list) حل میکند: سرور خودش، همراه با JSON Schema هر ورودی و توضیح دوزبانه، فهرست ابزارهایش را اعلام میکند — مدل چیزی را از قبل حفظ نکرده، در لحظه کشف میکند.
مشکل دوم: هر سیستم قرارداد خودش را داشت
پیش از MCP، هر ادغام هوش مصنوعی با هر سیستم یک قرارداد سفارشی بود — یک اتصال اودو با یک اتصال CRM دیگر هیچ شباهتی نداشت. با MCP، همهی سیستمها همان شکل پیام JSON-RPC را صحبت میکنند؛ همان کلاینتی که به اودو وصل میشود، به یک سرور MCP دیگر (مثلاً GitHub یا Slack) هم همانطور وصل میشود. این یعنی نوشتن یک سرور MCP یکبار انجام میشود و روی هر کلاینت سازگار کار میکند، نه فقط یکی.
مشکل سوم: نوشتن غیرقابلاعتماد بود
یک REST API معمولی فرض میکند تماسگیرنده کد است و میداند دقیقاً چه میخواهد. یک مدل زبانی گاهی اشتباه میفهمد. MCP این تفاوت را در پروتکل خودش به رسمیت میشناسد: یک ابزار میتواند resultType: "input_required" برگرداند و از کاربر تأیید بخواهد، پیش از آنکه چیزی واقعاً نوشته شود — چیزی که یک REST endpoint سنتی مفهومش را ندارد.
پس آیا REST API اودو منسوخ شده؟
نه. MCP جایگزین API نیست، یک لایهی بالاتر برای مصرفکنندهی هوش مصنوعی است. سرور MCP ابرک هم پشت صحنه از همان ORM اودو استفاده میکند — فقط قرارداد بیرونیاش برای مدل زبانی طراحی شده، نه برای برنامهنویس. جزئیات معماری و ۵۱ ابزار موجود در صفحهی اپ سرور MCP آمده و آموزش اتصال نشان میدهد چطور در عمل کار میکند.
جدول تصمیم؛ کی API کافی است و کی MCP لازم
| نیاز شما | راه حل |
|---|---|
| وب سایت/اپ به ERP وصل شود | REST API کافی است |
| مدیر با زبان طبیعی گزارش بخواهد | MCP + مدل زبانی |
| چند مدل AI مختلف استفاده شود | MCP یک بار، همه مدل ها |
| AI اقدام ثبت هم بکند نه فقط جواب | MCP با ابزارهای کنترل شده |
MCP جایگزین API نیست؛ لایه ای بالای آن برای دنیای AI است. تحلیل کامل در بدنه مقاله و پیاده سازی آماده در سرور MCP ابرک.
معماری امنیتی MCP؛ پنج دیوار دفاعی
- احراز هویت هر کلاینت: OAuth یا کلید اختصاصی؛ هیچ endpoint بی نام
- Scope در سطح ابزار: ابزارهای فقط-خواندن و ابزارهای نوشتن جدا تعریف می شوند
- اعتبارسنجی ورودی: هر پارامتر از مدل، مثل ورودی کاربر ناشناس اعتبارسنجی می شود
- Rate limit و بودجه: سقف فراخوانی per-client
- لاج کامل قابل جستجو: چه کسی کِی چه ابزاری را با چه ورودی صدا زد
این پنج مورد دقیقاً چیزی است که سرور MCP ابرک پیاده کرده؛ بدون این ها اتصال AI به ERP یعنی باز گذاشتن در بانک اطلاعاتتان به روی یک متغیر غیرقابل پیش بینی.
سناریوی مقایسه ای؛ یک خواسته، دو معماری
خواسته: «مدیر فروش با واتساپ بپرسد فروش امروز چقدر بود.»
- مسیر API سنتی: ساخت ربات واتساپ + backend واسط + کوئری های امن + مدیریت نشست = چند هفته توسعه و نگهداری دائمی
- مسیر MCP: ابزار sales_report را expose کنید؛ مدل خودش سوال را به فراخوانی تبدیل می کند = راه اندازی چند ساعته، نگهداشت حداقلی
