اكتشاف أدوات MCP لوكلاء الذكاء الاصطناعي للمؤسسات

Introduction

Agentic AI systems are defined not just by reasoning, but by action. Modern agents don’t stop at generating responses - they invoke tools, call APIs, trigger workflows, and interact with external systems to complete tasks end to end. As agents become autonomous, tools become first-class execution primitives.

In early implementations, tool usage is often tightly controlled: a small, static set of tools is hardcoded into the agent configuration. This works for prototypes, but it breaks down quickly in real-world systems where:

• Multiple teams publish tools independently
• Tools evolve, version, and deprecate over time
• Different environments expose different capabilities
• Security and access control matter

At enterprise scale, the challenge is no longer how to call a tool, but how an agent discovers which tools exist, which ones it is allowed to use, and which ones are appropriate in a given context.

This is where MCP tool discovery and the MCP Gateway become critical system capabilities.

In TrueFoundry, agents do not discover tools by directly querying MCP servers or relying on static configuration. Instead, tool discovery is mediated through the MCP Gateway, which sits between agents and MCP servers and enforces discovery using identity, environment, and policy context.

What MCP Tool Discovery means?

At a high level, MCP tool discovery refers to the ability for an AI agent to dynamically learn about available tools exposed by MCP servers and decide which ones it can use at runtime.

However, in enterprise systems, discovery is often misunderstood.

MCP tool discovery is:

• Dynamic: tools are discovered at runtime, not hardcoded at build time
• Context-aware: discovery depends on environment, workspace, agent identity, and permissions
• Filtered: agents only see tools they are allowed to use
• Decoupled from invocation: discovery answers what exists, invocation answers how to call it

In practice, discovery involves exposing structured metadata about tools - capabilities, schemas, ownership, versions - so agents can reason about which tools to use before invoking them.

MCP tool discovery is not:

• A static list of tools baked into agent prompts
• A manual configuration step updated by developers
• A UI-only registry that agents cannot query programmatically
• A flat catalog where every agent sees every tool

Treating discovery as any of the above leads to brittle systems where agents either fail silently or operate with excessive privileges.

Why This Distinction Matters

In agentic AI systems, discovery happens before action. If discovery is incomplete, insecure, or outdated, agents will make poor decisions, even if the underlying tools work perfectly.

This is why MCP tool discovery must be designed as a runtime, policy-aware capability, not a static configuration artifact. The sections that follow explore why naive approaches fail at scale and how enterprise platforms approach MCP tool discovery correctly.

Why MCP Tool Discovery Breaks at Enterprise Scale

In small setups, MCP tool discovery is often treated as a static concern. Tools are manually listed, agents are configured with fixed toolsets, and changes are infrequent. This model fails quickly once agentic systems move into production.

At enterprise scale, several pressures emerge simultaneously.

First, tool ownership becomes decentralized. Different teams publish MCP tools for different domains- data access, internal workflows, observability, ticketing, infra automation. Hardcoding tool lists requires constant coordination and redeployments, which does not scale across teams or environments.

Second, environments diverge. The set of tools available in development, staging, and production is rarely identical. Some tools are region-specific, others are restricted to certain environments or compliance zones. Static discovery creates drift, where agents either fail due to missing tools or accidentally reference tools that should not exist in that context.

Third, security boundaries matter. In enterprise systems, not every agent should discover every tool. Discovery itself becomes a privileged operation. If agents can see tools they are not authorized to use, you introduce:

• Information leakage about internal capabilities
• Over-permissioned agents
• Increased blast radius when agents behave unexpectedly

Finally, agent autonomy amplifies mistakes. In agentic systems, discovery happens repeatedly and automatically. A single incorrect discovery result can propagate across many executions, leading to repeated failures or unsafe tool usage.

These failures share a common root cause: discovery is treated as configuration, when it should be treated as a runtime, policy-enforced capability.

This is the point where MCP tool discovery must move closer to the execution layer - where context, identity, and policy are available in real time.

MCP Tool Discovery via the TrueFoundry MCP Gateway

