پروتکل MCP چگونه لایهٔ استدلال را از اجرای ابزارهای AI جدا می‌کند؟

تصور کنید هر بار که می‌خواهید ابزار جدیدی را به دستیار هوش مصنوعی خود اضافه کنید، مجبور باشید تمام کدهای اتصال را از نو بنویسید. پروتکل زمینهٔ مدل (MCP) این اصطکاک را حذف می‌کند تا توسعه‌دهندگان بتوانند قابلیت‌های خود را یک‌بار تعریف کرده و در هر کلاینت سازگاری به اشتراک بگذارند.

مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — در درک زبان و استدلال فوق‌العاده‌اند، اما به‌طور پیش‌فرض دسترسی به پایگاه‌داده شما، فایل‌های محلی یا APIهای داخلی ندارند. بر اساس مستندات آنتروپیک (Anthropic)، توسعه‌دهندگان پیش از این مجبور بودند برای هر ترکیبِ مدل، منبع داده و سیستم تجاری، یک اتصال سفارشی بسازند؛ رویکردی که با رشد تعداد ابزارها، به سرعت غیرقابل مدیریت می‌شد.

آنتروپیک در نوامبر ۲۰۲۴ پروتکل MCP را معرفی کرد تا این پراکندگی را پایان دهد. این پروتکل شبیه به «USB-C برای هوش مصنوعی» عمل می‌کند؛ یک لایه اتصال استاندارد که استدلال مدل را از اجرای واقعی ابزار جدا می‌کند. این رویکرد در واقع تلاشی برای ایجاد یک استاندارد جهانی است؛ همان‌طور که در بررسی جامع ما درباره استانداردسازی اتصال مدل‌های زبانی به ابزارهای خارجی تحلیل کردیم، این پروتکل مسیر توسعه عامل‌های هوشمند را هموار می‌کند. همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، استانداردسازی لایه‌های دسترسی اولین قدم برای کنترل‌پذیری بیشتر در سامانه‌های عامل‌محور است. از طریق MCP، یک اپلیکیشن هوش مصنوعی می‌تواند بدون کدنویسی مجدد، به فایل‌های محلی، پایگاه‌داده‌ها، موتورهای جست‌وجو و سیستم‌های تجاری داخلی متصل شود.

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

یک دستیار مهندسی را تصور کنید که باید مستندات استقرار را بخواند، تعداد تست‌های شکست‌خورده را بررسی کند و ریسک انتشار را محاسبه نماید. بدون MCP، توسعه‌دهنده باید یک رابط «فراخوانی تابع» (Function Calling) اختصاصی برای یک مدل خاص بسازد. اگر تیم دیگری بخواهد همین قابلیت را در یک IDE یا پلتفرم عامل داخلی استفاده کند، باید دوباره اتصال را پیاده‌سازی کند. در حالی که قابلیت زیرساختی یکسان است، اما کدهای اتصال به صورت نمایی زیاد می‌شوند.

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

• دغدغه‌های اپلیکیشن هوش مصنوعی: تعامل با کاربر، انتخاب مدل، استدلال و تجربه تأیید عملیات.
• دغدغه‌های سرور MCP: قابلیت‌های تجاری، اعتبارسنجی ورودی، دسترسی به داده‌ها و اجرای ابزار.

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

معماری هسته

یک تعامل در MCP شامل چهار جزء اصلی است:

• میزبان MCP (Host): اپلیکیشنی که کاربر با آن تعامل می‌کند (مثل یک IDE هوشمند یا دستیار دسکتاپ).
• کلاینت MCP: جزئی در میزبان که اتصال به سرور را مدیریت می‌کند.
• سرور MCP: سرویسی که قابلیت‌های خاص (مثل دسترسی به GitHub، Jira یا سیستم فایل محلی) را ارائه می‌دهد.
• حمل‌کننده (Transport): لایه ارتباطی پیام‌ها؛ که شامل ورودی/خروجی استاندارد (stdio) برای اتصالات محلی و HTTP جریان‌پذیر (Streamable HTTP) برای سرورهای راه دور است.

مفاهیم پایه: ابزارها، منابع و پرامپت‌ها

یک سرور MCP سه مفهوم اساسی را به کلاینت ارائه می‌دهد:

• ابزارها (Tools): توابع قابل اجرا که می‌توانند تغییر ایجاد کنند (مانند ایجاد تیکت پشتیبانی یا اجرای تست). به دلیل احتمال تغییر وضعیت، میزبان باید این اقدامات را به کاربر نمایش داده و تأیید بگیرد.
• منابع (Resources): اطلاعات فقط-خواندنی که در بستر متن مدل قرار می‌گیرند (مانند مستندات محصول یا رکورد یک پایگاه‌داده). این مورد شبیه به خواندن داده از یک endpoint از نوع GET است.
• پرامپت‌ها (Prompts): قالب‌های تعاملی قابل استفاده مجدد که میزبان را در یک گردش‌کار خاص (مثلاً بررسی یک حادثه) راهنمایی می‌کنند.

تفاوت MCP با RAG و فراخوانی تابع

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

پیاده‌سازی با FastMCP

