# مقال على Hacker News يجادل بأن MCP كان فكرة خاطئة منذ البداية

> **المغزى:** تضخم السياق بتعريفات الأدوات مشكلة حقيقية في بناء الـ agents، لكن البروتوكول الموحد يحمل أيضًا الأذونات والمفاتيح وسجل الاستدعاءات، وهذه لا تختفي مع ذكاء النماذج.

- المصدر: المغزى (https://almaghza.com/a/2026-09-21-mcp-context-bloat-debate/)
- التاريخ: 10 ربيع الآخر - 21 سبتمبر 2026 (2026-09-21)
- القسم: ذكاء اصطناعي
- الوسوم: MCP، AI Agents، Anthropic

نُشر على موقع maharship.com في 14 سبتمبر 2026 مقال بعنوان "Why MCP Was Always a Bad Idea"، ووصل إلى Hacker News في 20 سبتمبر بـ 231 نقطة. وهو رأي كاتب واحد، لا إعلان ولا قرار من أي جهة.

أطلقت Anthropic بروتوكول MCP، أي Model Context Protocol، في نوفمبر 2024، ثم تبرعت به في 2025 لمؤسسة Agentic AI Foundation التابعة لـ Linux Foundation. والفكرة أن يحصل النموذج على بروتوكول ثابت يتصل عبره بالخدمات والأدوات الخارجية.

المشكلة التي يشير إليها المقال لا يكاد يختلف عليها أحد. فكل MCP server يُضاف يحقن في نافذة السياق تعريف كل أداة لديه والـ schema الخاصة بها. ومع عدد قليل من الـ servers، يُستهلك جزء كبير من النافذة قبل أن يبدأ المستخدم بأول سؤال. هذا ما يُعرف بـ context bloat، أي تضخم السياق.

ولهذا ظهرت طبقة كاملة من الأدوات الوسيطة، مثل Composio وMintMCP وPipedream، وظيفتها تقليص ما يصل إلى الـ agent من أدوات. ويصف الكاتب هذه الحلول بأنها جيدة على المدى القصير، لكنه يرى أن ما نُسي هو أن النماذج نفسها تحسنت. فالبروتوكول صُمم لنماذج كانت أضعف بكثير، بينما صارت النماذج الحالية قادرة على قراءة التوثيق واستدعاء API عادية بنفسها.

في المقابل، هناك حجة مضادة قوية. البروتوكول الموحد ليس فقط وسيلة ليفهم النموذج الأدوات، بل هو أيضًا مكان واحد لإدارة الأذونات وحفظ المفاتيح وتسجيل كل استدعاء. وهذه الوظائف لا تختفي عندما يصبح النموذج أذكى.

الواضح حتى الآن أن تضخم السياق مشكلة حقيقية تؤثر في كلفة الـ agents وأدائها. أما غير الواضح فهو أن التخلي عن البروتوكول هو الحل.

## المصادر

- [مقال Why MCP Was Always a Bad Idea](https://maharship.com/blog/why-mcp-was-always-a-bad-idea/)
- [الموقع الرسمي لـ MCP](https://modelcontextprotocol.io/)
- [النقاش على Hacker News](https://news.ycombinator.com/item?id=49779329)