IRCNF

پروتکل MCP از Anthropic پیروز شد: چطور Model Context Protocol به استاندارد جهانی یکپارچه‌سازی ابزارهای هوش مصنوعی تبدیل شد

اشتراک‌گذاری:
پروتکل MCP از Anthropic پیروز شد: چطور Model Context Protocol به استاندارد جهانی یکپارچه‌سازی ابزارهای هوش مصنوعی تبدیل شد

در نوامبر ۲۰۲۴، شرکت Anthropic مشخصاتی به نام Model Context Protocol منتشر کرد – یک استاندارد باز برای اتصال مدل‌های هوش مصنوعی به ابزارها، منابع داده و سرویس‌های خارجی. در آن زمان، این پروتکل فقط یک قالب یکپارچه‌سازی اختصاصی دیگر به نظر می‌رسید. اما تا اواسط ۲۰۲۶، تمام پلتفرم‌های بزرگ هوش مصنوعی آن را پذیرفتند. MCP مشکل پراکندگی را حل کرد که مدتها بود مانع پیشرفت عامل‌های هوش مصنوعی شده بود: ناتوانی در به اشتراک‌گذاری یکپارچه‌سازی ابزارها بین مدل‌ها و runtimeهای مختلف.

MCP دقیقاً چیست؟

MCP یک پروتکل client/server است که روی JSON-RPC 2.0 ساخته شده. یک سرور MCP قابلیت‌هایی را ارائه می‌دهد – ابزارها، منابع و پرامپت‌ها – از طریق یک لایه انتقال (stdio برای فرآیندهای محلی، HTTP/SSE برای سرویس‌های شبکه‌ای). یک کلاینت MCP که در یک میزبان هوش مصنوعی مانند Claude، Copilot یا Cursor تعبیه شده، در زمان اجرا این قابلیت‌ها را کشف و فراخوانی می‌کند.

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

  • ابزارها – توابع قابل فراخوانی که مدل می‌تواند اجرا کند، با تعریف ورودی/خروجی JSON Schema تایپ‌شده. برای مثال: github.create_pull_request، postgres.run_query، slack.send_message.
  • منابع – داده‌های ساختاریافته‌ای که مدل می‌تواند بخواند، با شناسه URI. یک فایل، یک ردیف پایگاه داده، یک رویداد تقویم.
  • پرامپت‌ها – قالب‌های پرامپت قابل استفاده مجدد و پارامتریزر شده که سرور برای کارهای رایج در معرض قرار می‌دهد.

طراحی مستقل از انتقال عمدی است. یک سرور MCP که به صورت محلی اجرا می‌شود از طریق stdin/stdout ارتباط برقرار می‌کند. همان سرور که به عنوان یک میکروسرویس مستقر می‌شود به HTTP با Server-Sent Events برای استریمینگ سوئیچ می‌کند. کلاینت اهمیتی نمی‌دهد که از کدام انتقال استفاده می‌شود.

جدول زمانی پذیرش که همه چیز را تغییر داد

Anthropic MCP را به صورت متن‌باز منتشر کرد و SDKهای Python و TypeScript را همراه با مشخصات ارائه داد. پذیرش اولیه از ابزارهای توسعه‌دهنده بود: Cursor، Zed و Continue ظرف چند هفته MCP را یکپارچه کردند و به کاربران خود دسترسی به فهرست رو به رشدی از سرورها برای GitHub، سیستم‌های فایل، پایگاه‌های داده و جستجوی وب دادند.

نقطه عطف در اوایل ۲۰۲۵ رخ داد وقتی OpenAI از پشتیبانی بومی MCP در Responses API و چارچوب عامل خود خبر داد. این تصمیم نشان داد که MCP یک ویژگی مختص Claude نیست – بلکه زیرساخت است. Google نیز با یکپارچه‌سازی MCP در Gemini در Google AI Studio و Vertex AI دنبال کرد و به عامل‌های Gemini اجازه داد از همان فهرست سرورهایی استفاده کنند که کاربران Claude ساخته بودند. Microsoft Copilot Studio نیز پشتیبانی از کانکتور MCP را اضافه کرد و به تیم‌های سازمانی امکان داد APIهای داخلی را بدون نوشتن کد پلاگین سفارشی به عنوان سرور MCP در معرض قرار دهند.

