عصر MCP: چطور Model Context Protocol بی‌سروصدا اپ‌های هوش مصنوعی را در ۲۰۲۶ دگرگون کرد

Anthropic در اواخر ۲۰۲۴ Model Context Protocol را منتشر کرد. بیشتر آدم‌ها آن را زیر عنوان «یک استاندارد دیگر» بایگانی کردند و رفتند سراغ کارشان. هجده ماه بعد، MCP عملاً لایه لوله‌کشی پشته اپ‌های هوش مصنوعی است. Claude Code اول از همه MCP است. Cursor چند سرور را در یک نشست اجرا می‌کند. Linear، Figma، Notion، GitHub، Slack و Stripe همگی سرور رسمی منتشر کرده‌اند. پروتکل برنده شد.

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

MCP کابلی است که بالاخره جا افتاد

Model Context Protocol به هر کلاینت هوش مصنوعی اجازه می‌دهد از طریق یک سرور استاندارد با هر ابزار یا منبع داده‌ای صحبت کند. پیش از MCP هر یکپارچه‌سازی دست‌دوز بود. هر کلاینت فرمت ابزار خودش را اختراع می‌کرد. هر ابزار برای هر کلاینت یک آداپتور سفارشی می‌نوشت. هزینه ترکیبی کمرشکن بود و بیشتر سازندگان کوتاه آمدند و چند یکپارچه‌سازی را هاردکد کردند.

MCP این وضع را جمع کرد. سرور را یک بار بسازید، هر کلاینت MCP می‌تواند از آن استفاده کند. کلاینت را یک بار بسازید، هر سرور MCP در دسترس است. پدیده درست در زمان درست، با حاکمیتی باز، که Anthropic کار پروتکل را انجام می‌دهد اما مالک استاندارد نیست.

MCP در سطح سیم واقعاً چیست

MCP همان JSON-RPC روی یک ترنسپورت است، با مجموعه کوچکی از پدیده‌های استاندارد. سرور منابع (داده‌ای که مدل می‌تواند بخواند)، ابزارها (کارهایی که می‌تواند صدا بزند) و پرامپت‌ها (قالب‌هایی که کاربر می‌تواند فراخوانی کند) را عرضه می‌کند. کلاینت روی هر سرور همان متدها را به کار می‌برد: list، read، call. کل انتزاع همین است.

JSON-RPC کسل‌کننده است، خوب شناخته شده است، با curl دیباگ می‌شود و از هر فایروالی که تا حالا ساخته شده رد می‌شود. تفکیک این پدیده‌ها به مدل ساختار کافی می‌دهد تا درباره کارهای سرور استدلال کند، بی‌آنکه سرور را مجبور کند در یک طرحواره یک‌اندازه‌برای‌همه جا بگیرد.

سه ترنسپورت و اهمیتشان

MCP روی سه ترنسپورت عرضه می‌شود: stdio، HTTP به‌علاوه SSE و WebSockets. Stdio سرور را به‌عنوان پروسه فرزند کلاینت اجرا می‌کند و پیش‌فرض کلاینت‌های دسکتاپ مثل Claude Desktop است. HTTP به‌علاوه SSE سرور را به‌صورت یک سرویس راه‌دور اجرا می‌کند که کلاینت از آن poll و stream می‌کند، شکل درست برای سرورهای MCP ابری. WebSockets حالت نادری را پوشش می‌دهد که از یک سرور راه‌دور به full-duplex نیاز دارید.

ترنسپورت بیشتر یک انتخاب استقرار است تا قابلیت. همان منطق سرور روی هر سه کار می‌کند. یک تیم می‌تواند روی stdio به‌صورت محلی نمونه‌سازی کند و روی HTTP به‌علاوه SSE پشت گیت‌وی احراز هویت خودش منتشر کند، بدون بازنویسی لایه پروتکل.

چرا MCP جایی برد که استانداردهای قبلی باختند

پلاگین‌های ChatGPT، مشخصات function-calling و OpenAPI-for-LLMs همه سعی کردند استاندارد ابزار-عامل شوند. هر سه متوقف شدند. MCP برد چون پدیده درست را در زمان درست و با حاکمیت درست انتخاب کرد.

پلاگین‌های ChatGPT به یک کلاینت و یک مدل صورتحساب گره خورده بودند و مانیفستشان اندپوینت‌های HTTP بدون حالت با مشخصات OpenAPI را فرض می‌کرد که تقریباً هیچ محصول واقعی تمیز ارائه نمی‌دهد. مشخصات function-calling هر آزمایشگاه، فرمت‌های تک‌فروشنده‌ای بودند که لباس استاندارد پوشیده بودند. OpenAPI-for-LLMs سعی کرد یک فرمت مستندسازی را به قرارداد زمان اجرا تبدیل کند و ناسازگاری امپدانس کمرش را شکست.

