«یک‌بار تعریف، همه‌جا اجرا»؛ رویکرد MCP در اتصال ابزارهای هوش مصنوعی

اگر توسعه‌دهنده‌ای هستید که برای هر پروژه جدید، مجبورید کدهای واسط (Glue Code) تکراری بنویسید، دوران این دشواری به پایان رسیده است. «نوشتن کدهای واسط منحصربه‌فرد برای هر پروژه»، برای مدت‌ها یک الزام خسته‌کننده در ساخت ابزارهای سفارشی برای عامل‌های هوش مصنوعی بود. آنتروپیک (Anthropic) در نوامبر ۲۰۲۴ با معرفی پروتکل زمینهٔ مدل (Model Context Protocol یا MCP)، این پراکندگی را حل کرد. MCP استانداردی است که ابزارها را به‌صورت سرورهایی تعریف می‌کند که برای هر کلاینت سازگاری در دسترس هستند.

مشکلی که MCP حل می‌کند

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

پروتکل MCP این همگام‌سازی دستی را با تبدیل ابزار به یک سرور مستقل حذف می‌کند. این رویکرد به اپلیکیشن‌های متعدد اجازه می‌دهد تا بدون نیاز به نوشتن کدهای یکپارچه‌سازی جدید برای هر جفت اتصال، به یک «منبع حقیقت واحد» (Single Source of Truth) متصل شوند. درست مثل اینکه به‌جای ساختن یک پریز برق متفاوت برای هر وسیله در خانه، از یک استاندارد جهانی استفاده کنید تا هر دستگاهی با یک اتصال ساده کار کند. این رویکرد در واقع جایگزینی برای روش‌های پراکنده و سنتی اتصال داده به مدل‌هاست که پیش از این باعث پیچیدگی زیرساخت‌ها می‌شد.

پذیرش در صنعت

پذیرش این پروتکل در صنعت پس از عرضه اولیه بسیار سریع بود. شرکت‌های OpenAI و گوگل (Google) هر دو تنها چند ماه پس از انتشار، این پروتکل را پذیرفتند.

در دسامبر ۲۰۲۵، آنتروپیک پروتکل MCP را به بنیاد هوش مصنوعی عامل‌محور (Agentic AI Foundation) اهدا کرد. این یک پروژه تحت بنیاد لینوکس و مستقل از فروشندگان (Vendor-neutral) است که با همکاری Block و OpenAI بنیان‌گذاری شده است. این انتقال، پروتکل یک شرکت واحد را به یک زیرساخت مشترک صنعتی تبدیل کرد و به این ترتیب مقیاس‌پذیری گردش‌های کاری AI را در سطح کل صنعت تسهیل نمود.

پیاده‌سازی فنی

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

• یکپارچگی SDK: توسعه‌دهندگان از @modelcontextprotocol/sdk برای تعریف سرور استفاده می‌کنند. یک سرور معمولی با یک نام و نسخه مقداردهی می‌شود (مثلاً weather-server نسخه 1.0.0).
• اعتبارسنجی طرح‌واره: به‌جای نوشتن دستی JSON schema، این پروتکل از اعتبارسنج‌های Zod برای تعریف الزامات ورودی استفاده می‌کند. سپس SDK این اعتبارسنج‌های Zod را به طرح‌واره‌های مورد نیاز تبدیل می‌کند.
• لایه انتقال: سرورها معمولاً از طریق StdioServerTransport متصل می‌شوند که به کلاینت اجازه می‌دهد سرور را به‌عنوان یک زیرفرآیند (Subprocess) اجرا کند.
• ثبت ابزار: ابزارها با یک عنوان، یک توضیحات و یک طرح‌واره ورودی ثبت می‌شوند. برای مثال، ابزار get_weather ممکن است یک رشته متنی برای city (شهر) به‌عنوان ورودی بگیرد تا دما را برحسب سلسیوس برگرداند.

جزئیات حیاتی و تله‌های پیاده‌سازی

یک نکته حیاتی در پیاده‌سازی، نقطه ورود (Entrypoint) است. یک اشتباه رایج، استفاده از await در سطح بالای فایل (Top-level await) در نقطه ورود سرور است (مثلاً await server.connect(transport)). اگرچه این کد ممکن است از نظر بررسی نوع (Type-check) درست باشد، اما فرآیند اجرا، فایل را به فرمتی از ماژول تبدیل می‌کند که از top-level await پشتیبانی نمی‌کند. این اتفاق باعث کرش کردن فرآیند پیش از آن می‌شود که سرور بتواند به درخواست‌ها گوش دهد (Listen).

راهکار ضروری برای اطمینان از شنود صحیح سرور، قرار دادن منطق اتصال در یک تابع async main() است.

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

• توضیحات مبهم: این تصور که توضیحات ابزار MCP اهمیت کمتری نسبت به توضیحات درون‌خطی (Inline) دارد. چون این توضیحات در تمام پروژه‌ها به اشتراک گذاشته می‌شوند، به‌عنوان دستورالعمل‌های دائمی برای مدل عمل می‌کنند.
• سرورهای شخص ثالث بررسی‌نشده: اتصال به سروری بدون بررسی دسترسی‌های آن. توضیحات ابزارها متونی هستند که توسط سرور کنترل می‌شوند و مدل آن‌ها را به‌عنوان یک دستور مستقیم می‌خواند.
• تولید ابزارهای تکراری: ساختن سروری برای ابزاری که پیش‌تر در یک ریجستری عمومی وجود دارد.

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

این تغییر، رویکرد بنیادین توسعه عامل‌ها را از «یکپارچگی‌های سفارشی» (Bespoke Integrations) به یک «اکوسیستم پلاگین» برای مدل‌های زبانی بزرگ (LLMs) تغییر می‌دهد. اکنون بار نگهداری از دوش توسعه‌دهنده اپلیکیشن به دوش ارائه‌دهنده ابزار منتقل شده است که یک API نسخه‌بندی شده واحد را برای تمام مصرف‌کنندگان هوش مصنوعی مدیریت می‌کند.

برای شروع، توسعه‌دهندگان می‌توانند سرورهای خود را با استفاده از StdioClientTransport تست کنند تا پیش از استقرار در یک عامل عملیاتی، دست‌دادن (Handshake) واقعی MCP و لیست ابزارها را تأیید کنند—نه یک نسخه شبیه‌سازی شده (Mock).

گام بعدی شما

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

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