MCP Tool Discovery for Enterprise AI Agents

導入

エージェント型AIシステムは、推論だけでなく、 アクションによって定義されます。現代のエージェントは、応答を生成するだけにとどまりません。ツールを呼び出し、APIを実行し、ワークフローをトリガーし、外部システムと連携して、タスクをエンドツーエンドで完遂します。エージェントが自律的になるにつれて、 ツールはファーストクラスの実行プリミティブとなります。

初期の実装では、ツールの利用は厳しく管理されることがよくあります。少数の静的なツールセットがエージェント設定にハードコードされています。これはプロトタイプには機能しますが、実際のシステムではすぐに破綻します。その理由は次のとおりです。

• 複数のチームがツールを個別に公開する
• ツールは時間とともに進化し、バージョン管理され、非推奨になる
• 異なる環境が異なる機能を提供する
• セキュリティとアクセス制御が重要である

企業規模では、課題はもはや ツールを呼び出す方法ではなく、 エージェントがどのツールが存在し、どのツールの使用が許可されており、特定のコンテキストでどのツールが適切であるかをどのように発見するかです。

ここで重要になるのが MCPツールディスカバリーとMCPゲートウェイが不可欠なシステム機能となる.

TrueFoundryでは、エージェントはMCPサーバーに直接クエリを実行したり、静的な設定に依存したりしてツールを検出することはありません。その代わりに、ツールの検出は MCP Gateway、 エージェントとMCPサーバーの間に位置し、ID、環境、ポリシーのコンテキストを使用して検出を強制します。

MCPツール検出とは？

大まかに言えば、MCPツール検出とは、AIエージェントが 利用可能なツールを動的に学習し によって公開される MCPサーバー そして、実行時にどのツールを使用できるかを決定することです。

しかし、エンタープライズシステムでは、検出はしばしば誤解されています。

MCPツール検出は次のとおりです。

• 動的：ツールは実行時に検出され、ビルド時にハードコードされるわけではありません。
• コンテキスト認識型：検出は、環境、ワークスペース、エージェントのID、および権限に依存します。
• フィルタリングされる：エージェントは、使用を許可されているツールのみを表示します。
• 呼び出しから分離されているディスカバリが答えること： 何が存在するか、インボケーションが答えること： それをどう呼び出すか

実際には、ディスカバリとは、ツールに関する構造化されたメタデータ（機能、スキーマ、所有者、バージョンなど）を公開することで、エージェントが推論できるようにするものです。 どの ツールを呼び出す前に使用すべきか。

MCPツールディスカバリは 次のようにはありません。

• エージェントのプロンプトに組み込まれた静的なツールリスト
• 開発者によって更新される手動の設定手順
• エージェントがプログラムでクエリできないUI専用のレジストリ
• すべてのエージェントがすべてのツールを見るフラットなカタログ

ディスカバリを上記のように扱うと、エージェントがサイレントに失敗するか、過剰な権限で動作するような脆弱なシステムにつながります。

この区別が重要な理由

エージェントAIシステムでは、ディスカバリは アクションの前に行われます。ディスカバリが不完全、安全でない、または古くなっている場合、たとえ基盤となるツールが完全に機能していても、エージェントは誤った判断を下します。

これが、MCPツールディスカバリが〜として設計されなければならない理由です。 ランタイムの、ポリシー対応機能、静的な設定アーティファクトではありません。続くセクションでは、なぜ単純なアプローチが大規模環境で失敗するのか、そしてエンタープライズプラットフォームがMCPツールの検出にどのように適切に取り組むのかを掘り下げていきます。

エンタープライズ規模でMCPツールの検出が破綻する理由

小規模な設定では、MCPツールの検出は静的な懸念事項として扱われることがよくあります。ツールは手動でリスト化され、エージェントは固定のツールセットで構成され、変更は頻繁ではありません。このモデルは、エージェントシステムが本番環境に移行するとすぐに破綻します。

