MCP چیست: وصل‌کردن ابزارها به دستیار هوش مصنوعی

آخرین به‌روزرسانی: ۲ مهر ۱۴۰۵

فرض کنید می‌خواهید دستیار هوش مصنوعی‌تان گزارش‌های خطای مخزن کد را بخواند، به دیتابیس آزمایشی کوئری بزند و تقویمتان را ببیند. تا چندی پیش، هر کدام از این اتصال‌ها باید برای هر دستیار جداگانه ساخته می‌شد.

MCP (Model Context Protocol) یک پروتکل باز برای وصل‌کردن ابزارها و منبع‌های داده به دستیارهای هوش مصنوعی است. در ایجنت هوش مصنوعی چیست آن را در یک پاراگراف معرفی کردیم. این‌جا دقیق‌تر می‌بینیم از چه اجزایی ساخته شده، چه چیزهایی را منتقل می‌کند و پیش از وصل‌کردن هر سرور به چه چیزهایی باید فکر کرد.

MCP چه مشکلی را حل می‌کند؟#

مشکل اتصال‌های تکراری را: به‌جای اینکه هر دستیار برای هر سرویس کد جداگانه داشته باشد، هر دو طرف یک بار با یک قرارداد مشترک ساخته می‌شوند.

اگر ۵ دستیار و ۲۰ سرویس داشته باشیم، بدون قرارداد مشترک به صد اتصال جداگانه نیاز داریم. با MCP هر سرویس یک بار «سرور MCP» می‌سازد و هر دستیار یک بار «کلاینت MCP» پیاده می‌کند، و ضرب به جمع تبدیل می‌شود. این پروتکل را Anthropic معرفی و به‌صورت باز منتشر کرد و حالا دستیارها و ابزارهای شرکت‌های مختلف از آن پشتیبانی می‌کنند.

میزبان، کلاینت و سرور چه نقشی دارند؟#

میزبان برنامه‌ای است که شما با آن کار می‌کنید، کلاینت اتصالی است داخل میزبان، و سرور قابلیت‌های یک سرویس را عرضه می‌کند.

• میزبان (Host): دستیار دسکتاپ، ویرایشگر کد یا ایجنت کدنویسی در ترمینال. مدل زبانی و رابط کاربری این‌جاست.
• کلاینت (Client): بخشی داخل میزبان که اتصال به یک سرور را نگه می‌دارد؛ به ازای هر سرور، یک کلاینت.
• سرور (Server): برنامه‌ای که قابلیت‌های یک سرویس یا منبع داده را به زبان MCP عرضه می‌کند. پیام‌ها بین کلاینت و سرور در قالب JSON-RPC رد و بدل می‌شوند.

نکته‌ی مهم این نمودار: مدل مستقیم با سرور حرف نمی‌زند. مدل می‌گوید «این ابزار را با این ورودی صدا بزن»، میزبان تصمیم می‌گیرد اجرا کند یا نه، و پنجره‌ی تأیید کاربر همین‌جا قرار می‌گیرد.

سرور محلی یا راه‌دور؟#

سرورهای راه‌دور معمولاً با یک مرحله‌ی ورود و اجازه‌دادن وصل می‌شوند. شکل دقیق افزودن سرور از میزبانی به میزبان دیگر فرق می‌کند؛ راهنمای همان برنامه را ببینید.

سرور MCP چه چیزهایی عرضه می‌کند؟#

سه نوع قابلیت: ابزار، منبع و پرامپت. فرقشان در این است که چه کسی تصمیم می‌گیرد از آن‌ها استفاده شود:

ابزارها پرکاربردترین بخش‌اند. هر ابزار یک نام، یک توضیح و یک طرح ورودی به شکل JSON Schema دارد و سرور فهرستشان را این‌طور به کلاینت می‌دهد:

{
  "name": "search_orders",
  "description": "جستجوی سفارش‌ها با شماره‌ی سفارش. فقط خواندنی.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "order_id": { "type": "integer", "description": "شماره‌ی سفارش" }
    },
    "required": ["order_id"]
  }
}

این توضیح را مدل می‌خواند و بر اساسش تصمیم می‌گیرد کی و چطور ابزار را صدا بزند. توضیح دقیق، ابزار را درست‌تر به کار می‌اندازد؛ توضیح بدخواهانه می‌تواند مدل را گمراه کند.