پدیده درست: سرور، نه پلاگین

انتخاب MCP که یکپارچه‌سازی را یک سرور بلندمدت با قرارداد تایپ‌شده کرد، به جای مانیفست پلاگین بدون حالت، تصمیم معماری‌ای است که همه چیز دیگر از آن بیرون می‌آید. یک سرور می‌تواند اتصال‌های پایگاه داده نگه دارد، منابع را کش کند، توکن‌های احراز هویت را مدیریت کند، پاسخ‌ها را stream کند و به‌روزرسانی بدهد بی‌آنکه کلاینت بشکند. یک پلاگین بدون حالت تقریباً هیچ‌کدام را نمی‌تواند. یکپارچه‌سازی‌های واقعی به حالت، تلاش مجدد، observability و مدیریت rate-limit نیاز دارند. سرورها این را حمل می‌کنند. پلاگین‌ها با آن می‌جنگند.

زمان‌بندی درست: بعد از tool-use، پیش از پشته عامل

MCP دقیقاً وقتی آمد که سازندگان دیگر سر این بحث نمی‌کردند که tool use مهم است یا نه، و شروع کرده بودند به بحث درباره اینکه چطور ده ابزار را بدون بازنویسی در هر نسخه به یک عامل وصل کنند. بحث tool use تمام شده بود. مشکل بعدی ارکستراسیون بود. MCP به لایه ارکستراسیون یک انتزاع تمیز داد.

حاکمیت هم کمک کرد. Anthropic مشخصات را متن‌باز کرد، سازمان GitHub را باز کرد، از روز اول مشارکت بیرونی پذیرفت و اجازه داد آزمایشگاه‌های دیگر بدون کسب مجوز کلاینت پیاده کنند. تا نیمه ۲۰۲۶، OpenAI پشتیبانی MCP را در پشته Assistants خود عرضه کرد. Gemini آن را از طریق Gemini API پشتیبانی می‌کند. همین چادر بزرگ بود که یک پروژه جانبی را به استاندارد تبدیل کرد.

سرورهای شاخص MCP در محیط تولید

یک فهرست کوتاه بیشتر بار را می‌کشد. بیشتر پشته‌های عامل در ۲۰۲۶ ترکیبی از همین نه سرورند.

Figma فریم‌ها، کامپوننت‌ها، متغیرها و درخت لایه‌ها را عرضه می‌کند، پس مدل یک فریم را همان‌طور می‌خواند که توسعه‌دهنده یک مشخصات را. Linear ایشوها، پروژه‌ها و چرخه‌ها را عرضه می‌کند و Claude Code را به یک کدنویس آگاه از پروژه تبدیل می‌کند. Notion صفحه‌ها، پایگاه‌های داده و بلاک‌ها را عرضه می‌کند و آن را به مخزن زمینه جهانی بدل می‌کند. GitHub مخزن‌ها، ایشوها، پول‌ریکوئست‌ها و اکشن‌ها را عرضه می‌کند، سطح زمینه کد شاخص. Slack کانال‌ها، تردها و جستجو را عرضه می‌کند. Stripe مشتریان، اشتراک‌ها، پرداخت‌ها و متریک‌ها را عرضه می‌کند، همان‌طور که عامل‌های مالی و عملیات دفترها را می‌خوانند.

Postgres طرحواره‌ها، جدول‌ها و کوئری‌ها را با دامنه‌های فقط‌خواندنی یا خواندن-نوشتن عرضه می‌کند. Filesystem یک دایرکتوری ایزوله را عرضه می‌کند، راهی که Claude Code یک مخزن را می‌خواند و می‌نویسد. Browserbase ناوگانی میزبانی‌شده از Chromium را از طریق MCP عرضه می‌کند، راهی که عامل‌ها بدون مدیریت زیرساخت یک مرورگر را هدایت می‌کنند. نه سرور، نود درصد کار عامل.

کلاینت‌های MCP-اول که صحنه را اداره می‌کنند

Claude Code کلاینت MCP شاخص است. هر یکپارچه‌سازی یک سرور MCP است. افزودن یک ابزار یعنی ویرایش یک فایل پیکربندی و اشاره‌دادن آن به یک باینری یا URL سرور. Claude Desktop همین مدل را با رابطی برای پیکربندی سرورها در هر ورک‌اسپیس عرضه می‌کند. Cursor در اوایل ۲۰۲۶ پشتیبانی MCP را اضافه کرد و حالا چند سرور را در یک نشست اجرا می‌کند، برای همین همان پنل Cursor که کد را ویرایش می‌کند می‌تواند یک فریم Figma بکشد، یک ایشوی Linear ثبت کند و از Postgres کوئری بگیرد.