تا اواسط ۲۰۲۶، ثبت سرور MCP به بیش از ۲۰۰۰ سرور نگهداری‌شده توسط جامعه و فروشندگان رسید. AWS، Azure و GCP هر کدام سرورهای MCP شخص اولی برای سرویس‌های اصلی خود منتشر کردند. Stripe، Linear، Notion و Atlassian یکپارچه‌سازی‌های رسمی ارائه دادند. اکوسیستمی که سالها طول کشیده بود تا حول REST APIها ساخته شود، در عرض چند ماه حول MCP بازسازی شد.

چرا MCP بر جایگزین‌ها پیروز شد

قبل از MCP، هر پلتفرم هوش مصنوعی قالب مخصوص خود برای فراخوانی ابزار داشت. OpenAI از function calling با گویش خاص JSON Schema خود استفاده می‌کرد. LangChain از Tools با تعریف کلاس پایتون. Semantic Kernel از Plugins با توصیف‌گر OpenAPI. هر اکوسیستم نیاز به بازنویسی یکپارچه‌سازی‌ها از ابتدا هنگام تغییر مدل یا runtime داشت.

MCP به سه دلیل پیروز شد:

  • واقعاً باز است. مشخصات تحت مجوز MIT است و مستقل مدیریت می‌شود. هیچ فروشنده‌ای به تنهایی نقشه راه را کنترل نمی‌کند. این امر پذیرش را برای OpenAI و Google از نظر سیاسی ایمن کرد – آنها پروتکلی را ارائه نمی‌دادند که کاربران را به اکوسیستم Anthropic قفل کند.
  • ساده‌تر از جایگزین‌ها است. یک سرور MCP فرآیندی است که با JSON-RPC صحبت می‌کند. نیازی به چارچوب، مانیفست پلاگین یا مشخصات OpenAPI ندارید. یک سرور کاربردی در پایتون با استفاده از SDK رسمی حدود ۳۰ خط کد است.
  • مستقل بودن از انتقال، اصطکاک استقرار را از بین می‌برد. همان باینری سرور در محیط توسعه محلی و در خوشه Kubernetes کار می‌کند. این پیش‌بینی‌پذیری برای تیم‌های سازمانی با الزامات شبکه و امنیتی سخت مهم است.

در عمل چه شکلی است

توسعه‌دهنده‌ای که امروز یک عامل پشتیبانی مشتری می‌سازد، دیگر کد چسب فراخوانی ابزار سفارشی برای هر مدلی که می‌خواهد پشتیبانی کند نمی‌نویسد. در عوض، یک سرور MCP اجرا می‌کند که CRM، سیستم تیکتینگ و پایگاه دانش خود را به عنوان ابزار و منابع در معرض قرار می‌دهد. هر میزبان هوش مصنوعی سازگار با MCP – Claude، GPT-4o، Gemini – می‌تواند از آن ابزارها بدون تغییر استفاده کند.

یک نمونه stack مشخص را در نظر بگیرید. یک تیم موارد زیر را مستقر می‌کند:

  • یک سرور MCP که پایگاه داده PostgreSQL را می‌پیچد و run_query و list_tables را به عنوان ابزار در معرض قرار می‌دهد
  • یک سرور MCP برای مخزن GitHub خود که مدیریت Issue و ایجاد PR را در معرض قرار می‌دهد
  • یک سرور MCP برای Slack که ارسال پیام در کانال و خواندن ترد را ارائه می‌دهد

عامل هوش مصنوعی آنها – که روی هر مدلی که برای workload آنها بهترین عملکرد را دارد اجرا می‌شود – هر سه سرور را در زمان راه‌اندازی از طریق یک فایل پیکربندی کشف می‌کند و می‌تواند در طول یک جلسه استدلال هر ابزاری را در هر سروری فراخوانی کند. تغییر از Claude به Gemini هیچ یکپارچه‌سازی را نمی‌شکند. این ارزش عملی MCP است.

تغییر تجربه توسعه‌دهنده

