در چشم انداز کنونی هوش مصنوعی، مفهومی در حال ایجاد هیاهوی قابل توجه است: MCP یا Model Context Protocol. شگفت آور است که توجه پیرامون این سیستم پروتکل حتی از آخرین نسخه های مدل OpenAI نیز فراتر رفته و به یک نقطه کانونی در بحث های صنعت تبدیل شده است.
افزایش محبوبیت فناوری Agent که ناشی از ظهور Manus است، اشتیاق توسعه دهندگان جهانی را برانگیخته است. MCP که به عنوان یک ‘پروتکل یکپارچه’ برای فراخوانی ابزار Agent قرار گرفته است، به سرعت مورد توجه قرار گرفته و ظرف تنها دو ماه، حمایت بازیگران اصلی هوش مصنوعی مانند OpenAI و Google را به دست آورده است. این صعود سریع، MCP را از یک مشخصات فنی نسبتاً مبهم به یک استاندارد اساسی در اکوسیستم هوش مصنوعی تبدیل کرده و یک ‘رویداد خارق العاده’ را در قلمرو زیرساخت هوش مصنوعی رقم زده است.
با این حال، با فروکش کردن هیجان اولیه، سوالات مهمی مطرح می شوند: آیا MCP واقعاً به طور جهانی قابل استفاده است؟ آیا انتظارات از قابلیت های آن بیش از حد افزایش یافته است؟
این بررسی به بررسی ریشه های MCP می پردازد، نقاط قوت و محدودیت های اصلی آن را تشریح می کند، تصورات غلط رایج را روشن می کند و مسیر بالقوه آینده آن را بررسی می کند. هدف این نیست که ارزش ذاتی MCP را رد کنیم، بلکه در عوض درک عمیق تری از نقش و مرزهای آن ایجاد کنیم. تنها از طریق چنین وضوحی است که می توان به طور کامل از پتانسیل آن بهره برد.
رونمایی از MCP: یک پروتکل فراخوانی ابزار یکپارچه
تعریف MCP
MCP یک پروتکل فنی باز است که برای استانداردسازی نحوه تعامل مدل های زبان بزرگ (LLM) با ابزارها و خدمات خارجی طراحی شده است. آن را به عنوان یک مترجم جهانی در دنیای هوش مصنوعی در نظر بگیرید که مدل های هوش مصنوعی را قادر می سازد تا با طیف گسترده ای از ابزارهای خارجی ‘صحبت’ کنند. این پروتکل یک زبان و ساختار مشترک برای LLM ها فراهم می کند تا قابلیت های ارائه شده توسط برنامه ها و خدمات مختلف را درخواست و استفاده کنند.
نیاز به MCP
قبل از ظهور MCP، فراخوانی ابزار هوش مصنوعی با دو چالش کلیدی روبرو بود:
- تکه تکه شدن رابط: هر LLM از فرمت های دستورالعمل متمایز استفاده می کرد، در حالی که هر API ابزار دارای ساختارهای داده منحصر به فرد خود بود. توسعه دهندگان مجبور بودند کد اتصال سفارشی برای هر ترکیب بنویسند که منجر به یک فرآیند توسعه پیچیده و ناکارآمد می شد.
- عدم کارآیی در توسعه: این رویکرد ‘ترجمه یک به یک’ پرهزینه و مقیاس پذیر نبود. این امر مانند استخدام یک مترجم اختصاصی برای هر مشتری خارجی بود که مانع از بهره وری و چابکی می شد.
MCP با ارائه یک چارچوب استاندارد برای تعامل LLM ها با ابزارهای خارجی، فرآیند توسعه را ساده کرده و مقیاس پذیری بیشتری را ممکن می سازد، این نقاط درد را برطرف می کند.
درک عملکرد MCP
معماری فنی MCP را می توان به عنوان سیستمی متشکل از سه مؤلفه اصلی مفهوم سازی کرد: MCP Host، MCP Client و MCP Server. این عناصر به طور هم افزایی برای تسهیل ارتباط یکپارچه بین مدل های هوش مصنوعی و دنیای خارج کار می کنند.
برای درک نقش MCP، یک محیط سازمانی مدرن را در نظر بگیرید. در این قیاس:
- کاربران نشان دهنده مدیران ارشد هستند که مسئول درک نیازهای کاربر و تصمیم گیری نهایی هستند.
- مدل های زبان بزرگ (LLM) (مانند Claude یا GPT) دستورالعمل های اجرایی را درک می کنند، مراحل انجام وظیفه را برنامه ریزی می کنند، زمان استفاده از خدمات خارجی را تعیین می کنند و اطلاعات را برای ارائه پاسخ ها تلفیق می کنند.
- سیستم های Agent به عنوان دستیاران شخصی یا منشی های اجرایی عمل می کنند و وظایف را طبق دستورالعمل انجام می دهند.
- MCP به عنوان یک پلت فرم ارتباطی استاندارد یا سیستم دسترسی به خدمات سازمانی مورد استفاده منشی ها عمل می کند. تصمیم گیری نمی کند بلکه در عوض از دستورالعمل ها پیروی می کند و با ارائه دهندگان خدمات مختلف در یک فرمت و پروتکل واحد ارتباط برقرار می کند.
قبل از MCP، تعامل هوش مصنوعی با ابزارهای خارجی شبیه به دوران استانداردهای ارتباطی آشفته بود. هر بار که یک منشی (Agent) نیاز به تماس با یک بخش مختلف یا تامین کننده خارجی داشت، مجبور بود از یک دستگاه یا نرم افزار ارتباطی متفاوت استفاده کند. این امر مستلزم آشنایی با سیستم های متنوع بود که منجر به ناکارآمدی می شد. توسعه دهندگان مجبور بودند کدهای اتصال جداگانه برای هر ابزار بنویسند که منجر به اتلاف وقت و محدود شدن مقیاس پذیری می شد.
MCP این فرآیند را با ارائه یک پلت فرم ارتباطی یکپارچه ساده می کند و به منشی ها اجازه می دهد تا با استفاده از همان سیستم و پروتکل ارتباطی با هر بخش یا ارائه دهنده خدمات تماس بگیرند. توسعه دهندگان فقط باید یک بار رابط MCP را پیاده سازی کنند و سیستم های هوش مصنوعی را قادر می سازند تا با تمام ابزارهایی که از پروتکل پشتیبانی می کنند، تعامل داشته باشند.
MCP: جعبه ابزاری ساخته شده بر اساس Function Call
درک این نکته بسیار مهم است که MCP جایگزینی برای Function Call سنتی نیست. بلکه یک جزء مکمل است که قابلیت های آن را افزایش می دهد.
Function Call مکانیسم اصلی است که LLM ها از طریق آن با ابزارها یا API های خارجی تعامل دارند. این یک قابلیت اساسی LLM ها است و آنها را قادر می سازد تا تشخیص دهند چه زمانی به یک ابزار نیاز است و چه نوع ابزاری مورد نیاز است.
MCP به عنوان یک سیستم طبقه بندی ابزار عمل می کند و یک چارچوب ساختاریافته برای سازماندهی و دسترسی به ابزارهای مختلف ارائه می دهد. بنابراین، MCP جایگزین Function Call نمی شود، بلکه در عوض با Agents برای انجام وظایف پیچیده همکاری می کند.
فرآیند فراخوانی ابزار کامل شامل ترکیبی از ‘Function Call + Agent + سیستم MCP’ است.
در اصل، LLM نیاز به فراخوانی یک ابزار خاص را از طریق Function Call بیان می کند. Agent از دستورالعمل ها برای اجرای فراخوانی ابزار پیروی می کند، در حالی که MCP یک مشخصات فراخوانی ابزار استاندارد ارائه می دهد.
قیاس زیر را در نظر بگیرید: یک رئیس (کاربر) قهوه می خواهد. در دفتر (MCP Host)، مدیر دفتر (LLM) به منشی (Agent) دستور می دهد که یک قهوه آمریکانو (Function Call) بخرد. منشی لیست تامین کنندگان را بررسی می کند و متوجه می شود که یک تامین کننده قهوه آمریکانو با Meituan یا سیستم خرید یکپارچه شرکت (پیاده سازی MCP Server) ادغام شده است. سپس منشی تامین کننده را در سیستم خرید (MCP Client) پیدا می کند و سفارش می دهد.
قبلاً، بدون MCP، وقتی LLM یک Function Call صادر می کرد، Agent ترجمه می کرد و مستقیماً به API متصل می شد تا ابزار را فراخوانی کند. هر API به یک حالت فراخوانی جداگانه و یک لیست ابزار تعریف شده و حالت فراخوانی برای Agent برای تفسیر نیاز داشت. با MCP، بسیاری از API ها را می توان مستقیماً از طریق MCP Client تامین کننده سفارش داد که در وقت و تلاش Agent صرفه جویی می شود. با این حال، Function Call LLM بدون تغییر باقی می ماند، همچنان در قالب {tool: ‘buy coffee’, ‘type’: ‘Americano’} است.
با تمایز بین Function Call و MCP، واضح می شود که MCP تعیین نمی کند کدام ابزار استفاده شود و نه برنامه ریزی وظیفه یا قصد کاربر را انجام می دهد. این جنبه ها در حوزه لایه Agent قرار می گیرند. MCP به سادگی یک رابط ابزار یکپارچه ارائه می دهد و به یک پروتکل استاندارد شناخته شده در صنعت تبدیل می شود.
چالش های توسعه MCP و چشم انداز بازار
معمای توسعه
از فوریه، جامعه توسعه هوش مصنوعی شاهد یک ‘هجوم طلایی MCP’ بوده است. در غیاب یک فروشگاه برنامه رسمی، هزاران ابزار داوطلبانه با پروتکل MCP در عرض سه ماه ادغام شده اند.
این رشد سریع، MCP را در کانون توجه صنعت قرار داده است، اما شکاف بین آرزو و واقعیت را نیز آشکار کرده است. توسعه دهندگان در ابتدا MCP را به عنوان یک ‘کلید جهانی’ می دیدند، اما متوجه شده اند که بیشتر شبیه یک ‘آچار تخصصی’ است که در سناریوهای خاص برتری دارد اما در سناریوهای دیگر کمتر موثر است.
شرکت کنندگان MCP را می توان به عنوان برنامه های کاربردی سرویس گیرنده محلی، برنامه های کاربردی سرویس گیرنده ابری و توسعه دهندگان سرور MCP دسته بندی کرد. برنامه های محلی شبیه به دستیاران هوش مصنوعی محلی هستند، در حالی که برنامه های کاربردی سرویس گیرنده ابری شبیه به نسخه های مبتنی بر وب ChatGPT هستند. توسعه دهندگان سرور MCP ارائه دهندگان واقعی ابزار هستند که باید API های خود را مجدداً بسته بندی کنند تا مطابق با قوانین MCP باشند.
ظهور MCP در ابتدا مورد استقبال برنامه های کاربردی سرویس گیرنده محلی قرار گرفت، اما برنامه های کاربردی سرویس گیرنده ابری و توسعه دهندگان سرور MCP با چالش هایی روبرو شدند.
MCP از برنامه کاربردی Claude Desktop Anthropic سرچشمه گرفته است که در ابتدا به عنوان یک پروتکل رابط برای فراخوانی فایل ها و عملکردهای محلی طراحی شده بود و عمیقاً در نیازهای سمت سرویس گیرنده ریشه دارد.
برای کاربران سرویس گیرنده محلی، MCP نشان دهنده یک انقلاب بود و یک جعبه ابزار بی نهایت قابل گسترش ارائه می داد که به کاربران اجازه می داد تا به طور مداوم قابلیت های دستیاران هوش مصنوعی خود را گسترش دهند.
برنامه های کاربردی سرویس گیرنده محلی مانند Cursor و Claude Desktop از MCP برای فعال کردن کاربران برای افزودن پویا ابزارها بر اساس نیازهای فردی استفاده کرده اند و به گسترش نامحدود قابلیت های دستیار هوش مصنوعی دست یافته اند.
MCP یک نقطه درد اصلی در توسعه سرویس گیرنده محلی را برطرف می کند: چگونه برنامه های هوش مصنوعی را قادر می سازیم تا به طور یکپارچه با محیط های محلی و ابزارهای خارجی بدون توسعه رابط های جداگانه برای هر ابزار تعامل داشته باشند. این پروتکل یکپارچه به طور قابل توجهی هزینه های ادغام را کاهش می دهد و به استارت آپ های کوچک و توسعه دهندگان فردی میانبری برای ساخت برنامه های هوش مصنوعی غنی از ویژگی با منابع محدود ارائه می دهد.
با این حال، جذابیت MCP هنگام در نظر گرفتن توسعه سمت سرور (MCP Server) و سرویس گیرنده های ابری کاهش می یابد. نسخه های اولیه MCP از یک مکانیسم پیوند دوگانه برای سرورهای ابری (از راه دور) استفاده می کردند، با استفاده از یک اتصال طولانی SSE برای انتقال یک طرفه پیام از سرور به سرویس گیرنده و یک اتصال کوتاه HTTP برای ارسال پیام ها.
این رویکرد برای بازخورد و مداخله به موقع کاربر به خوبی کار می کرد، اما یک سری چالش های مهندسی در محیط های سمت سرور ایجاد کرد.
اولاً، پیاده سازی رابط MCP نشان دهنده حجم کار اضافی برای ارائه دهندگان خدمات بزرگ سازمانی است، بدون اینکه لزوماً مزایای متقابلی به دست آورد. این خدمات اغلب دارای سیستم های API بالغ هستند و ارائه یک لایه سازگاری MCP اضافی ممکن است فقط هزینه های نگهداری را افزایش دهد بدون اینکه ارزش قابل توجهی ایجاد کند. بسیاری از برنامه های کاربردی در سطح سازمانی مکانیسم های فراخوانی ابزار بسته و قابل کنترل را بر اکوسیستم باز MCP ترجیح می دهند.
علاوه بر این، برای رسیدگی به فراخوانی های همزمانی بالا، خدمات MCP اغلب باید به معماری های چند سروری مقیاس شوند. مدل اتصال دوگانه MCP پیچیدگی آدرس دهی متقابل دستگاه را معرفی می کند. هنگامی که یک اتصال طولانی روی یک سرور برقرار می شود و یک درخواست به سرور دیگری مسیریابی می شود، یک مکانیسم صف پخش اضافی برای هماهنگی این اتصالات توزیع شده مورد نیاز است که به طور قابل توجهی دشواری پیاده سازی و هزینه های نگهداری را افزایش می دهد.
ثانیاً، MCP در حوزه برنامه های کاربردی ابری محدودیت هایی دارد. Agent های هوش مصنوعی ابری (Agent های سمت سرور) معمولاً در خدمات بدون حالت اجرا می شوند، وظایف را پس از پذیرش پردازش می کنند و پس از اتمام، منابع را آزاد می کنند. استفاده از MCP Client در سمت سرور نیاز به ایجاد موقت یک پیوند SSE، ارسال یک درخواست فراخوانی ابزار، دریافت نتیجه از SSE و سپس بستن پیوند SSE دارد که یک رویکرد ناکارآمد است که پیچیدگی را افزایش می دهد و عملکرد را کاهش می دهد. یک درخواست RPC واحد باید در این سناریو کافی باشد.
در عمل، برنامه های کاربردی ابری که از MCP استفاده می کنند اغلب به مجموعه ابزارهای از پیش تعیین شده تکیه می کنند و از قابلیت امضای MCP برای کشف ابزار پویا و بارگیری انعطاف پذیر استفاده نمی کنند.
حالت تعامل داده ای محیط های ابری توانایی استفاده آزادانه از ابزارها را آنطور که MCP در نظر گرفته بود محدود می کند. این امر مستلزم یک فرآیند بسیار استاندارد برای فراخوانی ابزارهای خاص و کدگذاری شده است که انعطاف پذیری را قربانی می کند.
تیم MCP نسبت به بازخورد کاربران واکنش نشان داده است. پس از دریافت بازخورد از توسعه دهندگان سمت سرور، MCP پروتکل خود را در 26 مارس به روز کرد و انتقال SSE اصلی را با انتقال HTTP جریانی جایگزین کرد. پروتکل جدید از سناریوهای خدمات بدون حالت که فقط به درخواست های فراخوانی ابزار واحد نیاز دارند و الزامات فشار در زمان واقعی که قبلاً از طریق پیوندهای دوگانه HTTP + SSE برآورده شده بود، پشتیبانی می کند.
این پیشرفت ها نشان می دهد که مشکلات فعلی MCP ناشی از محدودیت های طراحی اولیه است، اما غیرقابل حل نیستند.
بی نظمی بازار
چالش دیگر پیش روی MCP، قابلیت استفاده پایین بسیاری از پیاده سازی ها در بازار است.
بازار فعلی MCP یک چرخه هیاهوی فناوری معمولی را تجربه می کند. شبیه به هرج و مرج اولیه App Store، کمتر از 20٪ از هزاران ابزار MCP موجود در حال حاضر دارای ارزش عملی هستند. بسیاری از پیاده سازی ها دارای مشکلات جدی هستند، از خطاهای پیکربندی ساده گرفته تا عدم قابلیت استفاده کامل. برخی بدون آزمایش کافی به بازار عرضه می شوند، در حالی که برخی دیگر محصولات آزمایشی هستند که هرگز برای استفاده عملی در نظر گرفته نشده اند.
یک مسئله اساسی تر این است که ممکن است بسیاری از پیاده سازی های MCP مورد نیاز بازار نباشند. بسیاری از ابزارهایی که از طریق MCP ارائه می شوند، به سادگی API های مجدداً بسته بندی شده هستند که قبلاً در دسترس بودند و قبل از ظهور MCP استفاده می شدند و ارزش منحصر به فرد کمی اضافه می کنند.
به عنوان مثال، ده ها سرویس جستجو از طریق MCP ارائه می شوند، اما کیفیت آنها به طور قابل توجهی متفاوت است. برخی از خدمات ممکن است نادرست یا کند باشند و آنها را کمتر از راه حل های موجود مطلوب کند.
علاوه بر این، MCP فاقد یک سیستم ارزیابی قوی است و انتخاب مناسب ترین ابزار بر اساس معیارهای قابل اعتماد را برای Agents دشوار می کند. این فرآیند انتخاب ناکارآمد، منابع محاسباتی را هدر می دهد، زمان تکمیل وظیفه را افزایش می دهد و تجربه کاربر را کاهش می دهد.
عدم وجود یک سیستم ارزیابی، انتخاب مناسب ترین ابزار را برای عاملان دشوار می کند. اگر چندین سرویس MCP ابزارهایی با نام ها و توضیحات مشابه ارائه دهند، عامل ممکن است برای انتخاب بهترین گزینه با مشکل مواجه شود که منجر به هدر رفتن نشانه ها و کاهش کارایی می شود.
موفق ترین برنامه های کاربردی هوش مصنوعی اغلب رویکردی برعکس اتخاذ می کنند و ابزارهای دقیق تری را به جای تعداد بیشتری از ابزارها ارائه می دهند. Manus، به عنوان مثال، علیرغم وجود آن، تصمیم گرفت به جای پذیرش پروتکل MCP، برنامه های کاربردی داخلی بسازد. Manus دقت و پایداری تماس را بر ادغام با اکوسیستم MCP اولویت داد.
ویرایشگرهای کد مانند Cursor عملکردهای توسعه داخلی دارند و بیشتر ابزارهای MCP خارجی را زائد می کنند.
وضعیت آشفته فعلی بازار MCP لزوماً نشانه شکست نیست، بلکه یک مرحله ضروری از رشد برای هر اکوسیستم فناوری نوظهور است. سابقه تاریخی نشان می دهد که این گسترش بیش از حد اولیه به تدریج از طریق مکانیسم های انتخاب بازار همگرا می شود و با ارزش ترین عناصر را پشت سر می گذارد.
این فرآیند به صنعت اجازه می دهد تا از چالش های فعلی بیاموزد و یک چارچوب MCP قوی تر و قابل اعتمادتر ایجاد کند. شبیه به اینکه چگونه حباب دات کام منجر به نوآوری های تغییر دهنده بازی در تجارت الکترونیک و رسانه های اجتماعی شد، روند MCP ممکن است منجر به یک اکوسیستم ابزار ساده تر و با ارزش تر شود.
نگرش باز تیم MCP نسبت به بازخورد کاربران دلگرم کننده است و صنعت به ابزارهای بهتری برای ارزیابی و اطمینان از کیفیت خدمات MCP نیاز دارد که به ایجاد اکوسیستم قابل استفاده تر کمک می کند.
MCP خوب است، درمان قطعی نیست
مسائل ذکر شده در بالا از محدودیت ها و کاستی های MCP ناشی می شوند و آنچه را که می تواند به طور واقع بینانه به دست آورد برجسته می کنند. با این حال، انتقادات دیگر از انتظارات غیرواقعی ناشی می شوند.
یکی از انتقادات اخیر MCP را یک پروتکل معیوب می داند زیرا الگوهای تعامل بین LLM ها و MCP را دیکته نمی کند.
برخی انتظار دارند که MCP به طور خودکار تصمیم گیری سیستم هوش مصنوعی را بهبود بخشد یا کارایی برنامه ریزی وظیفه را افزایش دهد. این انتظار ابزارها را با صنعتگران اشتباه می گیرد.
این مشکل ناشی از عدم تطابق شناختی است - انتظار می رود که یک پروتکل ارتباطی وظایف یک سیستم هوشمند را انجام دهد. این مانند سرزنش USB برای عدم ویرایش عکس ها یا سرزنش استانداردهای 5G برای عدم نوشتن کد است. MCP در درجه اول یک ‘سوکت ابزار’ استاندارد است که سازگاری پلاگین را تضمین می کند تا اینکه دیکته کند کدام دستگاه را استفاده کنید یا چگونه.
اثربخشی فراخوانی ابزار Agent به عواملی مانند مهارت انتخاب ابزار، مهارت های برنامه ریزی وظیفه و درک زمینه بستگی دارد که هیچ کدام در حوزه MCP قرار نمی گیرند. MCP فقط یک رابط ابزار استاندارد را تضمین می کند، نه اینکه چگونه این ابزارها انتخاب و ترکیب شوند.
ما اغلب به دنبال گلوله های نقره ای در فناوری هستیم، راه حل های کاربردی جهانی. مانند اصل ‘بدون گلوله نقره ای’ در مهندسی نرم افزار، استفاده از ابزار هوش مصنوعی هیچ راه حل جادویی ندارد. یک سیستم هوش مصنوعی قوی به اجزای طراحی شده نیاز دارد: LLM ها برای درک و تولید، چارچوب های Agent برای برنامه ریزی و اجرا، و MCP متمرکز بر رابط های ابزار یکپارچه.
MCP طراحی پروتکل خوبی را نشان می دهد - تمرکز بر یک مشکل و حل خوب آن، به جای همه چیز. محدودیت آن به پیشرفت آن در ادغام ابزار سمت سرویس گیرنده کمک می کند.
موجودیت هایی مانند Qwen Alibaba، ‘Xinxiang’ Baidu و Kouzi Space ByteDance پروتکل MCP را می پذیرند و سعی می کنند اکوسیستم های MCP داخلی کارآمدتری ایجاد کنند.
با این حال، تفاوت های کلیدی در استقرار وجود دارد: Baidu و ByteDance تهاجمی تر هستند. Baidu یک رویکرد C-end را امتحان می کند، چندین مدل هوش مصنوعی و ابزار خارجی را از طریق ‘Xinxiang’ (Kokone) ادغام می کند و از پروتکل MCP استفاده می کند، در درجه اول برای دستگاه های تلفن همراه، برای ادغام در زندگی روزمره کاربر و تشویق به پذیرش.
Kouzi Space ByteDance بیش از 60 پلاگین توسعه MCP دارد. از طریق یک صفحه وب قابل دسترسی است، همچنین یک IDE بومی هوش مصنوعی، Trae را راه اندازی کرد که از MCP پشتیبانی می کند و در درجه اول سناریوهای بهره وری را هدف قرار می دهد.
Alibaba پروتکل MCP را در محصولاتی مانند Alipay ادغام کرد و امکان فراخوانی ابزار هوش مصنوعی با یک کلیک را فراهم کرد و مدل Qwen3 منبع باز را منتشر کرد که از پروتکل MCP پشتیبانی می کند و قابلیت های Agent خود را افزایش می دهد.
توسعه دهندگان Tencent Cloud یک مجموعه توسعه هوش مصنوعی را منتشر کردند که از خدمات میزبانی پلاگین MCP پشتیبانی می کند. موتور دانش مدل بزرگ Tencent Cloud کاربران را قادر می سازد تا پلاگین های MCP را فراخوانی کنند. عامل هوشمند توسعه نرم افزار Craft که توسط CodeBuddy Tencent Cloud راه اندازی شده است، با اکوسیستم باز MCP سازگار است. علاوه بر این، Tencent Maps و Tencent Cloud Storage MCP SERVER خود را منتشر کرده اند.
استفاده از ابزار هوش مصنوعی ممکن است از عملکرد مستقیم و تک ابزاری به همکاری Agent حرفه ای تکامل یابد، همانطور که سبک های برنامه نویسی از زبان اسمبلی به جهت گیری شی تکامل یافته اند.
در این الگو، MCP ممکن است به سادگی بخشی از زیرساخت اساسی شود، به جای یک رابط رو به کاربر یا توسعه دهنده. یک طرح کامل تر ممکن است به معماری هایی مانند Agent to Agents (A2A) برای افزایش برنامه ریزی وظیفه و کارایی انتخاب ابزار با افزایش سطوح انتزاع نیاز داشته باشد.
با بازگرداندن MCP به نقش ‘پروتکل’ خود، می توانیم قدرت واقعی آن را برای هدایت استانداردسازی صنعت تشخیص دهیم - این ممکن است ارزشمندترین لحظه ‘راز زدایی’ در تکامل فناوری باشد.