MCP چیست در هوش مصنوعی؟ client، server و tool

MCP (Model Context Protocol) یک قرارداد استاندارد است برای اینکه یک برنامهٔ هوش مصنوعی بتواند از بیرون داده و ابزار بگیرد؛ همان نقشی که برای ویرایشگرهای کد Language Server Protocol دارد. این مقاله بر پایهٔ مشخصهٔ رسمی (نسخهٔ 2026-07-28 که در تاریخ ۱۹ اکتبر ۲۰۲۶ «latest» بود) مفاهیم client، server، tool و resource را توضیح می‌دهد و می‌گوید چه وقت اتصال ابزار به عامل با MCP منطقی است. جزئیات پروتکل با نسخه تغییر می‌کند؛ هر پیاده‌سازی باید نسخهٔ خود را از مشخصه بخواند. ما سرور MCP نساخته یا آزمایش نکرده‌ایم، ادعای سازگاری یک محصول خاص نداریم و امنیت را «تضمین» نمی‌کنیم. برای انتخاب فناوری انتخاب تکنولوژی و برای آشنایی با API API چیست را ببینید.

MCP چیست؟

مشخصه می‌گوید MCP یک پروتکل باز است که ادغام یکپارچه بین برنامه‌های LLM و منابع داده و ابزار خارجی را ممکن می‌کند. پیام‌ها در قالب JSON-RPC 2.0 رد و بدل می‌شوند و سه نقش دارند:

سه ابزار پایه: tool، resource، prompt

• Tool: تابعی که مدل می‌تواند اجرا کند (مثلاً «ایجاد تیکت»)؛ هر ابزار نام و inputSchema دارد. مشخصه ابزارها را «model-controlled» می‌نامد، یعنی مدل می‌تواند بر اساس زمینه و prompt کاربر آن‌ها را کشف و فراخوانی کند.
• Resource: زمینه و داده برای کاربر یا مدل (مثلاً محتوای یک فایل یا رکورد).
• Prompt: پیام‌ها و گردش‌های الگو که کاربر می‌تواند انتخاب کند.

کلاینت هم می‌تواند قابلیت‌هایی مثل elicitation (درخواست اطلاعات بیشتر از کاربر به ابتکار سرور) ارائه کند. مشخصه افزونه‌های اختیاری (مثل اجرای ناهمزمان کارهای طولانی یا «مهارت‌ها» از طریق MCP) را هم نام می‌برد که فقط با پشتیبانی هر دو سمت فعال می‌شوند.

یک فراخوانی چطور پیش می‌رود؟

1. کلاینت قابلیت‌ها را از سرور کشف می‌کند و فهرست ابزارها را با درخواست tools/list می‌گیرد (فهرست می‌تواند صفحه‌بندی و کش شود).
2. مدل بر اساس prompt و توضیح ابزارها تصمیم می‌گیرد کدام ابزار را فراخوانی کند.
3. host نمایش و تأیید را اعمال می‌کند؛ مشخصه می‌گوید برای ایمنی همیشه باید یک انسان در حلقه با امکان رد باشد، و برنامه‌ها باید نشان دهند کدام ابزارها در دسترس مدل است و هنگام فراخوانی نشانگر بصری و پرسش تأیید بدهند.
4. کلاینت tools/call را با نام و آرگومان‌ها می‌فرستد و نتیجه (متن یا ساختار، با پرچم خطا) برمی‌گردد.

نکتهٔ معماری: هر کلاینت فقط با یک سرور حرف می‌زند، و طبق اصول طراحی «سرور نباید بتواند کل مکالمه را ببیند یا به سرور دیگر نگاه کند»؛ تاریخچه در host می‌ماند و تعامل بین سرورها را host کنترل می‌کند.

چه وقت MCP منطقی است؟

• چند برنامه، یک ابزار: اگر یک ابزار (مثلاً دسترسی به تیکت‌ها) را می‌خواهید در چند برنامهٔ هوش مصنوعی استفاده کنید، یک سرور MCP به‌جای یک یکپارچه‌سازی اختصاصی برای هر برنامه کافی است.
• ابزار قابل‌کشف برای عامل: وقتی مدل باید خودش انتخاب کند کدام ابزار را بزند و فهرست ابزارها در طول زمان تغییر می‌کند.
• مرز روشن: وقتی می‌خواهید دسترسی به یک سیستم را در یک سرور با مجوزهای مشخص جمع کنید و host فقط همان را ببیند.

چه وقت لازم نیست؟