Continue.dev از ابتدا MCP-اول عرضه می‌شود. JetBrains AI پشتیبانی MCP را اضافه کرد. Zed هم MCP را عرضه کرد. هر IDE و کلاینت هوش مصنوعی که بخواهد جدی گرفته شود حالا پشتیبانی MCP دارد و محصولاتی که داستان MCP ندارند دارند کهنه به نظر می‌رسند.

طراحان واقعاً با MCP چه کار کنند

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

حرکت بزرگ‌تر ساختن یک ورک‌اسپیس MCP واحد است. Figma، Notion و مخزن توکن‌های طراحی را به‌صورت سه سرور به Claude Code وصل کنید. همان پرامپتی که می‌گوید «این کامپوننت را طبق مشخصات بساز» فریم Figma را می‌خواند، دلیل طراحی را از Notion می‌کشد، به فایل توکن ارجاع می‌دهد و کد را می‌نویسد. این اولین بار است که یک سیستم طراحی در جریان کاری هوش مصنوعی واقعاً مثل یک مصنوع پیوسته رفتار می‌کند. همین الگو برای Claude Skills هم صدق می‌کند، جایی که Skill همان پرسونا است و MCP همان ورک‌اسپیس.

سازندگان واقعاً با MCP چه کار کنند

برای هر ابزار داخلی‌ای که تیمتان دارد یک سرور MCP داخلی منتشر کنید. Claude Code را به آن وصل کنید. تماشا کنید همان عاملی که کد می‌نویسد شروع به اجرای عملیات می‌کند. الگوی برنده در ۲۰۲۶ «دستیار هوش مصنوعی برای X» نیست. «هر ابزاری که تیمتان به کار می‌برد، به‌صورت سرور MCP عرضه شده، با یک کلاینت که ارکستراسیون را انجام می‌دهد» است.

می‌خواهید MCP را بدون از دست دادن یک فصل روی مدل احراز هویت به ابزارهای تیمتان وصل کنید، یا پشته‌ای از سرورهای MCP داخلی بسازید که در تولید دوام بیاورد؟ Brainy را استخدام کنید. ClaudeBrainy یک قالب سرور MCP به‌علاوه کتابخانه‌های پرامپت عرضه می‌کند و AppBrainy ساخت کامل محصول را برای تیم‌هایی انجام می‌دهد که می‌خواهند عامل‌هایشان یک ورک‌اسپیس واقعی را به اشتراک بگذارند، نه اسکرین‌شات.

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

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

تأخیر ارکستراسیون چندسروره، پیچیدگی احراز هویت و نبود داستان موبایل سه جایی‌اند که MCP هنوز زمین می‌خورد، و دموهایی که آن‌ها را پنهان می‌کنند همان دموهایی‌اند که باید نادیده گرفت.

تأخیر در ارکستراسیون چندسروره واقعی است. پرامپتی که در یک نوبت به Figma، Notion و Postgres دست می‌زند می‌تواند پیش از اینکه مدل زمینه کافی برای پاسخ داشته باشد سه رفت‌وبرگشت بپردازد، و روی ترنسپورت‌های کندتر انتظار تجمعی از پنج ثانیه می‌گذرد. کش کمک می‌کند. connection pooling کمک می‌کند. هیچ‌کدام تأخیر را ناپدید نمی‌کند.

پیچیدگی احراز هویت حفره دوم است. MCP احراز هویت را استاندارد نکرده است. هر سرور مدل خودش را انتخاب می‌کند: OAuth، کلیدهای API، توکن‌های محدودشده، گاهی اصلاً هیچ. وصل‌کردن پانزده سرور به یک کلاینت یعنی پانزده مخزن اعتبارنامه، پانزده سیاست refresh و پانزده ردپای ممیزی. بیشتر تیم‌ها این را دست‌کم می‌گیرند تا اولین باری که یک سرور داده مشتری به زمینه‌ای غیرمشتری نشت می‌کند.

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

سه حالت شکست که دموهای پرهیاهوی MCP پنهان می‌کنند

بیشتر پشیمانی‌های MCP در ۲۰۲۶ به همین سه حفره برمی‌گردد.

اول. دموی دست‌تکان‌دادن روی احراز هویت. ارائه‌دهنده سروری را نشان می‌دهد که به CRM یک مشتری وصل است، عامل جواب می‌دهد، تشویق. احراز هویت یک توکن شخصی از حساب دمو بود. اشاره‌دادن همان ستاپ به یک سیستم تولید چندمستاجری یعنی بازسازی احراز هویت با اعتبارنامه‌های محدودشده، جریان‌های OAuth و ایزولاسیون مستاجر. راه‌حل: مدل احراز هویت را پیش از انتشار سرور انتخاب کنید، نه بعد از آن.

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