In TrueFoundry, MCP tool discovery is mediated through the MCP Gateway, which runs as part of the AI Gateway. Agents do not discover tools by querying MCP servers directly. Instead, all discovery and invocation flows through the gateway.

This design ensures that discovery remains consistent, policy-aware, and auditable across environments.

MCP Servers as Gateway-Managed Capabilities

Enterprise MCP servers in TrueFoundry expose tools using the MCP protocol, but their availability is controlled at the gateway layer through identity, environment, and policy enforcement. This includes:

• Common tools MCP servers provided by TrueFoundry
• Custom MCP servers deployed by teams
• Environment- or workspace-specific MCP servers

الأدوات ليست مرئية عالميًا بشكل افتراضي. بل تُعرض للوكلاء فقط عبر البوابة، بناءً على تهيئة المنصة وضوابط الوصول.

هذا يمنع الوكلاء من اكتشاف أدوات موجودة ولكنها غير مخصصة لبيئتهم أو عبء عملهم.

الاكتشاف في ساحة تجربة بوابة الذكاء الاصطناعي

توفر ساحة تجربة بوابة الذكاء الاصطناعي نظرة واضحة على كيفية عمل اكتشاف أدوات MCP أثناء التشغيل.

عند إنشاء جلسة وكيل:

• تستعلم البوابة عن خوادم MCP المسجلة
• تطبق عوامل تصفية مساحة العمل والبيئة والسياسة
• تُرجع فقط الأدوات المرئية لسياق الوكيل هذا

ونتيجة لذلك، فإن الأدوات المعروضة في ساحة التجربة هي ليست كتالوجًا ثابتًا. إنها تمثل الـ عرض الاكتشاف الدقيق التي سيراها الوكيل أثناء التنفيذ.

هذا يجعل سلوك الاكتشاف قابلاً للاختبار ويمكن التنبؤ به قبل نشر الوكلاء في بيئة الإنتاج.

تدفق الاكتشاف والاستدعاء أثناء التشغيل

أثناء التشغيل، يتبع اكتشاف أدوات MCP مسارًا ثابتًا:

1. يطلب وكيل اكتشاف الأداة
2. تُقيّم بوابة MCP:
   • هوية الوكيل
   • مساحة العمل والبيئة
   • خوادم MCP المسجلة
   • سياسات الاكتشاف
3. يتلقى الوكيل مجموعة مصفاة من الأدوات
4. يتم تنفيذ استدعاء الأداة عبر نفس مسار البوابة، مع تفويض وتطبيق منفصلين.

يتم فصل الاكتشاف والاستدعاء عمدًا. يكشف الاكتشاف عن الإمكانيات، وليس حقوق التنفيذ.

لماذا تعتبر بوابة MCP مهمة

من خلال وضع اكتشاف أدوات MCP خلف البوابة، تضمن TrueFoundry ما يلي:

• لا يكتشف الوكلاء أبدًا أدوات خارج نطاقهم المسموح به
• يعكس الاكتشاف ظروف التشغيل الحقيقية
• تظل رؤية الأدوات متسقة عبر بيئات التطوير والإنتاج
• تنطبق الحوكمة والتدقيق بالتساوي على الاكتشاف والاستدعاء

هذا ما يسمح لاكتشاف أدوات MCP بالتوسع بأمان مع زيادة استقلالية الوكيل.

الأمان والحوكمة والتحكم في الوصول في اكتشاف أدوات MCP

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

في ترو فاوندري، يتم التعامل مع اكتشاف أدوات MCP على أنه عملية مميزة تفرضها السياسات، وليس مجرد بحث سلبي عن البيانات الوصفية.

الاكتشاف المحدد بالهوية

يتم تقييم كل طلب اكتشاف في سياقه، بما في ذلك:

• هوية الوكيل أو حساب الخدمة
• مساحة العمل وحدود المشروع
• بيئة التنفيذ (تطوير، اختبار، إنتاج)
• سياسات الحوكمة على مستوى المؤسسة

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

الاكتشاف والاستدعاء يتشاركان نفس نموذج الثقة

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