مدل ذهنی برای توسعه‌دهندگان محصولات مبتنی بر هوش مصنوعی تغییر کرده است. قبلاً یکپارچه‌سازی‌ها مختص مدل بودند: برای function calling OpenAI می‌ساختید، یا برای استفاده از ابزار Claude، و جابجایی بین آنها به معنای بازنویسی schemaها و کد چسب بود. اکنون یکپارچه‌سازی‌ها مختص قابلیت هستند: یک سرور MCP یک بار می‌سازید و هر runtime هوش مصنوعی سازگار می‌تواند از آن استفاده کند.

این تغییر پیامدهای عملی برای نحوه ساختاردهی زیرساخت هوش مصنوعی توسط تیم‌ها دارد. سرورهای MCP اکنون یک لایه مجزا در stack هستند – جدا از برنامه، جداگانه مستقر و جداگانه نسخه‌بندی می‌شوند. تیم‌ها فهرست سرورهای MCP داخلی می‌سازند همانطور که قبلاً فهرست API داخلی می‌ساختند. انضباط طراحی API – قراردادهای واضح، نسخه‌بندی، مستندسازی – برای اولین بار به یکپارچه‌سازی ابزارهای هوش مصنوعی اعمال می‌شود.

امنیت و مجوزدهی

MCP نسخه ۱.۱ که در سه‌ماهه اول ۲۰۲۶ منتشر شد، یک لایه مجوزدهی OAuth 2.1 برای سرورهای مبتنی بر HTTP اضافه کرد. یک کلاینت MCP اکنون می‌تواند قبل از فراخوانی ابزارها روی یک سرور راه دور، توکن‌های دسترسی با scope محدود مذاکره کند. این اعتراض اصلی سازمان‌ها به استقرارهای اولیه MCP را برطرف کرد: اینکه هر مدل متصل بدون کنترل دسترسی دقیق می‌توانست هر ابزاری را فراخوانی کند. با استاندارد شدن جریان‌های OAuth 2.1 در مشخصات، استقرارهای MCP سازمانی بدون میان‌افزار امنیتی سفارشی عملی شده است.

نکات عملی

اگر در سال ۲۰۲۶ محصولات مبتنی بر هوش مصنوعی می‌سازید، MCP دیگر یک زیرساخت اختیاری برای ارزیابی نیست – بلکه لایه یکپارچه‌سازی پیش‌فرض است. در اینجا کارهایی که باید انجام دهید:

  • یکپارچه‌سازی ابزار موجود خود را حسابرسی کنید. هر schema فراخوانی تابع سفارشی که برای یک مدل خاص نگهداری می‌کنید اکنون بدهی فنی است. مهاجرت به یک سرور MCP به شما قابلیت حمل در سراسر همه مدل‌های سازگار می‌دهد.
  • قبل از ساختن، ثبت سرورها را بررسی کنید. فهرست سرور MCP در modelcontextprotocol.io احتمالاً یک سرور نگهداری‌شده برای API مورد نیاز شما دارد. Stripe، GitHub، Postgres، Slack و Google Drive همه سرورهای شخص اول دارند.
  • سرورهای MCP را به عنوان محصولات داخلی بسازید. با سرور MCP خود همانطور رفتار کنید که با یک API داخلی رفتار می‌کنید: آن را نسخه‌بندی کنید، مستند کنید و یک مدل مالکیت واضح به آن بدهید. تیم‌هایی که در یک فهرست MCP داخلی خوب طراحی شده سرمایه‌گذاری می‌کنند، آن سرمایه‌گذاری را در هر ویژگی هوش مصنوعی که عرضه می‌کنند چند برابر خواهند کرد.
  • برای هر چیزی که در سطح تولید است از جریان OAuth 2.1 استفاده کنید. سرورهای stdio محلی برای توسعه مناسب هستند. هر سرور MCP که در معرض یک عامل هوش مصنوعی تولیدی قرار می‌گیرد باید به دسترسی احراز هویت‌شده با scope محدود نیاز داشته باشد.

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

اشتراک‌گذاری:
پروتکل MCP از Anthropic پیروز شد: چطور Model Context Protocol به استاندارد جهانی یکپارچه‌سازی ابزارهای هوش مصنوعی تبدیل شد | IRCNF - Intelligent Reliable Custom Next-gen Frameworks