Model Context Protocol (MCP)

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

JSON-RPC 2.0 Open Standard Client–Server
اجرای زنده در Sandbox

معرفی MCP

MCP را می‌توان به پورت USB-C برای اتصال هوش مصنوعی تشبیه کرد: همان‌طور که USB-C یک رابط فیزیکی یکسان برای اتصال دستگاه‌های مختلف است، MCP یک رابط نرم‌افزاری یکسان برای اتصال مدل‌های زبانی به منابع داده و ابزارهای مختلف فراهم می‌کند. پیش از MCP، هر ادغام (integration) بین یک دستیار هوش مصنوعی و یک سیستم خارجی به‌صورت اختصاصی و غیرقابل‌استفاده‌ی مجدد نوشته می‌شد. MCP این الگو را می‌شکند: هر سروری که مطابق MCP نوشته شود، توسط هر برنامه‌ی میزبانی که از MCP پشتیبانی می‌کند، قابل استفاده است.

چرا مهم است؟ اگر کسب‌وکار شما یک سرور MCP بسازد، دیگر نیازی نیست برای هر دستیار هوش مصنوعی جدید (Claude، یک IDE هوشمند، یک ایجنت سفارشی) یکپارچه‌سازی جداگانه بنویسید.

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

معماری MCP از سه نقش مجزا تشکیل شده است:

  • Host — برنامه‌ای که کاربر مستقیماً با آن کار می‌کند (مثل یک دستیار هوش مصنوعی یا یک IDE). Host مسئول مدیریت مجوزها و هماهنگی بین چند اتصال است.
  • Client — درون Host زندگی می‌کند و یک اتصال ۱ به ۱ و state‌دار (stateful) با دقیقاً یک Server نگه می‌دارد.
  • Server — برنامه‌ای که شما می‌سازید؛ داده‌ها و قابلیت‌های خودتان را از طریق Resources، Tools و Prompts در معرض دید Host قرار می‌دهد.

یک Host می‌تواند همزمان به چند Server مختلف متصل باشد (مثلاً یکی برای انبار، یکی برای CRM)، و هرکدام از این اتصال‌ها کاملاً مستقل و ایزوله هستند.

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

Resources

داده‌هایی که Server در معرض دید Host قرار می‌دهد — مثل یک سند، رکورد پایگاه‌داده یا فایل کانفیگ. هر Resource با یک URI یکتا شناسایی می‌شود و معمولاً application-controlled است، یعنی این برنامه‌ی میزبان است که تصمیم می‌گیرد چه زمانی آن را بخواند (شبیه یک درخواست GET).

Tools

توابعی که مدل زبانی می‌تواند خودش تصمیم بگیرد اجرا کند (model-controlled) — مثل check_inventory() یا book_appointment(). هر Tool یک نام، توضیح، و یک JSON Schema برای ورودی و خروجی دارد. مدل بر اساس همین توضیح تصمیم می‌گیرد چه زمانی از Tool استفاده کند، پس دقت در نوشتن description اهمیت زیادی دارد.

Prompts

الگوهای آماده و قابل‌استفاده مجدد که معمولاً user-controlled هستند — کاربر آن‌ها را آگاهانه انتخاب می‌کند (مثلاً به‌شکل یک دستور سریع در رابط کاربری). Promptها به استانداردسازی نحوه‌ی تعامل بهینه با Server شما کمک می‌کنند.

Sampling و Roots (پیشرفته)

علاوه بر سه رکن اصلی، MCP دو قابلیت پیشرفته هم دارد: Sampling به Server اجازه می‌دهد در جهت معکوس، از مدل زبانیِ Host بخواهد متنی تولید کند؛ و Roots مرزهای فایل‌سیستمی را که Server مجاز به دسترسی به آن‌هاست مشخص می‌کند.

لایه‌های انتقال (Transports)

Transportکاربردتوضیح
stdioسرورهای محلیارتباط از طریق ورودی/خروجی استاندارد پردازه؛ ساده‌ترین حالت، مناسب زمانی که Server روی همان دستگاه کاربر اجرا می‌شود.
HTTP-based (Streamable HTTP)سرورهای remoteارتباط از طریق HTTP، مناسب برای سرورهایی که به‌صورت سرویس مستقل و از راه دور اجرا می‌شوند و نیاز به احراز هویت دارند.