MCP در عمل به چه کاری می‌آید؟#

به هر کاری که دستیار برایش باید داده‌ی بیرونی ببیند یا در سیستم دیگری کاری انجام دهد. چند نمونه برای برنامه‌نویس و مدیر سایت:

• مخزن کد و گزارش‌های خطا: ایجنت گزارش را می‌خواند، کد مرتبط را پیدا می‌کند و تغییر پیشنهاد می‌دهد.
• دیتابیس آزمایشی: دیدن ساختار جدول‌ها و پرسیدن سؤال از داده، با کاربر فقط‌خواندنی.
• مستندات: دسترسی به مستندات به‌روز یک کتابخانه به‌جای تکیه بر حافظه‌ی مدل.
• مرورگر: باز کردن صفحه‌ی در حال توسعه و خواندن خطاهای کنسول.
• کار روزمره: تقویم، یادداشت‌ها، پوشه‌های اسناد و ابزار مدیریت پروژه.

اگر سرویسی که هر روز با آن کار می‌کنید API دارد، احتمال زیادی هست که سرور MCP هم برایش نوشته شده باشد. رسمی یا غیررسمی بودنش را بررسی کنید.

ساختن سرور اختصاصی#

اگر سیستمی داخلی دارید، مثلاً پنل سفارش‌های خودتان، ساختن سرور MCP برایش کار بزرگی نیست و کیت‌های توسعه‌ی رسمی برای چند زبان منتشر شده است. ابزارها را کوچک و مشخص بسازید («وضعیت سفارش» بهتر از «اجرای هر کوئری دلخواه»)، محدودیت‌ها را در توضیح بنویسید، و ورودی و دسترسی را در خود سرور بررسی کنید. ایجنت‌ها در نوشتن چنین سروری کمک خوبی‌اند؛ روش کار امن با آن‌ها در ایجنت کدنویسی آمده است.

پیش از وصل‌کردن سرور MCP چه چیزهایی را بررسی کنیم؟#

منبع سرور، دسترسی‌هایش و اینکه به محتوای برگشتی‌اش اعتماد نکنید. سرور MCP کدی است که با دسترسی شما اجرا می‌شود یا به حساب‌های شما وصل است؛ همان دقت نصب یک افزونه‌ی وردپرس را لازم دارد:

1. منبع: سرور رسمی سازنده‌ی سرویس، یا کدی که خودتان خوانده‌اید.
2. کمترین دسترسی: توکنی که به سرور می‌دهید فقط همان دسترسی لازم را داشته باشد؛ برای دیتابیس، کاربر فقط‌خواندنی.
3. تأیید را خاموش نکنید، به‌خصوص برای ابزارهایی که می‌نویسند، می‌فرستند یا پاک می‌کنند.
4. به محتوای برگشتی اعتماد نکنید: ایمیل، صفحه‌ی وب یا توضیح یک ابزار ممکن است دستور پنهان داشته باشد. این همان تزریق پرامپت است، از راه ابزار.
5. سرورهای کم و لازم: تعریف هر ابزار بخشی از پنجره‌ی متن را می‌گیرد و ابزارهای زیاد و مشابه، مدل را در انتخاب گیج می‌کنند.
6. نسخه‌ی مشخص: سرور را از منبع معلوم و با نسخه‌ی معلوم نصب کنید تا تغییری بی‌خبر به دستتان نرسد.

این موضوع به کجا می‌رود#

جهت روشن این است که MCP به روش رایج اتصال دستیارها به سرویس‌ها تبدیل شده و سرویس‌های بیشتری سرور رسمی خودشان را منتشر می‌کنند، به‌خصوص سرورهای راه‌دور با ورود استاندارد. خود پروتکل هم هنوز در حال تکامل است و مشخصاتش به‌روز می‌شود.

برای آمادگی:

• اگر سیستم داخلی دارید، API تمیز و مستند برایش بسازید؛ افزودن سرور MCP روی آن بعداً ساده است.
• جزئیات فنی را از مستندات رسمی پروتکل بخوانید، نه از خلاصه‌های قدیمی.
• فهرستی از سرورهای وصل‌شده و دسترسی هر کدام نگه دارید و گاهی مرورش کنید.

خلاصه#

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