همه یک جمله حفظاند: «MCP مثل USB-C است برای هوش مصنوعی». قشنگ است، ولی اگر تو سالهاست API مینویسی، این تشبیه جواب سؤالت را نمیدهد. سؤال واقعی این است: من همین حالا یک API دارم که کار میکند؛ چرا باید یک لایهٔ دیگر رویش بگذارم؟
این مقاله همان سؤال را باز میکند: اول میبینیم MCP دقیقاً چیست، بعد کنار API میگذاریمش و آخرش جاهایی را نشان میدهیم که MCP انتخاب اشتباهی است. اگر فقط تعریف میخواستی، بخش اول کافی است.
کوتاه و بیحاشیه
- MCP چیست
- یک استاندارد باز برای وصل کردن اپهای هوش مصنوعی به ابزار، داده و ورکفلو؛ با یک قرارداد مشترک بهجای اینتگریشن اختصاصی
- تفاوت اصلی با API
- API رابط برای کدِ توست و تو تصمیم میگیری کدام اندپوینت کِی صدا زده شود؛ MCP ابزارها را به مدل معرفی میکند تا خودِ مدل وسط گفت‌وگو انتخاب کند
- زیر پوسته
- JSON-RPC 2.0 روی دو ترنسپورت: stdio (همان دستگاه) و Streamable HTTP (دور)
- سرور چه چیزی می‌دهد
- سه چیز: tools، resources و prompts
- چه زمانی بهکار میآید
- وقتی یک قابلیت باید در چند کلاینت (کلود، کرسر، VS Code، ادیتور خودت) بدون کدِ جدید قابل استفاده باشد
- چه زمانی نه
- برای اتوماسیون ثابت و اسکریپتشده، API سادهتر، ارزانتر و قابل تستتر است
MCP چیست؟
MCP یا Model Context Protocol (پروتکل زمینهٔ مدل) یک استاندارد باز است که اپلیکیشنهای هوش مصنوعی را به سیستمهای بیرونی وصل میکند. آنتروپیک آن را نوامبر ۲۰۲۴ معرفی کرد و بعد از آن به یک استاندارد مشترک تبدیل شد: کلود، ChatGPT، VS Code و Cursor امروز همه MCP را میفهمند.
سه نقش دارد و مهم است که قاطی نکنی:
- Host: اپلیکیشنی که کاربر با آن کار میکند (کلود دسکتاپ، کرسر، ادیتور خودت).
- Client: بخشی داخل Host که با یک سرور MCP اتصال برقرار میکند؛ پروتکل را همین بلد است.
- Server: برنامهای که ابزارها و دادهها را معرفی میکند. این همان چیزی است که تو مینویسی.
سرور سه نوع چیز معرفی میکند: tools (کارهایی که میشود انجام داد، مثل «پروژه بساز»)، resources (دادههای خواندنی، مثل یک فایل یا رکورد) و prompts (قالبهای آمادهٔ درخواست). مدل با ابزار کار میکند و با resource متن می‌خواند.
MCP چه مشکلی را حل میکند که API حل نمی‌کند؟
یک API خوب، برای مصرفکنندهای نوشته شده که کد است: تو مستندات را میخوانی، اندپوینت را صدا میزنی، خروجی را پارس میکنی. تصمیم «چه زمانی کدام اندپوینت» مال توست، داخل کدت.
حالا همان قابلیت را به یک مدل بده. مدل باید بداند چه ابزارهایی وجود دارد، هر کدام چه ورودی می‌گیرد و کِی باید سراغش برود. بدون استاندارد، برای هر (مدل × سرویس) یک اینتگریشن جدا لازم است؛ کلاسیک مسئلهٔ M×N. MCP این را به M+N تبدیل میکند: سرویس یک سرور MCP می‌دهد، کلاینتها هم همه همان قرارداد را بلدند. دقیقاً منطق LSP برای ویرایشگرها.
همین «یک بار بساز، همهجا استفاده کن» دلیل اصلی محبوبیتش است. تفاوت را در این جدول بهتر میبینی:
تفاوت MCP و API در یک جدول
| API (مثلاً REST) | MCP | |
|---|---|---|
| مخاطب | کدِ برنامه‌نویس | مدل زبانی، با واسطهٔ Host |
| تصمیم کی صدا بزند | کد تو، از قبل نوشته شده | مدل، در لحظه و وسط گفت‌وگو |
| کشف قابلیت | مستندات و OpenAPI که آدم می‌خواند | tools/list در زمان اجرا، با اسکیمای ورودی |
| شکل فراخوانی | هر سرویس، سلیقهٔ خودش | یک شکل ثابت برای همه |
| احراز هویت | کدِ تو مدیریت میکند | سرور؛ یا از Host می‌گیرد (OAuth) یا خودش کلید دارد |
| هزینهٔ اضافه | ندارد | توکن بابت توضیح ابزارها در هر نشست |
| قابل تست بودن | با curl و تست واحد، راحت | با Inspector یا کلاینت؛ کمی دست‌وپاگیرتر |
| جایگاه | لایهٔ زیرین، منبع حقیقت | پوستهٔ روی همان API |
سطر آخر مهمترین است: MCP جایگزین API نیست. یک سرور MCP خوب تقریباً همیشه یکی از این دو کار را میکند: یا یک API موجود را میپیچد، یا مستقیم به دیتابیس/فایلسیستم وصل میشود. بدون منطق و اعتبارسنجی زیرین، چیزی برای عرضه ندارد.
مدل دقیقاً چه چیزی می‌بیند؟
این بخش را در بیشتر مقالههای فارسی ندیدم و همینجاست که ماجرا روشن میشود. کلاینت از سرور میپرسد چه ابزارهایی داری و جوابی شبیه این می‌گیرد:
{
"tools": [
{
"name": "get_project_status",
"description": "وضعیت دیپلوی یک پروژه را برمیگرداند",
"inputSchema": {
"type": "object",
"properties": { "projectId": { "type": "string" } },
"required": ["projectId"]
}
}
]
}این توصیف مستقیم میرود داخل پرامپت مدل. یعنی description در واقع متن پرامپت است، نه مستندات. اگر مبهم بنویسی، مدل ابزار اشتباه را انتخاب میکند؛ اگر خیلی طولانی بنویسی، توکن میسوزاند. این تنها جای پروتکل است که «مهندسی پرامپت» وارد کد میشود.
بعد مدل تصمیم می‌گیرد و فراخوانی میفرستد:
{
"method": "tools/call",
"params": {
"name": "get_project_status",
"arguments": { "projectId": "abc123" }
}
}سرور اجرا میکند و خروجی ساختیافته برمیگرداند. از نظر فنی، همان کاری است که یک اندپوینت API میکند — فقط قرارداد و مخاطبش عوض شده.
چه زمانی MCP بسازیم، چه زمانی API کافی است؟
| وضعیت | انتخاب |
|---|---|
| اسکریپت ثابت که هر شب اجرا میشود | API؛ MCP اینجا فقط یک لایهٔ اضافه است |
| محصولی که مشتری‌هایش از کلود، کرسر و ادیتورهای مختلف استفاده میکنند | MCP؛ یک بار میسازی، همهجا کار میکند |
| ابزار داخلی تیم که می‌خواهی مدل خودش انتخابش کند | MCP؛ کشف و اسکیما همین‌جا ارزشش را نشان می‌دهد |
| فایل، دیتابیس یا لاگ که مدل باید بخواند | MCP با tools و resources، نه اندپوینت تازه |
| پردازش سنگین، استریم ویدیو یا حجم بالای درخواست | API؛ MCP برای این بارها ساخته نشده |
| چند سرویس که باید با هم orchestrate شوند | یک سرور MCP که چند API را پشت یک ابزار تمیز جمع میکند |
پنج محدودیتی که در تبلیغ‌ها نمی‌بینی
- صفحهبندی: اگر API صد رکورد در هر فراخوانی برگرداند، مدل معمولاً نمیفهمد باید صفحه بعد را بگیرد. همین باعث میشود نتیجه ناقص بدهد و مطمئن هم باشد. راهحل: خودِ سرور صفحهبندی را جمع کند.
- هزینهٔ کانتکست: هر ابزار با توضیح و اسکیما میآید داخل پرامپت. بیست ابزار بیدقت یعنی هزینه و کندی در هر نشست. ابزار کمتر و دقیقتر بهتر از ابزار زیاد است.
- کار چندمنبعی: ترکیب چند سرور در یک گفت‌وگو همیشه تمیز انجام نمیشود؛ برای جریان پیچیده، یک سرور MCP که منطق را یکجا دارد جواب بهتری می‌دهد.
- امنیت: مدل خروجی ابزار و محتوای resource را می‌خواند؛ یعنی راه تزریق پرامپت از همانجا باز است. هر سروری که وصل میکنی، عملاً یک ورودی غیرقابلاعتماد است.
- نسخه و تغییر: اسم و اسکیمای ابزار، قرارداد است. تغییرش میتواند رفتار مدل را بیصدا خراب کند؛ مثل یک API نسخهبندی نکرده، فقط بدون خطای ۴۰۰.
MCP با Function Calling و RAG چه تفاوتی دارد؟
| مفهوم | لایه | کارش |
|---|---|---|
| Function Calling | قابلیت مدل | مدل خروجی JSON با اسم تابع و پارامتر می‌دهد |
| MCP | استاندارد انتقال و کشف | میگوید این توابع کجا هستند، چطور معرفی و صدا زده شوند |
| Plugin | وابسته به یک محصول | همان ایده، ولی فقط داخل اکوسیستم همان شرکت |
| RAG | بازیابی داده | قطعهٔ متنی مرتبط را می‌آورد در کانتکست |
اینها رقیب هم نیستند. Function Calling همان قابلیتی است که MCP ازش استفاده میکند؛ RAG هم معمولاً کنار MCP مینشیند: RAG برای «چه چیزی میدانیم» و MCP برای «چه کاری میتوانیم بکنیم».
اولین قدم عملی
لازم نیست از صفر شروع کنی. اگر یک API دارید، اولین سرور MCP معمولاً یک فایل است که دو یا سه اندپوینت را به ابزار تبدیل میکند: یک name که مدل میفهمد، یک description دقیق، و یک inputSchema تنگ و مشخص. بعد با @modelcontextprotocol/inspector تستش میکنی و بعد به کلاینت وصلش میکنی.
اگر نمیخواهی سرور بنویسی، سرور MCP لکسویا همان الگو را برای زیرساخت آماده کرده: پروژه بساز، دیپلوی کن، لاگ بیلد را بخوان، دیتابیس بالا بیاور — همه از داخل ادیتور. راهنمای اتصالش را ببین.
جمع‌بندی
MCP یک استاندارد است، نه یک محصول و نه جایگزین API. ارزشش در دو چیز است: کشف در زمان اجرا (مدل خودش می‌بیند چه ابزاری هست) و یک قرارداد برای همه (یک بار میسازی، هر کلاینتی استفاده میکند).
برای اتوماسیون قطعی و اسکریپت، همیشه API را انتخاب کن. برای ابزار و دادهای که باید در گفت‌وگو و توسط مدل انتخاب شود، MCP کوتاهترین راه است. اگر مطمئن نیستی، از یک ابزار کوچک شروع کن؛ اگر مدل بدون توضیح اضافه ازش درست استفاده کرد، مسیر را درست رفتهای.
MCP را روی زیرساخت خودت امتحان کن
سرور MCP رسمی لکسویا با حدود ۶۰ ابزار: پروژه، دیپلوی، لاگ، دیتابیس، S3 و صورتحساب — از داخل کلود، کرسر یا OpenCode.
سؤالات متداول
MCP به زبان ساده چیست؟
MCP یک استاندارد باز است که اپلیکیشنهای هوش مصنوعی را به ابزارها و دادههای بیرونی وصل میکند. بهجای اینکه برای هر مدل و هر سرویس یک اینتگریشن اختصاصی بنویسی، سرویس یک سرور MCP معرفی میکند و هر کلاینتی (کلود، کرسر، VS Code) با همان قرارداد ازش استفاده میکند.
آیا MCP جایگزین API میشود؟
نه. MCP یک لایه روی API است یا مستقیم به دیتابیس و فایلسیستم وصل میشود، ولی منطق و اعتبارسنجی زیرین همان API است. برای اتوماسیون ثابت و اسکریپتشده، API سادهتر، ارزانتر و قابل تستتر است؛ MCP برای وقتی است که مدل باید در لحظه انتخاب کند.
تفاوت MCP با Function Calling چیست؟
Function Calling یک قابلیت مدل است: مدل JSON با نام تابع و پارامترها تولید میکند. MCP استاندارد انتقال و کشف است: میگوید این توابع کجا هستند، چطور معرفی میشوند و چطور صدا زده میشوند. عملاً Function Calling موتور داخل ماجراست و MCP قرارداد بیرونی.
آیا MCP فقط مخصوص کلود است؟
نه. آنتروپیک آن را معرفی کرد ولی استاندارد باز است و امروز کلود، ChatGPT، VS Code، Cursor و کلاینتهای دیگر پشتیبانی میکنند. همین پشتیبانی چندگانه دلیل اصلی ارزش MCP است: یک بار میسازی، همهجا استفاده میشود.
امنیت MCP چطور است؟
هر سرور MCP یک ورودی غیرقابلاعتماد است، چون خروجی ابزار و محتوای resource مستقیم وارد کانتکست مدل میشود؛ یعنی راه تزریق پرامپت از همانجا باز است. قبل از وصل کردن هر سرور، منبعش را بررسی کن، ابزارهای پرخطر را حذف کن و دسترسیها را به حداقل برسان.
اولین سرور MCP را چطور بسازم؟
با SDK رسمی (TypeScript یا Python) یک فایل کافی است: نام ابزار، توضیح دقیق و اسکیمای ورودی را تعریف میکنی و داخلش همان API موجودت را صدا میزنی. با Inspector تستش میکنی و بعد به کلاینت وصل میکنی. توصیه: با دو ابزار شروع کن، نه بیست ابزار.
آیا MCP برای دیتابیس هم بهکار میرود؟
بله و رایجترین کاربردش همین است: سروری که چند کوئری خواندنی با پارامتر مشخص را بهعنوان ابزار معرفی میکند. بهتر است به مدل دسترسی خام SQL ندهی؛ ابزارهای محدود و خواندنی بگذار تا هم امن باشد هم قابل پیشبینی.
منابع
- معرفی رسمی MCP؛ تعریف، تشبیه USB-C و فهرست کلاینتهای پشتیبان.
- معماری MCP؛ نقش Host/Client/Server و primitiveهای tools، resources و prompts.
- Security Best Practices؛ تزریق پرامپت، ابزارهای مخرب و مرز اعتماد.
- اعلام اولیهٔ آنتروپیک (نوامبر ۲۰۲۴).
- سرور MCP لکسویا؛ یک پیادهسازی واقعی روی HTTP با احراز هویت و فهرست ابزارها.
مطالب مرتبط
- سرور MCP لکسویا برای دیدن یک پیادهسازی واقعی با احراز هویت روی HTTP.
- پلتفرم ابری چیست؟ اگر می‌خواهی بدانی سرور MCP را کجا بالا بیاوری.
- دیپلوی چیست؟ برای مرحلهٔ بعد: از کدِ روی لپتاپ تا سرویس روی اینترنت.
- OpenCode و DeepSeek Harness برای دیدن کلاینتهایی که MCP را پشتیبانی میکنند.