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

مسئله‌ای که MCP حل می‌کنه

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

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

بدتر از حجم کار، جایی‌‌ست که این کد زندگی می‌کنه. اتصالی که برای دستیار داخلی شرکتت نوشتی، داخل همون دستیار حبس شده. اگه فردا تیم دیگه‌ای بخواد به همون دیتابیس وصل بشه، از صفر شروع می‌کنه. سه تا نشونه‌ی همیشگی این وضعیت رو احتمالاً دیدی:

• هر تیم نسخه‌ی خودش از «اتصال به CRM» رو داره و هیچ‌کدوم دقیقاً مثل اون یکی رفتار نمی‌کنه.
• عوض‌کردن مدل یعنی بازنویسی لایه‌ی ابزارها، چون فرمت تعریف ابزار هر ارائه‌دهنده فرق داره.
• هیچ‌کس دقیقاً نمی‌دونه کدوم دستیار به چه داده‌ای دسترسی داره، چون دسترسی‌ها توی کد پخش شده‌ن.

کاری که MCP می‌کنه اینه که این M×N رو به M+N تبدیل می‌کنه. هر برنامه یک بار زبان مشترک رو یاد می‌گیره، هر سرویس یک بار خودش رو با همون زبان عرضه می‌کنه، و بعد هر کدوم با هر کدوم کار می‌کنه.

MCP دقیقاً چیه

Model Context Protocol یه استاندارد بازه که Anthropic در نوامبر ۲۰۲۴ منتشرش کرد و حالا پیاده‌سازی‌هاش در ابزارهای مختلف وجود داره. زیرساختش JSON-RPC 2.0 هست؛ یعنی چیز عجیبی اختراع نشده، فقط یه قرارداد مشخص روی یه پروتکل پیام‌رسانی شناخته‌شده تعریف شده.

تشبیه رایجش درگاه USB-C هست و تا حدی درسته: قبلش هر دستگاه کابل خودش رو داشت، بعدش یه درگاه مشترک. ولی این تشبیه یه چیز مهم رو جا می‌ندازه. USB-C فقط برق و داده رد می‌کنه؛ MCP علاوه بر انتقال داده، یه واژگان مشترک برای «چه کارهایی می‌شه کرد» و «چه داده‌ای در دسترسه» تعریف می‌کنه. مدل باید بفهمه یه ابزار چه‌کار می‌کنه تا تصمیم بگیره کِی صداش بزنه.

معماری: Host، Client و Server

سه نقش توی MCP وجود داره و قاطی‌کردنشون باعث بیشترین سردرگمی می‌شه. بذار دقیق جداشون کنیم:

1. Host — برنامه‌ایه که کاربر توش با هوش مصنوعی کار می‌کنه: Claude Desktop، یه افزونه‌ی ادیتور، یا اپلیکیشن خودت. Host تصمیم می‌گیره به چه سرورهایی وصل بشه و مجوزها رو از کاربر می‌گیره.
2. Client — داخل Host زندگی می‌کنه و برای هر سرور یکی ساخته می‌شه. یعنی اگه Host به سه سرور وصل باشه، سه تا Client داره. این یک‌به‌یک بودن عمدیه: مرز بین سرورها رو حفظ می‌کنه.
3. Server — قابلیت یا داده‌ای مشخص رو عرضه می‌کنه. می‌تونه یه پروسه‌ی محلی باشه که فقط یه پوشه رو می‌خونه، یا سرویسی از راه دور که به سیستم سازمانی وصله.

ارتباط از چه مسیری می‌گذره

دو تا حالت انتقال وجود داره. برای سرورهای محلی، stdio استفاده می‌شه: Host پروسه‌ی سرور رو اجرا می‌کنه و از طریق ورودی و خروجی استاندارد باهاش حرف می‌زنه. هیچ پورتی باز نمی‌شه و هیچ چیزی از دستگاه بیرون نمی‌ره. برای سرورهای راه دور، Streamable HTTP استفاده می‌شه که جایگزین انتقال SSE قدیمی شده.

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

سه چیزی که یه سرور عرضه می‌کنه

یه سرور MCP قابلیت‌هاش رو در سه شکل عرضه می‌کنه. تفاوتشون فقط فنی نیست؛ تفاوت اصلی اینه که چه کسی کنترل می‌کنه کِی استفاده بشن.