エンタープライズ規模では、いくつかの課題が同時に発生します。

まず、 ツールの所有権が分散化されます。異なるチームが、データアクセス、内部ワークフロー、可観測性、チケット管理、インフラ自動化など、異なるドメイン向けにMCPツールを公開します。ツールリストをハードコーディングすると、絶え間ない調整と再デプロイが必要となり、これはチームや環境をまたいでスケールしません。

次に、 環境が乖離します。開発、ステージング、本番環境で利用できるツールセットは、ほとんど同じではありません。一部のツールは地域固有のものであり、その他は特定の環境やコンプライアンスゾーンに制限されています。静的な検出はドリフト（乖離）を生み出し、エージェントがツールの欠落により失敗したり、そのコンテキストに存在すべきではないツールを誤って参照したりする原因となります。

第三に、 セキュリティ境界が重要になります。エンタープライズシステムでは、すべてのエージェントがすべてのツールを検出できるべきではありません。検出自体が特権操作となります。エージェントが使用を許可されていないツールを見ることができる場合、以下の問題が発生します。

• 内部機能に関する情報漏洩
• 過剰な権限を持つエージェント
• エージェントが予期せぬ動作をした場合の爆発半径の拡大

最後に、 エージェントの自律性が誤りを増幅させます。エージェントシステムでは、検出は繰り返し自動的に行われます。1つの誤った検出結果が多くの実行に伝播し、繰り返し失敗したり、安全でないツールの使用につながる可能性があります。

これらの失敗には共通の根本原因があります。 ディスカバリが設定として扱われていること、本来は ランタイムでポリシー適用済みの機能です。

ここで、MCPツールのディスカバリは、コンテキスト、ID、ポリシーがリアルタイムで利用可能な実行レイヤーに近づく必要があります。

TrueFoundry MCPゲートウェイを介したMCPツールのディスカバリ

TrueFoundryでは、MCPツールのディスカバリは MCPゲートウェイ、AIゲートウェイの一部として動作します。エージェントはMCPサーバーに直接クエリを実行してツールをディスカバリすることはありません。その代わりに、すべてのディスカバリと呼び出しはゲートウェイを介して行われます。

この設計により、ディスカバリは 一貫性があり、ポリシーを認識し、監査可能であること が環境全体で保証されます。

ゲートウェイ管理機能としてのMCPサーバー

エンタープライズMCPサーバー はTrueFoundryでMCPプロトコルを使用してツールを公開しますが、その可用性はID、環境、およびポリシーの適用を通じてゲートウェイ層で制御されます。これには以下が含まれます。

• 共通ツールMCPサーバー （TrueFoundryによって提供されるもの）
• チームによってデプロイされたカスタムMCPサーバー
• 環境またはワークスペース固有のMCPサーバー

ツールはデフォルトではグローバルに表示されません。エージェントには ゲートウェイを介してのみ、プラットフォームの設定とアクセス制御に基づいて表示されます。

これにより、エージェントは、存在するものの自身の環境やワークロード向けではないツールを発見することを防げます。

AI Gateway Playgroundでの検出

AI Gateway Playgroundは、MCPツールの検出が実行時にどのように機能するかについて、具体的な視点を提供します。

エージェントセッションが作成されると:

• ゲートウェイは登録済みのMCPサーバーに問い合わせます
• ワークスペース、環境、ポリシーのフィルターを適用します
• そのエージェントコンテキストに表示されるツールのみを返します

その結果、Playgroundに表示されるツールは 静的なカタログではありません。それらは まさにその検出ビュー をエージェントが実行中に見ることになります。

これにより、エージェントを本番環境にデプロイする前に、検出動作をテスト可能かつ予測可能にできます。

実行時検出と呼び出しフロー

実行時において、MCPツールの検出は一貫したパスをたどります:

