اودو سالهاست 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 آمده و آموزش اتصال نشان میدهد چطور در عمل کار میکند.