يكشف الاكتشاف إمكانيات، وليس حقوق التنفيذ. يتم تقييم الاستدعاء دائمًا بشكل مستقل ولا يُستدل عليه أبدًا بمجرد الاكتشاف.

قابل للتدقيق افتراضيًا

بالنسبة للبيئات المنظمة، يجب أن يكون سلوك الاكتشاف قابلاً للتفسير. تجعل TrueFoundry اكتشاف أدوات MCP قابلاً للملاحظة والتدقيق:

• يتم تسجيل طلبات الاكتشاف وتتبعها
• يمكن مراجعة قرارات رؤية الأداة
• يمكن تدقيق نشاط الاكتشاف أثناء مراجعات الأمان والامتثال

هذا يحول اكتشاف أدوات MCP من عملية داخلية غامضة إلى قدرة نظام قابلة للحوكمة.

أنماط الفشل الشائعة في اكتشاف أدوات MCP وكيف تتجنبها TrueFoundry

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

في TrueFoundry، يتم فرض اكتشاف أدوات MCP من خلال MCP Gateway، والذي يطبق ضوابط المصادقة والترخيص والسياسة بشكل متسق عبر الاكتشاف والاستدعاء. وهذا يمنع أنماط الفشل الأكثر شيوعًا التي تظهر في الأنظمة الوكيلة التشغيلية.

نمط الفشل 1: قوائم الأدوات المضمنة في الكود أو القديمة

ماذا يحدث
يتم تهيئة الوكلاء بقوائم أدوات ثابتة أو تكوينات مضمنة في المطالبة. ومع تطور خوادم MCP، تتم إضافة الأدوات أو إهمالها أو إعادة تكوينها، ويبدأ الوكلاء في العمل بناءً على افتراضات قديمة مما يؤدي إلى حالات فشل أو سلوك غير آمن.

كيف تتجنب TrueFoundry هذا
يتم اكتشاف الأدوات ديناميكيًا في وقت التشغيل عبر بوابة MCP. تستعلم البوابة عن خوادم MCP المسجلة (بما في ذلك خوادم MCP للأدوات الشائعة) وتعيد المجموعة الحالية والموثوقة من الأدوات المتاحة لسياق الوكيل. لا يعتمد الوكلاء أبدًا على كتالوجات أدوات مكتوبة بشكل ثابت أو قديمة.

نمط الفشل 2: الوكلاء ذوو الصلاحيات المفرطة

ماذا يحدث
لتجنب حالات فشل الاكتشاف، تعرض الفرق جميع الأدوات لجميع الوكلاء. يزيد هذا من نطاق التأثير ويجعل استخدام الأدوات غير المقصود أو غير الآمن أكثر احتمالًا.

كيف تتجنب TrueFoundry هذا
يتم الاكتشاف محدد النطاق حسب الهوية والسياسة. تقوم بوابة MCP بتقييم هوية الوكيل ومساحة العمل والبيئة وقواعد الحوكمة قبل إرجاع نتائج الاكتشاف. يرى الوكلاء فقط الأدوات التي يُسمح لهم باكتشافها صراحةً، لا أكثر.

يُعامل الاكتشاف نفسه على أنه عملية مميزة، وليس نقطة نهاية بيانات وصفية عامة.

نمط الفشل 3: انجراف البيئة

ماذا يحدث
تكتشف العوامل أدوات موجودة في بيئة التطوير أو الاختبار المرحلي ولكنها غير متاحة أو مقيدة في بيئة الإنتاج. يسبب هذا أعطالاً أثناء الترقية أو سلوكًا غير متوقع أثناء التشغيل.

كيف تتجنب TrueFoundry ذلك
الاكتشاف هو مراعٍ للبيئة بشكل افتراضي. تعرض بوابة MCP فقط الأدوات المسجلة والممكّنة لـ بيئة التنفيذ الحالية. وهذا يضمن أن ما تكتشفه العوامل في ساحة لعب بوابة الذكاء الاصطناعي هو بالضبط ما ستراه عند التشغيل.

لا يوجد تباين بين التجريب والتنفيذ في بيئة الإنتاج.

