شهریور
Opsless و آینده کار
MCP چیست و چرا زیرساخت اصلی عصر Opsless است
وقتی یک Agent قرار است بهجای انسان کارهای واقعی انجام دهد — رکورد بسازد، ایمیل بفرستد، وضعیت یک معامله را عوض کند — باید راهی داشته باشد که «بفهمد» چه ابزارهایی در دسترساند و چطور باید آنها را صدا بزند. تا همین چند سال پیش، پاسخ این سؤال هربار از صفر نوشته میشد: یک اتصال دستی، یک مستند API، یک لایهٔ ترجمهٔ سفارشی برای هر جفت Agent-ابزار. MCP یا Model Context Protocol دقیقاً همین مسئله را حل میکند و به همین دلیل است که در معماری هر محصول Opsless، از آن بهعنوان زیرساخت پایه یاد میشود.
لیست مطالب
تعریف MCP در یک جمله
MCP یک پروتکل باز و استاندارد است که مشخص میکند یک مدل زبانی یا Agent چطور با منابع بیرونی — داده، ابزار، Prompt آماده — گفتوگو کند، بدون اینکه برای هر منبع یک رابط اختصاصی نوشته شود. بهجای اینکه هر ابزار زبان خودش را داشته باشد، همه پشت یک قرارداد یکسان صحبت میکنند.
معماری Client-Server
MCP از یک الگوی ساده و آشنا پیروی میکند:
- MCP Server: کنار یک سیستم واقعی (مثلاً CRM، تقویم، پایگاهدادهٔ داخلی) قرار میگیرد و قابلیتهای آن سیستم را بهصورت استاندارد عرضه میکند.
- MCP Client: داخل Agent یا اپلیکیشن میزبان مدل زندگی میکند و از طرف مدل با یک یا چند Server صحبت میکند.
هر Server میتواند سه نوع چیز عرضه کند: Tools (اقداماتی که Agent میتواند اجرا کند)، Resources (دادههایی که Agent میتواند بخواند) و Prompts (الگوهای آمادهٔ تعامل). این تفکیک باعث میشود Agent بین «نگاهکردن» و «تغییردادن» تمایز روشنی داشته باشد.
چرا این با API معمولی یا پلاگین اختصاصی فرق دارد
یک API سنتی برای انسان یا برای یک کد از پیش نوشتهشده طراحی میشود؛ مستند آن برای خواندن انسانی است و هر تیم باید جداگانه آن را Integrate کند. یک پلاگین اختصاصی هم فقط داخل همان اپلیکیشن خاص کار میکند. اما یک Agent باید بتواند در لحظه، بدون کد از پیش نوشتهشده برای آن ابزار خاص، بفهمد چه ابزاری وجود دارد و چطور باید آن را صدا بزند. MCP این «قابلکشفبودن» (Discoverability) را بهصورت داخلی در پروتکل میگنجاند: هر Server میتواند فهرست ابزارهای خودش را همراه با Schema دقیق ورودی/خروجی اعلام کند.
تفاوت اصلی این است: API را برنامهنویس برای برنامهنویس مینویسد؛ MCP Server را سیستم برای Agent توصیف میکند.
چرا برای Opsless حیاتی است
در یک محصول Opsless، کاربر دیگر مستقیماً با CRM یا ابزار پیامرسانی کار نمیکند؛ Agent بهجای او این کار را انجام میدهد. این یعنی Agent باید بتواند به تعداد نامعلومی سیستم بیرونی متصل شود، بدون اینکه برای هر کدام یک ماه یکپارچهسازی سفارشی طول بکشد. سه ویژگی MCP دقیقاً همین را ممکن میکند:
- استانداردسازی: یک قرارداد یکسان برای همهٔ ابزارها یعنی افزودن یک سیستم جدید به دنیای Agent، کار چند ساعته است نه چند هفتهای.
- قابلیت کشف در لحظه: Agent میتواند در زمان اجرا بفهمد چه Toolهایی موجودند و Schema هرکدام چیست، بدون اینکه این اطلاعات از قبل در کد Hardcode شده باشد.
- ترکیبپذیری: چند MCP Server (CRM، ایمیل، تقویم) همزمان به یک Agent متصل میشوند و Agent میتواند در یک زنجیره از همهٔ آنها استفاده کند.
نمونهٔ یک Tool در قالب MCP
یک MCP Server برای یک CRM ممکن است ابزاری به این شکل تعریف کند:
{
"name": "crm.create_lead",
"description": "Create a new lead record in the CRM",
"input_schema": {
"type": "object",
"properties": {
"full_name": { "type": "string" },
"phone": { "type": "string" },
"source": { "type": "string", "enum": ["telegram", "instagram", "form"] }
},
"required": ["full_name", "phone"]
}
}Agent هنگام تصمیمگیری، این تعریف را میخواند، ورودی لازم را از Context مکالمه استخراج میکند و فراخوانی را با همین ساختار انجام میدهد. اگر فردا یک CRM جدید جایگزین این یکی شود، فقط MCP Server عوض میشود؛ منطق داخلی Agent دستنخورده میماند.
اتصال یک Agent به CRM از طریق MCP؛ نمای کلی
در عمل، جریان اتصال چیزی شبیه این مراحل است:
- Agent هنگام راهاندازی به MCP Server مربوط به CRM متصل میشود و فهرست Tools و Resources را دریافت میکند.
- وقتی کاربر یک Intent مثل «برای این مشتری یک لید بساز» میدهد، Agent از میان Tools موجود، مناسبترین را انتخاب میکند.
- Agent ورودی را طبق Schema میسازد و از طریق MCP Client فراخوانی را ارسال میکند.
- MCP Server درخواست را به CRM واقعی ترجمه میکند، نتیجه را میگیرد و در قالب استاندارد به Agent برمیگرداند.
نکتهٔ مهم این است که در این زنجیره، هیچکجا کاربر مجبور نیست بداند CRM چه شکلی دارد یا کجای آن باید کلیک کند. همین غیبت رابط کاربری است که MCP را به زیرساخت اصلی Opsless تبدیل میکند، نه فقط یک روش راحتتر برای اتصال API.
امنیت و کنترل دسترسی
وقتی Agent میتواند به چند MCP Server همزمان متصل شود، سؤال امنیتی جدی مطرح میشود: چه چیزی جلوی Agent را میگیرد که یک Tool را در جایی که نباید، صدا نزند؟ پاسخ درست این نیست که به مدل اعتماد کنیم؛ پاسخ این است که دامنهٔ دسترسی را در همان لایهٔ Server محدود کنیم. یک MCP Server خوب سه اصل را رعایت میکند:
- Scoping: هر اتصال فقط به Tools و Resourcesی دسترسی دارد که برای همان کاربر یا همان Agent مجاز شده، نه کل فهرست سیستم.
- Least Privilege: اگر Agent فقط باید لید بسازد، نباید همان اتصال بتواند رکورد را هم حذف کند؛ هر Tool باید دقیقاً همان کاری را انجام دهد که نامش میگوید.
- Audit Log: هر فراخوانی، صرفنظر از موفق یا ناموفق بودن، باید ثبت شود تا در صورت بروز خطا، مسیر کامل قابل بازسازی باشد.
این سه اصل دقیقاً همان چیزی است که به تیم فنی اجازه میدهد بدون نگرانی از رفتار غیرمنتظرهٔ مدل، دامنهٔ ابزارهای در دسترس Agent را هرچه بیشتر گسترش دهد.
جمعبندی
- MCP یک پروتکل استاندارد برای اتصال Agent به ابزارها و دادههای بیرونی است، نه یک API دیگر.
- معماری آن روی سه مفهوم Tools، Resources و Prompts، و رابطهٔ Client-Server ساخته شده است.
- مزیت اصلی آن نسبت به یکپارچهسازی سنتی، قابلیت کشف در لحظه و ترکیبپذیری چند سیستم است.
- برای یک محصول Opsless، MCP یعنی افزودن سیستم جدید بدون بازنویسی منطق Agent.
- Schema دقیق ورودی/خروجی هر Tool، پیششرط قابلاعتماد بودن هر فراخوانی است.
این مقاله بخشی از دورهٔ Opsless است.