• اگر فقط یک تابع ساده برای یک برنامه دارید، function calling مستقیم همان کار را ساده‌تر می‌کند و لایهٔ اضافه ندارد.
• اگر دسترسی باید کاملاً بسته و ثابت باشد و فهرست ابزار هیچ‌وقت عوض نمی‌شود، یک API معمولی با مجوز دقیق کافی است (برای API API چیست را ببینید).
• اگر نمی‌توانید به سرور MCP اعتماد کنید (ناشناس یا بدون مالک روشن)، اتصال آن به عامل ریسک است و نباید فقط چون «استاندارد است» وصلش کنید.

این قاعده‌ها جمع‌بندی نویسنده از مشخصه است؛ مشخصه خودش نمی‌گوید «کی استفاده کنید». ما هیچ محصول خاصی را «سازگار با MCP» توصیه یا رتبه‌بندی نمی‌کنیم.

امنیت و اعتماد

مشخصه صراحتاً می‌گوید MCP «دسترسی دلخواه به داده و مسیرهای اجرای کد» ایجاد می‌کند و باید با احتیاط به کار رود. اصول کلیدی آن:

• رضایت و کنترل کاربر: کاربر باید صریحاً با دسترسی به داده و عملیات موافقت کند و بفهمد چه می‌شود؛ رابط روشن برای بازبینی و تأیید لازم است.
• حریم داده: host باید پیش از اشتراک داده کاربر با سرور رضایت صریح بگیرد و دادهٔ منبع را بدون رضایت جای دیگر نفرستد.
• ایمنی ابزار: ابزارها اجرای کد دلخواه‌اند؛ توضیح رفتار و annotation آن‌ها باید نامطمئن فرض شود مگر از سرور معتمد گرفته شده باشد؛ پیش از هر فراخوانی رضایت صریح لازم است.

مشخصه می‌گوید خودِ پروتکل نمی‌تواند این اصول را اجرا کند؛ پیاده‌ساز باید رضایت، مجوز و کنترل دسترسی را در برنامه بسازد. نتیجه: «MCP دارد» یعنی «راه اتصال استاندارد دارد»، نه «امن است». برای هر سرور بپرسید: مالکش کیست؟ چه دسترسی‌ای دارد؟ چه داده‌ای می‌خواند؟ آیا تأیید انسانی برای عملیات نوشتن وجود دارد؟

آزمون کوچک

1. یک سرور MCP فقط‌خواندنی و محلی با داده ساختگی انتخاب یا بسازید.
2. در یک host، فقط همان را وصل کنید و فهرست ابزارها را ببینید.
3. یک وظیفه بدهید و بررسی کنید چه ابزارهایی صدا زده می‌شود و تأیید کجا نمایش داده می‌شود.
4. توضیح ابزار را عمداً گمراه‌کننده کنید و ببینید رفتار مدل چطور تغییر می‌کند (برای فهم ریسک «توضیح نامطمئن»).
5. تصمیم بگیرید آیا برای کار واقعی ارزش اضافه‌ای نسبت به فراخوانی مستقیم تابع دارد.

اشتباهات رایج

• فرض اینکه هر سرور MCP «رسمی» یا «امن» است.
• اتصال سرور با دسترسی نوشتن بدون تأیید انسانی.
• اعتماد به توضیح ابزار به‌عنوان قرارداد رفتار.
• اتصال چند سرور به یک host بدون بازبینی اینکه هر کدام چه داده‌ای می‌بیند.
• استفاده از MCP برای کاری که یک فراخوانی ساده کفایت می‌کند.
• تکیه بر یک نسخهٔ مشخصهٔ قدیمی.

چک‌لیست

1. نسخهٔ مشخصه و تاریخ مراجعه ثبت شده است.
2. مالک و دسترسی هر سرور MCP روشن و مورد اعتماد است.
3. تأیید انسانی برای عملیات نوشتن و حساس وجود دارد.
4. داده‌ای که به سرور می‌رسد حداقلی و با رضایت است.
5. توضیح ابزار نامطمئن فرض شده است.
6. مزیت MCP نسبت به فراخوانی مستقیم سنجیده شده است.

برای آمادگی تولید نرم‌افزار آمادهٔ تولید را هم ببینید.

منابع و مراجع

• Model Context Protocol Specification (version 2026-07-28) — Model Context Protocol، 2026-10-19.
• Architecture — Model Context Protocol، 2026-10-19.
• Tools — Model Context Protocol، 2026-10-19.