نمط الفشل 4: يصبح الاكتشاف بابًا خلفيًا للاستدعاء

ماذا يحدث
تسمح بعض تطبيقات MCP عن غير قصد لواجهات برمجة تطبيقات الاكتشاف بأن توحي بحقوق الاستدعاء أو تكشف عن تفاصيل الاستدعاء التي يمكن للعوامل استغلالها.

كيف تتجنب TrueFoundry ذلك
الاكتشاف والاستدعاء هما مفصولان تمامًا:

• الاكتشاف يكشف عن القدرات والبيانات الوصفية
• يمر الاستدعاء دائمًا عبر بوابة MCP لـ المصادقة والتفويض وتطبيق السياسات

اكتشاف الوكيل لأداة ما لا يعني أنه يمكنه استدعاؤها. يتم تقييم الاستدعاء بشكل مستقل عند كل طلب.

نمط الفشل 5: لا يوجد مسار تدقيق

ما الذي يحدث
لا تستطيع الفرق تفسير سبب استخدام الوكيل لأداة معينة أو محاولته استخدامها، مما يجعل الاستجابة للحوادث ومراجعات الامتثال صعبة.

كيف تتجنب TrueFoundry ذلك
تجعل بوابة MCP كلاً من الاكتشاف والاستدعاء قابلاً للمراقبة والتدقيق:

• يتم تسجيل طلبات الاكتشاف ويمكن تتبعها
• يمكن مراجعة قرارات رؤية الأداة
• تُعزى محاولات الاستدعاء إلى هوية الوكيل وسياقه

يتيح ذلك تحليل ما بعد الحادث ويدعم عمليات التدقيق التنظيمية والأمنية.

لماذا هذا مهم

مع ازدياد استقلالية الوكلاء، تتفاقم إخفاقات الاكتشاف بسرعة. يمكن أن يؤثر خطأ واحد في التكوين على آلاف عمليات التنفيذ عبر البيئات المختلفة.

من خلال فرض اكتشاف أدوات MCP عند طبقة البوابة، تضمن TrueFoundry أن يكون الاكتشاف:

• ديناميكيًا (محدث باستمرار)
• مراعٍ للسياسات (محدد النطاق حسب الهوية والبيئة)
• آمنًا (لا يوجد وصول ضمني)
• قابلًا للتدقيق (قابل للتتبع افتراضيًا)

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

الخلاصة

في أنظمة الذكاء الاصطناعي الوكيل، لم تعد الأدوات مجرد تكاملات اختيارية—بل هي عناصر تنفيذ أساسية. مع ازدياد استقلالية الوكلاء، تصبح القدرة على اكتشاف الأدوات بأمان ودقة أثناء التشغيل أمرًا بالغ الأهمية للصحة والأمان وقابلية التوسع.

قوائم الأدوات الثابتة، والتكوين اليدوي، والاختراقات الخاصة بالبيئة لا تصمد بمجرد أن تنشر فرق متعددة أدواتها، وتتباعد البيئات، وتعمل الوكلاء باستمرار. عند هذه النقطة، يتوقف اكتشاف أدوات MCP عن كونه ميزة للمطورين ويصبح مشكلة نظامية.

الفكرة المحورية بسيطة: يجب أن يتم الاكتشاف حيث يتوفر السياق والهوية والسياسة في الوقت الفعلي. وبدون ذلك، يعمل الوكلاء إما بمعرفة غير مكتملة أو تكون لديهم صلاحيات مفرطة، وكلاهما ينطوي على مخاطر.

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

بالنسبة للمؤسسات التي تبني أنظمة ذكاء اصطناعي قائمة على الوكلاء، لا يقتصر اكتشاف أدوات MCP على مجرد سرد الأدوات. بل يتعلق بـ التحكم في كيفية تعلم الوكلاء ما يمكنهم فعله. إن التعامل مع الاكتشاف كقدرة أساسية تُنفذ في وقت التشغيل هو ما يجعل استقلالية الوكيل آمنة وقابلة للإدارة وقابلة للتطوير.