توسعه‌دهندگان با استفاده از SDK پایتونی FastMCP می‌توانند توابع پایتون را مستقیماً به ابارهای MCP تبدیل کنند. برای پایداری، توصیه می‌شود وابستگی‌ها زیر نسخه ۲ (مثلاً mcp[cli]>=1.27,<2) تثبیت شوند زیرا نسخه ۲ هنوز در پیش‌انتشار است. طبق گزارش‌های فنی، در یک سرور ارزیابی ریسک، تابعی تعریف می‌شود که تعداد فایل‌های تغییریافته و تست‌های شکست‌خورده را گرفته و بر اساس نقاط برش (Thresholds) مشخص، سطح ریسک را «پایین»، «متوسط» یا «بالا» برمی‌گرداند.

فرآیند ساخت شامل چهار مرحله است:
۱. راه‌اندازی پروژه: نصب SDK از طریق pip.
۲. تعریف سرور: استفاده از دکوراتورهای @mcp.tool() برای توابع، @mcp.resource() برای داده‌ها و @mcp.prompt() برای قالب‌ها.
۳. تست: استفاده از MCP Inspector برای عیب‌یابی و بررسی نتایج ساختاریافته.
۴. یکپارچه‌سازی: اتصال به کلاینت‌هایی مثل Claude Code با دستور claude mcp add.

کانتینری‌سازی سرور MCP

برای اطمینان از تکرارپذیری، سرورها اغلب با Docker بسته‌بندی می‌شوند. در این حالت، استفاده از پرچم -i (تعاملی) ضروری است تا ورودی استاندارد برای ارتباطات MCP باز بماند. یک نکته فنی حیاتی این است که لاگ‌های برنامه نباید به خروجی استاندارد (stdout) فرستاده شوند، زیرا این مسیر برای پیام‌های پروتکل رزرو شده است؛ تمام لاگ‌های تشخیصی باید به خطای استاندارد (stderr) هدایت شوند.

انتقال به سرورهای راه دور

سرورهای محلی برای ابزارهای توسعه عالی‌اند، اما در موارد زیر سرورهای راه دور لازم هستند:

• زمانی که چندین کاربر به یک قابلیت نیاز دارند.
• دسترسی به سیستم‌های مشترک سازمانی.
• نیاز به احراز هویت متمرکز، نظارت و مقیاس‌دهی.

در استقرار راه دور، حمل‌کننده به streamable-http تغییر می‌کند که الزامات تولیدی مانند رمزنگاری TLS و محدودیت نرخ درخواست (Rate Limiting) را می‌طلبد.

حفاظ‌ها و ملاحظات امنیتی

MCP به‌تنهایی امنیت ابزار را تضمین نمی‌کند؛ توسعه‌دهندگان باید موارد زیر را اعمال کنند:

• حداقل دسترسی: سرورهای فقط-خواندنی نباید دسترسی تغییر داده‌های تولید داشته باشند.
• اعتبارسنجی ورودی: هرگز به آرگومان‌های تولید شده توسط مدل اعتماد نکنید و مقادیر را به‌صورت قطعی بررسی کنید.
• حضور انسان در چرخه (HITL): اقدامات حساس (حذف، استقرار) باید صراحتاً توسط کاربر تأیید شوند.
• محدودیت سیستم فایل: استفاده از لیست‌های سفید (Allowlist) برای جلوگیری از خروج از دایرکتوری‌های مجاز.
• حفاظت از اسرار: اعتبارنامه‌ها باید در متغیرهای محیطی باشند و هرگز در پاسخ‌های ابزار بازگردانده نشوند.

اشتباهات رایج در طراحی

• ابزار غول‌پیکر: ساخت یک ابزار execute_action با ورودی آزاد؛ به‌جای آن ابزارهای اتمیک و کوچک بسازید.
• توصیفات مبهم: استفاده از عبارت «پردازش داده‌ها» به‌جای توصیفات دقیق؛ توصیفات در واقع همان پرامپتی هستند که مدل را برای انتخاب ابزار هدایت می‌کنند.
• تورم داده‌ها: بازگرداندن کل پاسخ API به‌جای اطلاعات ساختاریافته مورد نیاز مدل؛ این کار پنجره متنی را هدر می‌دهد.
• خطای احراز هویت: سپردن مدیریت دسترسی به استدلال مدل؛ احراز هویت باید توسط منطق قطعی برنامه اجرا شود.

سلسله‌مراتب عامل‌محور

در یک سامانه کامل عامل‌محور، MCP نقش «دست‌ها» را ایفا می‌کند، در حالی که سیستم پیرامونی «مغز» است و توالی زیر را مدیریت می‌کند:
درخواست کاربر $\rightarrow$ اپلیکیشن AI $\rightarrow$ برنامه‌ریزی $\rightarrow$ بررسی سیاست‌ها $\rightarrow$ کلاینت MCP $\rightarrow$ سرور MCP $\rightarrow$ سیستم خارجی $\rightarrow$ نتیجه ابزار $\rightarrow$ اعتبارسنجی $\rightarrow$ پاسخ نهایی.

MCP صرفاً تضمین می‌کند که اتصال به ابزارها استاندارد و پیش‌بینی‌پذیر است، بدون اینکه جایگزین سیاست‌ها یا مغز برنامه‌ریز عامل شود.

گام بعدی شما

• اگر توسعه‌دهنده هستید، SDK پایتون FastMCP را نصب کنید و اولین ابزار محلی خود را برای Claude Code بسازید.
• برای عیب‌یابی ابزارها، حتماً از MCP Inspector استفاده کنید تا پیام‌های JSON-RPC را تحلیل کنید.
• در طراحی ابزارها، توصیفات (Docstrings) را با دقت بنویسید چون مستقیماً بر دقت انتخاب ابزار توسط مدل اثر می‌گذارد.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.