پاسخ کوتاه: MCP یا Model Context Protocol یک پروتکل باز است که مشخص می‌کند یک برنامهٔ هوش مصنوعی چطور به داده و ابزارهای بیرونی وصل شود. به‌جای اینکه برای هر مدل و هر نرم‌افزار یک اتصال جداگانه بنویسید، سرویس شما یک بار «سرور MCP» می‌شود و هر کلاینتی که این پروتکل را می‌فهمد — Claude، Cursor، و ابزارهای دیگر — می‌تواند از آن استفاده کند. پیام‌ها با JSON-RPC 2.0 رد و بدل می‌شوند و آخرین نسخهٔ مشخصات، ۲۰۲۶-۰۷-۲۸ است.
قبل از MCP، وصل‌کردن یک دستیار هوش مصنوعی به داده‌های واقعی کسب‌وکار یعنی نوشتن یکپارچه‌سازی اختصاصی برای هر ترکیب مدل و سیستم. اگر سه مدل و چهار سیستم داشتید، دوازده اتصال داشتید و دوازده‌تا را باید نگه می‌داشتید. MCP همان مسئله‌ای را حل می‌کند که Language Server Protocol برای ویرایشگرهای کد حل کرد: یک استاندارد در وسط، تا هر طرف فقط یک بار پیاده‌سازی کند.
معماری: میزبان، کلاینت، سرور
مشخصات رسمی سه نقش تعریف می‌کند و تفکیک این سه، بیشتر سوءتفاهم‌ها را حل می‌کند:
| نقش | چیست | نمونه |
|---|---|---|
| Host (میزبان) | برنامهٔ هوش مصنوعی که اتصال را آغاز می‌کند | یک IDE، یک اپ چت، یک عامل خودکار |
| Client (کلاینت) | رابط داخل میزبان که با یک سرور حرف می‌زند | به‌ازای هر سرور یک کلاینت |
| Server (سرور) | سرویسی که داده و قابلیت عرضه می‌کند | سرور MCP روی ERP، روی مخزن کد، روی پایگاه داده |
نکتهٔ مهمی که اغلب جا می‌افتد: مدل زبانی خودش عضو این معماری نیست. مدل داخل میزبان تصمیم می‌گیرد کدام ابزار صدا زده شود؛ اجرای واقعی را کلاینت انجام می‌دهد و سرور جواب می‌دهد. یعنی سرور MCP شما به هیچ مدل خاصی گره نخورده است.
سرور چه چیزهایی عرضه می‌کند
یک سرور MCP سه دستهٔ اصلی قابلیت دارد و تفاوتشان کاربردی است، نه تئوریک:
- Tools (ابزارها) — عملیاتی که مدل می‌تواند اجرا کند. هر ابزار نام، توضیح و یک شِمای ورودی دارد. «موجودی این کالا را بخوان» یا «پیش‌فاکتور بساز» ابزارند. این دستهٔ پرکاربردترین است.
- Resources (منابع) — دادهٔ خواندنی که میزبان می‌تواند به‌عنوان زمینه به مدل بدهد؛ مثل یک فایل، یک رکورد یا یک گزارش. برخلاف ابزار، منبع عملیات اجرا نمی‌کند.
- Prompts (پرامپت‌ها) — الگوهای آمادهٔ گفت‌وگو که سرور در اختیار کاربر می‌گذارد؛ مثلاً «گزارش فروش این ماه را تحلیل کن» با ساختار از پیش تعریف‌شده.
در سمت کلاینت هم سه قابلیت تعریف شده که کمتر شناخته‌شده‌اند ولی برای طراحی درست مهم‌اند: Roots (اعلام محدودهٔ مجاز کار به سرور)، Sampling (سرور می‌تواند از میزبان بخواهد از مدل چیزی بپرسد) و Elicitation (سرور می‌تواند وسط کار از کاربر اطلاعات بخواهد). Elicitation دقیقاً همان چیزی است که اجازه می‌دهد یک عملیات نوشتن، قبل از اجرا از کاربر تأیید بگیرد.
پیام‌ها و انتقال
پیام‌ها JSON-RPC 2.0 هستند و باید UTF-8 باشند. مشخصات دو روش انتقال استاندارد تعریف می‌کند:
| انتقال | چطور کار می‌کند | کجا مناسب است |
|---|---|---|
| stdio | پیام‌های خط‌به‌خط روی ورودی/خروجی استاندارد یک زیرفرایند که کلاینت اجرا می‌کند | ابزار محلی روی همان دستگاه کاربر |
| Streamable HTTP | هر پیام یک POST به یک نقطهٔ پایانی؛ پاسخ یا یک شیء JSON است یا یک جریان SSE مخصوص همان درخواست | سرور مشترک و از راه دور — حالت رایج برای ERP ابری |
معنای عملی این تفکیک: اگر سرور MCP شما روی یک سرویس ابری چندکاربره است، انتقال شما HTTP است و بنابراین باید مسئلهٔ احراز هویت را جدی بگیرید. سرور stdio روی لپ‌تاپ خود کاربر اجرا می‌شود و مرز امنیتی دیگری دارد.
احراز هویت و مجوز
مشخصات، مجوزدهی را روی OAuth 2.1 بنا کرده است: سرور MCP محافظت‌شده نقش resource server را دارد و کلاینت نقش OAuth client. سرور مجوز مسئول تعامل با کاربر و صدور توکن است و می‌تواند جدا یا هم‌محل با خود سرور باشد. مجموعه‌ای از RFCهای شناخته‌شده هم بخشی از الزاماتند — از جمله Bearer Token Usage، Authorization Server Metadata، Dynamic Client Registration و Protected Resource Metadata.
برای یک کسب‌وکار این یعنی: کلید ساده و ثابت («Bearer یکی برای همیشه») برای شروع کار می‌کند ولی مسیر استاندارد نیست. تفاوت این دو و اینکه هرکدام کجا جواب می‌دهد در احراز هویت MCP: کلید Bearer یا OAuth 2.1 باز شده است.
MCP در برابر API و افزونه
سه راه برای وصل‌کردن هوش مصنوعی به سیستم سازمانی وجود دارد و انتخاب اشتباه، هزینهٔ نگهداری را چند برابر می‌کند:
| معیار | MCP | REST API مستقیم | افزونهٔ اختصاصی |
|---|---|---|---|
| کشف قابلیت‌ها توسط مدل | خودکار؛ ابزارها خودشان را با شِما معرفی می‌کنند | ندارد؛ باید در پرامپت توضیح داده شود | ندارد |
| افزودن قابلیت جدید | یک ابزار به سرور اضافه می‌شود | تغییر کد کلاینت | انتشار نسخهٔ جدید افزونه |
| کار با چند مدل | یک سرور برای همه | برای هر کلاینت جدا | معمولاً قفل به یک پلتفرم |
| کنترل دسترسی | در سطح ابزار و نقش کاربر | در سطح توکن API | در سطح افزونه |
| مناسب برای | دستیار روی دادهٔ زنده با مسیر نامعین | یکپارچه‌سازی ماشین‌به‌ماشین ثابت | قابلیت بسته و مشخص |
چه زمانی MCP لازم نیست
MCP وقتی ارزش دارد که مدل باید تصمیم بگیرد کدام عملیات را صدا بزند. اگر مسیر از قبل مشخص است، پروتکل اضافه فقط پیچیدگی می‌آورد. سه مورد که REST ساده کافی است:
- همگام‌سازی زمان‌بندی‌شده: انتقال شبانهٔ سفارش‌ها بین دو سیستم، بدون دخالت مدل.
- وب‌هوک یک‌طرفه: اطلاع‌رسانی رویداد به یک سرویس بیرونی.
- گزارش ثابت: خروجی ماهانه‌ای که ستون‌هایش هرگز عوض نمی‌شود.
مقایسهٔ کامل معماری این دو مسیر در MCP یا API سنتی؛ تفاوت واقعی آمده است.
چرا برای ERP فارسی اهمیت دارد
یک ERP مثل اودوو صدها مدل داده و ده‌ها هزار رکورد دارد. بدون MCP، تنها راه استفاده از هوش مصنوعی روی این داده، خروجی‌گرفتن دستی و چسباندن در چت است — کند، محدود، و همیشه کهنه. با یک سرور MCP روی اودوو، دستیار می‌تواند بپرسد «مانده‌ی حساب این مشتری چقدر است؟» یا «سفارش‌های امروز را خلاصه کن» و جواب لحظه‌ای بگیرد — با دسترسی همان کاربری که کلید به او وصل است، نه بیشتر.
سه کاربردی که در عمل بیشترین بازده را دارند:
- گزارش‌گیری محاوره‌ای. سؤال‌هایی که ساختن گزارش برایشان صرف نمی‌کند: «کدام مشتری‌ها این ماه سفارش نداده‌اند؟»
- ثبت با تأیید. مدل پیش‌نویس می‌سازد، انسان تأیید می‌کند. Elicitation دقیقاً برای همین طراحی شده.
- بررسی وضعیت سامانه‌های بیرونی. مثل استعلام وضعیت صورتحساب در سامانه مودیان، بدون باز کردن پنل جدا.
فهرست کامل‌تر در ۷ کاربرد واقعی سرور MCP روی اودو آمده است.
امنیت: پروتکل امن نیست، پیاده‌سازی امن است
خود مشخصات بخش جداگانه‌ای برای امنیت و اعتماد دارد، ولی نکتهٔ کلیدی این است که MCP یک چارچوب است؛ مرزهای امنیتی را پیاده‌سازی سرور تعیین می‌کند. یک سرور MCP قابل‌اتکا حداقل باید سه چیز را تضمین کند:
- حداقل دسترسی. ابزارها فقط همان کاری را بتوانند بکنند که نقش کاربر اجازه می‌دهد — نه دسترسی سرویس‌اکانت فراگیر.
- تأیید انسانی پیش از نوشتن. خواندن و نوشتن نباید یک سطح اعتماد داشته باشند.
- ثبت کامل. هر فراخوانی با کاربر، ابزار، ورودی و نتیجه ثبت شود؛ بدون این، بازرسی بعد از حادثه ممکن نیست.
تحلیل مدل تهدید و اینکه هرکدام از این‌ها چطور نقض می‌شود در MCP چقدر امن است؟ آمده، و پیش از دادن هر کلید به یک کلاینت هوش مصنوعی، چک‌لیست امنیتی کلیدهای MCP را مرور کنید.
خطاهای رایج در پیاده‌سازی
- ابزار بیش از حد عمومی. ابزاری با نام «query» که هر کوئری دلخواهی می‌گیرد، عملاً یعنی دسترسی کامل. ابزارها باید کوچک و مشخص باشند.
- توضیح ضعیف ابزار. مدل از روی توضیح تصمیم می‌گیرد. توضیح مبهم یعنی ابزار اشتباه در زمان اشتباه صدا زده می‌شود.
- برگرداندن حجم زیاد داده. خروجی هزار ردیفی پنجرهٔ زمینه را پر می‌کند و کیفیت پاسخ را پایین می‌آورد. صفحه‌بندی و خلاصه‌سازی در سمت سرور انجام شود — جزئیات در ابزار MCP آگاه به بودجهٔ توکن.
- نادیده‌گرفتن چندمستأجری. روی سرویس ابری، انزوای دادهٔ هر مستأجر باید در خود لایهٔ ابزار اعمال شود. چرا این معمولاً خراب می‌شود در چرا اکثر سرورهای MCP روی ERP چندمستأجره خراب می‌شوند آمده است.
چطور شروع کنم
روی یک فضای کاری ابرک، اپ سرور MCP را فعال کنید و راهنمای گام‌به‌گام اتصال را دنبال کنید — از ساخت کلید تا اتصال یک کلاینت معمولاً کمتر از ۱۵ دقیقه طول می‌کشد. اگر هنوز فضای کاری ندارید، از شروع رایگان بسازید.
پرسش‌های پرتکرار
MCP مخفف چیست؟
Model Context Protocol. پروتکلی باز برای اتصال برنامه‌های مبتنی بر مدل زبانی به منابع داده و ابزارهای بیرونی.
MCP رایگان است؟
خود پروتکل باز و بدون هزینه است. چیزی که هزینه دارد، سروری است که شما یا فروشندهٔ نرم‌افزارتان پیاده می‌کند و سرویس مدلی که استفاده می‌کنید.
فرق MCP با function calling چیست؟
function calling قابلیتی در سطح API یک مدل است: شما فهرست توابع را در هر درخواست به مدل می‌دهید. MCP یک لایهٔ بالاتر است: سرور خودش ابزارهایش را معرفی می‌کند و همان سرور برای هر میزبان و هر مدلی که پروتکل را می‌فهمد کار می‌کند. در عمل، میزبان معمولاً ابزارهای MCP را به function calling مدل ترجمه می‌کند.
آیا داده‌ام به شرکت سازندهٔ مدل می‌رود؟
هر چیزی که ابزار برمی‌گرداند وارد گفت‌وگو می‌شود و به سرویس مدل ارسال می‌گردد. این تصمیم معماری شماست، نه ویژگی پروتکل: با محدودکردن خروجی ابزارها و تعریف دقیق دسترسی، مشخص می‌کنید چه چیزی از سازمان بیرون می‌رود.
آخرین نسخهٔ مشخصات کدام است؟
در زمان بررسی (۱۸ شهریور ۱۴۰۵) نسخهٔ ۲۰۲۶-۰۷-۲۸ به‌عنوان latest اعلام شده است. پروتکل نسخه‌بندی تاریخ‌محور دارد و سازگاری نسخه‌ها بخش جداگانه‌ای در مشخصات دارد.
منابع
- مشخصات رسمی MCP (نسخهٔ ۲۰۲۶-۰۷-۲۸) — modelcontextprotocol.io/specification/latest (بررسی: ۱۸ شهریور ۱۴۰۵)
- بخش Transports مشخصات — stdio و Streamable HTTP
- بخش Authorization مشخصات — مبتنی بر OAuth 2.1 و RFCهای مرتبط