سوم. دموی تک‌سروره. عامل از یک سرور زیبا استفاده می‌کند، ارائه‌دهنده وانمود می‌کند ارکستراسیون چندسروره فقط یک خط پیکربندی دیگر است. در تولید، سرور دوم و سوم تأخیر، تعارض احراز هویت و سردرگمی پرامپت می‌آورند. راه‌حل: مجموعه سرورها را مثل یک سیستم طراحی کنید، نه یک فهرست. مرزها را مستند کنید.

اولین حرکت بر اساس نقش

هر نقش در تیم اولین حرکت متفاوتی با MCP دارد. کار به‌طور نامتوازن توزیع شده است.

الگو این است. طراحان و توسعه‌دهندگان فرانت‌اند مونتاژ ورک‌اسپیس را حمل می‌کنند. توسعه‌دهندگان بک‌اند قرارداد سرور و مدل احراز هویت را. بنیان‌گذاران مسیر را انتخاب می‌کنند.

FAQ

Model Context Protocol چیست؟

MCP یک پروتکل باز است که به هر کلاینت هوش مصنوعی اجازه می‌دهد از طریق یک سرور استاندارد با هر ابزار یا منبع داده‌ای صحبت کند. سرور منابع، ابزارها و پرامپت‌ها را عرضه می‌کند. کلاینت JSON-RPC را روی stdio، HTTP به‌علاوه SSE یا WebSockets به کار می‌برد. Anthropic مشخصات را در اواخر ۲۰۲۴ منتشر کرد و تا نیمه ۲۰۲۶ استاندارد عملی یکپارچه‌سازی ابزار-عامل است.

آیا MCP فقط برای Claude است؟

نه. Cursor، Continue.dev، JetBrains AI، Zed و پشته Assistants شرکت OpenAI همگی از MCP پشتیبانی می‌کنند. Gemini آن را از طریق Gemini API پشتیبانی می‌کند. Anthropic پروتکل را منتشر کرد اما مالک آن نیست.

آیا باید سرور MCP خودم را بنویسم؟

برای ابزارهای شاخص احتمالاً نه. Figma، Linear، Notion، GitHub، Slack، Stripe، Postgres، Filesystem و Browserbase همگی سرور رسمی یا شاخص دارند. برای ابزارهای داخلی، پایگاه‌های داده سفارشی و APIهای اختصاصی خودتان خواهید نوشت. بیشتر سرورهای MCP داخلی چند صد خط کد به‌علاوه یک مدل احراز هویت‌اند.

MCP چه فرقی با tool use دارد؟

Tool use قابلیت سمت مدل برای صدا زدن توابع با ورودی و خروجی ساخت‌یافته است. MCP پروتکلی است که تعریف می‌کند ابزارها چطور در هر کلاینتی کشف، توصیف و فراخوانی می‌شوند. Tool use موتور است. MCP سیم‌کشی است. راهنمای عامل‌های computer use پایه سوم را پوشش می‌دهد، یعنی وقتی API تمیزی برای صدا زدن وجود ندارد.

کِی MCP معنا ندارد؟

وقتی یک ابزار، یک کلاینت و یک یکپارچه‌سازی هاردکد دارید که الان کار می‌کند. برد در دنیای چندابزاره و چندکلاینته است. برای یک عامل و یک API، همان tool use ساده کافی است.

تغییری که MCP واقعاً باز می‌کند

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

بیشتر تیم‌ها هنوز یکپارچه‌سازی هوش مصنوعی را یک فیچر می‌دانند که روی محصول پیچ شده. تیم‌هایی که جلو می‌افتند کلاینت هوش مصنوعی به‌علاوه مجموعه‌ای از سرورهای MCP را ورک‌اسپیس می‌دانند و محصول چیزی است که در لبه‌ها ظاهر می‌شود. اولی یک تب چت دیگر عرضه می‌کند. دومی ابزاری که تیم واقعاً استفاده می‌کند. همین تغییر در مقایسه ادیتورهای کد هوش مصنوعی و بررسی Claude 4.7 برای سازندگان هم دیده می‌شود.

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

اگر می‌خواهید MCP را بدون از دست دادن یک فصل روی مدل احراز هویت به ابزارهای تیمتان وصل کنید، یا پشته‌ای از سرورهای MCP داخلی بسازید که در تولید دوام بیاورد، Brainy را استخدام کنید. ClaudeBrainy بسته‌های Skill و قالب‌های سرور MCP عرضه می‌کند. AppBrainy ساخت کامل محصول را برای تیم‌هایی انجام می‌دهد که می‌خواهند عامل‌هایشان یک ورک‌اسپیس واقعی را به اشتراک بگذارند، نه اسکرین‌شات.