چرخه عمر اتصال

تمام پیام‌های MCP از فرمت JSON-RPC 2.0 پیروی می‌کنند (سه نوع پیام: request، response و notification). یک اتصال معمولی این چرخه را طی می‌کند:

  1. initialize — Client نسخه‌ی پروتکل و قابلیت‌های خود را به Server اعلام می‌کند
  2. Server با نسخه‌ی پروتکل و قابلیت‌های خودش پاسخ می‌دهد
  3. Client یک notification از نوع initialized می‌فرستد تا اتصال را نهایی کند
  4. عملیات عادی آغاز می‌شود: tools/list، tools/call، resources/list، resources/read، prompts/list، prompts/get
  5. در پایان، اتصال به‌صورت تمیز بسته می‌شود

شروع سریع: ساخت یک سرور ساده

نمونه‌ی زیر با پکیج رسمی پایتون یک سرور MCP با یک Tool ساده می‌سازد:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("Store Inventory")

@mcp.tool()
def check_inventory(sku: str) -> dict:
    """بررسی موجودی یک محصول بر اساس SKU"""
    # اینجا به دیتابیس واقعی خودتان وصل شوید
    return {"sku": sku, "in_stock": True, "quantity": 12}

if __name__ == "__main__":
    mcp.run()

همین چند خط کافی است تا هر Host سازگار با MCP بتواند این ابزار را کشف و در زمان مناسب فراخوانی کند — بدون هیچ کد یکپارچه‌سازی اضافه‌ای.

احراز هویت و امنیت

در transport نوع stdio، مرز امنیتی همان مرز پردازه‌ی سیستم‌عامل است. اما برای Serverهای remote روی HTTP، رعایت این نکات ضروری است:

  • از یک مکانیزم استاندارد احراز هویت (مثل OAuth 2.1) برای تایید هویت Client استفاده کنید
  • هر Tool را با کمترین دسترسی لازم تعریف کنید؛ هرگز یک Tool «همه‌کاره» با دسترسی کامل به دیتابیس نسازید
  • تمام فراخوانی‌های Tool را لاگ کنید تا در صورت رفتار غیرعادی قابل ردیابی باشند
  • روی Serverهای عمومی، محدودیت نرخ درخواست (Rate Limiting) اعمال کنید

SDKهای رسمی

SDKهای رسمی برای زبان‌های اصلی در دسترس هستند، از جمله پکیج mcp برای Python و @modelcontextprotocol/sdk برای TypeScript/JavaScript. SDKهای غیررسمی و جامعه‌محور برای زبان‌های دیگر هم به‌مرور در حال توسعه‌اند. توصیه می‌شود همیشه با آخرین نسخه‌ی SDK رسمی شروع کنید.

بهترین شیوه‌ها

  • ابزارها را کوچک و تک‌منظوره نگه دارید — یک Tool، یک وظیفه‌ی مشخص
  • توضیح دقیق بنویسید — مدل تصمیم استفاده از Tool را بر اساس description می‌گیرد، نه نام آن
  • خروجی ساخت‌یافته برگردانید — JSON با ساختار ثابت، نه متن آزاد غیرقابل پیش‌بینی
  • خطاها را واضح گزارش کنید — پیام خطای قابل‌فهم برای مدل، نه فقط کد وضعیت
  • نسخه‌بندی کنید — تغییرات ساختاری در Toolها را با احتیاط و مستندسازی انجام دهید

سوالات متداول

آیا MCP جایگزین REST API است؟

نه دقیقاً. MCP یک لایه‌ی استاندارد روی منطق موجود شماست؛ در پشت صحنه‌ی یک Tool معمولاً همان API یا دیتابیس فعلی شما فراخوانی می‌شود.

آیا MCP فقط برای مدل‌های Anthropic کار می‌کند؟

خیر. MCP یک استاندارد باز است و هدف آن سازگاری با هر مدل یا برنامه‌ی میزبانی است که پیاده‌سازی‌اش را پشتیبانی کند.

تفاوت MCP با UCP در OpenCommerce چیست؟

MCP برای اتصال امن و کنترل‌شده به داده‌های داخلی شماست؛ UCP برای تراکنش‌های تجاری عمومی (جست‌وجو، سبد خرید، پرداخت) طراحی شده که هر ایجنتی می‌تواند از آن استفاده کند.