• Tool — عملیه که مدل می‌تونه درخواست اجراش رو بده: ثبت یه رویداد، اجرای یه جست‌وجو، ساختن یه رکورد. کنترلش دست مدله؛ یعنی مدل بر اساس توضیحات تصمیم می‌گیره صداش بزنه.
• Resource — داده‌ای‌ که می‌شه خوندش: محتوای یه سند، یه رکورد مشتری، خروجی یه گزارش. معمولاً برنامه تصمیم می‌گیره چی رو وارد گفت‌وگو کنه، نه مدل.
• Prompt — الگوی ازپیش‌آماده برای یه جریان کاری تکراری. معمولاً کاربر صریحاً انتخابش می‌کنه، مثل یه دستور توی منو.

لازم نیست هر سرور هر سه تا رو داشته باشه. یه سرور خوب فقط کمترین سطح لازم برای مسئله‌ی واقعی رو در اختیار مدل می‌ذاره. سروری که سی تا ابزار مشابه عرضه می‌کنه، عملاً داره کار مدل رو سخت‌تر می‌کنه؛ همون‌طور که یه منوی سی‌صفحه‌ای انتخاب غذا رو سخت‌تر می‌کنه.

اولین سرور رو وصل کن

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

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/me/projects/report-2026"
      ]
    }
  }
}

به مسیر آخر دقت کن. یه پوشه‌ی مشخص داده شده، نه کل خانه‌ی کاربر. این مهم‌ترین تصمیم این فایله: دامنه‌ی دسترسی رو همین‌جا تعیین می‌کنی، نه بعداً. بعد از ذخیره و راه‌اندازی دوباره‌ی برنامه، ابزارهای اون سرور توی رابط ظاهر می‌شن.

اگه با Claude Code کار می‌کنی، همین کار از خط فرمان انجام می‌شه و لازم نیست فایل رو دستی ویرایش کنی:

claude mcp add filesystem \
  -- npx -y @modelcontextprotocol/server-filesystem ~/projects/report-2026

یه سرور ساده خودت بنویس

وقتی سرویس داخلی خودت رو می‌خوای عرضه کنی، نوشتن سرور کار سنگینی نیست. با SDK رسمی، هر ابزار یه اسم، یه توضیح، یه اسکیمای ورودی و یه تابع می‌خواد. مثال زیر یه ابزار برای خوندن فاکتوره:

server.registerTool(
  "get_invoice",
  {
    title: "دریافت فاکتور",
    // این متن را مدل می‌خواند تا تصمیم بگیرد ابزار را صدا بزند یا نه.
    description:
      "یک فاکتور را با شماره‌اش برمی‌گرداند. برای پرسش درباره مبلغ، " +
      "تاریخ یا وضعیت پرداخت یک فاکتور مشخص استفاده شود.",
    inputSchema: { invoiceId: z.string().describe("شماره فاکتور، مثل INV-2026-0142") },
  },
  async ({ invoiceId }) => ({
    content: [{ type: "text", text: await readInvoice(invoiceId) }],
  }),
)

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

این سرور حالا مستقل از هر برنامه‌ایه. همون کد رو هم دستیار داخلی می‌تونه استفاده کنه، هم ادیتور، هم هر ابزار دیگه‌ای که MCP رو می‌فهمه. همون M+N که اولش گفتیم، اینجا عملی می‌شه.

کجا MCP جواب نمی‌ده

هر استانداردی یه محدوده داره و MCP هم دارویِ همه‌ی دردها نیست. چند حالت هست که اضافه‌کردنش فقط پیچیدگی اضافه می‌کنه:

• فقط یک برنامه و یک سرویس داری و قرار نیست بیشتر بشه. M×N وقتی M و N هر دو یک باشن، مسئله‌ای نیست.
• کاری که می‌خوای انجام بشه قطعیه و اصلاً تصمیم‌گیری نمی‌خواد. برای اجرای یه گزارش هر شب، یه اسکریپت کافیه؛ مدل وسط این ماجرا فقط هزینه و عدم‌قطعیت اضافه می‌کنه.
• داده‌ی خیلی حجیم رو باید به‌صورت زنده پردازش کنی. MCP برای رد و بدل‌کردن قابلیت و داده‌ی هدفمند طراحی شده، نه برای جابه‌جایی گیگابایت.

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

امنیت رو بخشی از طراحی حساب کن

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

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