1. エージェントがツール検出を要求します
2. MCPゲートウェイは以下を評価します:
   • エージェントのID
   • ワークスペースと環境
   • 登録済みMCPサーバー
   • ディスカバリーポリシー
3. エージェントは フィルタリングされたツールセット
4. ツール呼び出しは、同じゲートウェイパスを介して実行され、認証と強制は個別に適用されます。

ディスカバリーと呼び出しは意図的に分離されています。ディスカバリーは 機能であり、実行権限ではありません。

MCPゲートウェイが重要な理由

MCPツールディスカバリーをゲートウェイの背後に配置することで、TrueFoundryは以下を保証します。

• エージェントが許可された範囲外のツールを発見することはありません。
• ディスカバリーは実際のランタイム条件を反映します。
• ツール可視性は、Playgroundと本番環境で一貫しています。
• ガバナンスと監査は、ディスカバリーと呼び出しの両方に等しく適用されます。

これにより、エージェントの自律性が高まるにつれて、MCPツールディスカバリーを安全に拡張できます。

MCPツールディスカバリーにおけるセキュリティ、ガバナンス、およびアクセス制御

エンタープライズエージェントシステムでは、 ツールディスカバリー自体がセキュリティ境界となります。. エージェントがツールを発見できる場合、たとえ後でその呼び出しがブロックされたとしても、その機能が存在することを暗黙的に学習します。したがって、制御されていない発見は情報漏洩の一形態となります。

TrueFoundry では、MCPツール発見は 特権的でポリシーによって強制される操作として扱われ、受動的なメタデータ検索ではありません。

IDベースの発見

すべての発見リクエストは、以下を含むコンテキスト内で評価されます。

• エージェントのIDまたはサービスアカウント
• ワークスペースとプロジェクトの境界
• 実行環境（開発、ステージング、本番）
• 組織レベルのガバナンスポリシー

エージェントは、 明示的に可視であるツールのみを発見します。エージェントのスコープ外のツールは事実上存在しないため、広範すぎる発見やチーム間の機能漏洩を防ぎます。

発見と呼び出しは同じ信頼モデルを共有します

MCPの実装における一般的な失敗モードは、呼び出しを保護しつつ発見を開放したままにすることです。TrueFoundryは、これを回避するために、 同じ認証、認可、およびポリシーモデル を発見と呼び出しの両方に適用します。

発見は、 機能、実行権限ではありません。呼び出しは常に独立して評価され、発見のみによって示唆されることはありません。

デフォルトで監査可能

規制された環境では、発見の挙動は説明可能である必要があります。TrueFoundryはMCPツールの発見を 観測可能かつ監査可能：

• 発見リクエストはログに記録され、追跡可能です
• ツールの可視性に関する決定はレビュー可能です
• 発見活動は、セキュリティおよびコンプライアンスレビュー中に監査できます

これにより、MCPツールの発見は不透明な内部プロセスから ガバナンス可能なシステム機能。

一般的なMCPツール発見の失敗モードと、TrueFoundryがそれらを回避する方法

ほとんどのMCPツール発見の失敗は、壊れたツールが原因ではありません。それらは 脆弱な発見モデル 、特にエージェントが継続的に複数の環境で動作するようになると、規模の拡大、自律性の確保、または変更への対応時に破綻するものです。

では、 TrueFoundryにおいて、MCPツールの発見は MCP Gatewayを通じて実施されます。、検出と呼び出し全体に認証、認可、ポリシー制御を一貫して適用します。これにより、本番環境のエージェントシステムでよく見られる最も一般的な障害モードを防ぎます。

障害モード1：ハードコードされた、または古いツールリスト

何が起こるか
エージェントは静的なツールリスト、またはプロンプトに埋め込まれた設定で初期化されます。MCPサーバーが進化するにつれて、ツールが追加、非推奨化、または再構成され、エージェントは古い前提に基づいて動作し始め、障害や危険な動作につながります。

