MCP همیشه ایده بدی بود؟

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

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

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

با گذشت زمان، MCP تحت نظارت آنتروپیک به تکامل خود ادامه داد تا اینکه در نهایت در سال 2025 به بنیاد هوش مصنوعی Agentic، تحت بنیاد لینوکس، اهدا شد. 2

با رشد بسیار زیاد در پذیرش، کاربران شروع به اضافه کردن سرورهای MCP زیادی به تنظیمات خود کردند و آنها شروع به برخورد با مشکل bloat زمینه کردند. هر سرور با ابزارهای متعددی همراه بود که هر کدام دارای طرحی خاص خود بود که شروع به بارگذاری بیش از حد زمینه همه این مدل ها کرد. توسعه دهندگان هارنس ترفندهای زیادی در این زمینه پیدا کردند، از جمله الگوهای جستجو/اجرای عمومی که اکنون توسط پلتفرم هایی مانند Composio، MintMCP و Pipedream ارائه می شود.

همه آنها به طور مؤثر مشکل داشتن یک مکان برای قرار دادن اعتبارنامه های شما برای سرویس های خارجی مختلف را حل می کنند و به نماینده شما مجموعه حداقلی از ابزارها (برای کاهش نفخ زمینه) را می دهند که می تواند برای دسترسی به آنها استفاده کند. من می خواهم روشن کنم که این یک چیز خوب است، برای کوتاه مدت.

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

مدل ها بهتر شدند آنها اکنون می توانند کد را بر روی کامپیوتر اجرا کنند، در مورد پایگاه های کد بزرگ استدلال کنند، و به طور کلی بسیار مستقل تر از همیشه عمل می کنند. بخش بزرگی از آن کار نوشتن/اجرای اسکریپت ها برای اهداف کدنویسی بود. یک عارضه جانبی (اگرچه اینطور است؟) این است که اکنون آنها در فراخوانی مستقیم APIها خوب هستند. آنها می توانند اسکریپت بنویسند، چندین سرویس مختلف بنویسند، و API هایی را که قبلا ندیده اند فراخوانی کنند، همگی در جریان های کاری مفید با کمترین مداخله از سمت کاربر.

LLM ها در این کار بسیار خوب شده اند، Cloudflare حتی حالت کد را راه اندازی کرد، روشی بهتر برای استفاده از MCP با داشتن LLM ها که فراخوان های مختلف را در اسکریپت هایی که می توانند در یک جعبه شنی اجرا شوند، ترکیب می کنند. 3

اما حتی بهتر از آن، LLM ها نحوه استفاده از دستور --help را برای کشف CLI ها کشف کرده اند، بنابراین دیگر نیازی به سرورهای MCP برای دسترسی به بسیاری از سرویس های موجود از طریق API های مستند یا CLI ندارند. اکثر سرورهای MCP سرویس از راه دور، در نهایت APIهایی را که از قبل وجود داشته اند، بسته بندی می کنند.

ما اکثر سرورهای MCP خود را حذف می کنیم. همین است. عواملی با دسترسی ترمینال می‌توانند جایگزین اکثر سرورهای MCP شوند و اغلب توانایی بیشتری دارند، هنوز هم برخی مشکلات وجود دارد، مانند CLI‌هایی که پاسخ‌های قابل خواندن توسط ماشین (JSON/XML و غیره) را برمی‌گردانند، که معمولا بسیار پرمخاطب و در استفاده از توکن‌ها سنگین هستند، اما ما راه‌هایی برای رفع این مشکل داریم.

بسیاری از جایگزین ها از قبل وجود دارد: API های HTTP مستند، مذاکره محتوای استاندارد، و مکانیسم های احراز هویت بالغ.

ما باید شروع به استانداردسازی کنیم که چگونه عامل ها مستقیما از API های HTTP استفاده می کنند. به عنوان مثال، کلاینت‌های عامل می‌توانند سرصفحه‌ها را ضمیمه کنند تا خود را به عنوان عامل شناسایی کنند، و سرورها می‌توانند به‌طور خودکار داده‌های پاسخ را به‌عنوان Markdown یا متن به جای HTML یا JSON پرمخاطب برای آنها ارسال کنند.

تعداد فزاینده ای از سرورهای دوستدار LLM، به ویژه سایت های متنی مانند سایت های مستندسازی، هدر Accept: text/markdown را ارج می نهند. این سرورها می‌توانند به‌جای پاسخ HTML که معمولا ارسال می‌کنند، به‌طور خودکار یک فایل Markdown رندر شده ارسال کنند. نوع رسانه به خودی خود استاندارد شده است و استفاده از آن برای مذاکره محتوای عامل محور در حال پذیرش است.

سایت های مستندسازی با استفاده از سربرگ Accept-Language

اخیرا، یک مهندس Vercel از هارنس ها خواست تا زبان برنامه نویسی مورد علاقه مشتری را ارسال کنند، بنابراین سایت های مستندسازی می توانند نمونه های خاص تری را ارائه دهند. برای مثال، افزودن پایتون می‌تواند به جای ارسال چیزی عمومی، اسناد را برای Python SDK اولویت‌بندی کند. Tobi Lutke از Shopify آنقدر آن را دوست داشت که اکنون در Docs Shopify ارسال می شود.

Malte Ubl (@cramforce): درخواست برای مهارها: دوست دارم اکنون "Accept: text/markdown" را ارسال کنید. مورد بعدی این است: زبان برنامه نویسی مورد علاقه خود را در هدر Accept-Language قرار دهید.

توبی لوتکه (@tobi): ایده عالی. از این در اسناد Shopify پشتیبانی می کند.

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

Anthropic، "معرفی پروتکل زمینه مدل"، 25 نوامبر 2024. ↩

آنتروپیک، «اهدای پروتکل بافت مدل و تأسیس بنیاد هوش مصنوعی عامل»، 9 دسامبر 2025. ↩

کنتون واردا و سونیل پای، «حالت کد: راه بهتر برای استفاده از MCP»، وبلاگ Cloudflare، 26 سپتامبر 2025. ↩