TrueFoundryがこれを回避する方法
ツールは検出されます MCPゲートウェイを介して実行時に動的に。ゲートウェイは登録されたMCPサーバー（共通ツールMCPサーバーを含む）にクエリを実行し、 現在の、信頼できるツールセット をエージェントのコンテキストで利用可能なものとして返します。エージェントがハードコードされた、または古いツールカタログに依存することはありません。

障害モード2：過剰な権限を持つエージェント

何が起こるか
検出の失敗を避けるため、チームはすべてのツールをすべてのエージェントに公開します。これにより、影響範囲が広がり、意図しない、または危険なツール使用の可能性が高まります。

TrueFoundryがこれを回避する方法
検出は IDとポリシーに基づいてスコープが設定されます。MCPゲートウェイは、検出結果を返す前に、エージェントのID、ワークスペース、環境、およびガバナンスルールを評価します。エージェントは、明示的に検出を許可されたツールのみを参照し、それ以上は参照しません。

検出自体は 特権操作であり、公開メタデータエンドポイントではありません。

Failure Mode 3: Environment Drift

What happens
Agents discover tools that exist in development or staging but are unavailable or restricted in production. This causes failures during promotion or unpredictable runtime behavior.

How TrueFoundry avoids this
Discovery is environment-aware by default. The MCP Gateway only surfaces tools registered and enabled for the current execution environment. This ensures that what agents discover in the AI Gateway Playground is exactly what they will see at runtime.

There is no divergence between experimentation and production execution.

Failure Mode 4: Discovery Becomes an Invocation Backdoor

What happens
Some MCP implementations inadvertently allow discovery APIs to imply invocation rights or expose invocation details that agents can exploit.

How TrueFoundry avoids this
Discovery and invocation are strictly decoupled:

• Discovery exposes capabilities and metadata
• Invocation always passes through the MCP Gateway for authentication, authorization, and policy enforcement

An agent discovering a tool does not imply it can invoke it. Invocation is evaluated independently on every call.

Failure Mode 5: No Audit Trail

What happens
Teams cannot explain why an agent used or attempted to use a particular tool, making incident response and compliance reviews difficult.

How TrueFoundry avoids this
The MCP Gateway makes both discovery and invocation observable and auditable:

• Discovery requests are logged and traceable
• Tool visibility decisions can be reviewed
• Invocation attempts are attributable to agent identity and context

This enables post-incident analysis and supports regulatory and security audits.

Why This Matters

As agents become more autonomous, discovery failures compound quickly. A single misconfiguration can affect thousands of executions across environments.

By enforcing MCP tool discovery at the gateway layer, TrueFoundry ensures that discovery is:

• Dynamic (always current)
• Policy-aware (identity and environment scoped)
• Secure (no implicit access)
• Auditable (traceable by default)

This turns MCP tool discovery from a fragile configuration step into a reliable, governable system primitive, one that can safely support enterprise-scale agentic AI.

Conclusion

In agentic AI systems, tools are no longer optional integrations—they are core execution primitives. As agents become more autonomous, the ability to safely and accurately discover tools at runtime becomes critical to correctness, security, and scalability.

Static tool lists, manual configuration, and environment-specific hacks do not hold up once multiple teams publish tools, environments diverge, and agents operate continuously. At that point, MCP tool discovery stops being a developer convenience and becomes a systems problem.

The key insight is simple: discovery must live where context, identity, and policy are available in real time. Without this, agents either operate with incomplete knowledge or are over-permissioned, both of which introduce risk.

In TrueFoundry, MCP tool discovery is implemented at the AI Gateway, alongside inference routing and agent execution. This allows discovery to be dynamic, identity-scoped, policy-aware, and auditable by default without coupling agents to static configuration or brittle registries.

For enterprises building agentic AI systems, MCP tool discovery is not about listing tools. It is about controlling how agents learn what they can do. Treating discovery as a first-class, runtime capability is what makes agent autonomy safe, governable, and scalable.