MCP Tool Discovery for Enterprise AI Agents

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

MCP servers in TrueFoundry expose tools using the MCP protocol, but their availability is controlled at the gateway layer. This includes:

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

Tools are not globally visible by default. They are surfaced to agents only through the gateway, based on platform configuration and access controls.

This prevents agents from discovering tools that exist but are not intended for their environment or workload.

Discovery in the AI Gateway Playground

The AI Gateway Playground provides a concrete view into how MCP tool discovery works at runtime.

When an agent session is created:

• The gateway queries registered MCP servers
• Applies workspace, environment, and policy filters
• Returns only the tools visible to that agent context

As a result, the tools shown in the Playground are not a static catalog. They represent the exact discovery view the agent will see during execution.

This makes discovery behavior testable and predictable before deploying agents into production.

Runtime Discovery and Invocation Flow

At runtime, MCP tool discovery follows a consistent path:

1. An agent requests tool discovery
2. The MCP Gateway evaluates:
   • Agent identity
   • Workspace and environment
   • Registered MCP servers
   • Discovery policies
3. The agent receives a filtered set of tools
4. Tool invocation is executed through the same gateway path, with separate authorization and enforcement

Discovery and invocation are deliberately decoupled. Discovery exposes capabilities, not execution rights.

Why the MCP Gateway Matters

By placing MCP tool discovery behind the gateway, TrueFoundry ensures that:

• Agents never discover tools outside their allowed scope
• Discovery reflects real runtime conditions
• Tool visibility remains consistent across Playground and production
• Governance and auditing apply equally to discovery and invocation

This is what allows MCP tool discovery to scale safely as agent autonomy increases.

Security, Governance, and Access Control in MCP Tool Discovery

In enterprise agentic systems, tool discovery itself is a security boundary. If an agent can discover a tool, it implicitly learns that the capability exists even if invocation is later blocked. Uncontrolled discovery therefore becomes a form of information leakage.

In TrueFoundry, MCP tool discovery is treated as a privileged, policy-enforced operation, not a passive metadata lookup.

Identity-Scoped Discovery

Every discovery request is evaluated in context, including:

• Agent identity or service account
• Workspace and project boundaries
• Execution environment (dev, staging, prod)
• Organization-level governance policies

Agents only discover tools that are explicitly visible to them. Tools outside an agent’s scope effectively do not exist, preventing over-broad discovery and cross-team capability leakage.

Discovery and Invocation Share the Same Trust Model

A common failure mode in MCP implementations is securing invocation while leaving discovery open. TrueFoundry avoids this by enforcing the same authentication, authorization, and policy model across both discovery and invocation.

Discovery exposes capabilities, not execution rights. Invocation is always evaluated independently and never implied by discovery alone.

Auditable by Default

For regulated environments, discovery behavior must be explainable. TrueFoundry makes MCP tool discovery observable and auditable:

• Discovery requests are logged and traceable
• Tool visibility decisions can be reviewed
• Discovery activity can be audited during security and compliance reviews

This turns MCP tool discovery from an opaque internal process into a governable system capability.

Common MCP Tool Discovery Failure Modes and How TrueFoundry Avoids Them

Most MCP tool discovery failures are not caused by broken tools. They stem from fragile discovery models that fail under scale, autonomy, or change, especially once agents operate continuously and across environments.

In TrueFoundry, MCP tool discovery is enforced through the MCP Gateway, which applies authentication, authorization, and policy controls consistently across discovery and invocation. This prevents the most common failure modes seen in production agentic systems.

Failure Mode 1: Hardcoded or Stale Tool Lists

What happens
Agents are initialized with static tool lists or prompt-embedded configurations. As MCP servers evolve, tools are added, deprecated, or reconfigured, and agents begin operating on outdated assumptions leading to failures or unsafe behavior.

How TrueFoundry avoids this
Tools are discovered dynamically at runtime through the MCP Gateway. The gateway queries registered MCP servers (including common tools MCP servers) and returns the current, authoritative set of tools available for the agent’s context. Agents never rely on hardcoded or stale tool catalogs.

Failure Mode 2: Over-Permissioned Agents

What happens
To avoid discovery failures, teams expose all tools to all agents. This increases blast radius and makes unintended or unsafe tool usage more likely.

How TrueFoundry avoids this
Discovery is identity- and policy-scoped. The MCP Gateway evaluates agent identity, workspace, environment, and governance rules before returning discovery results. Agents only see tools they are explicitly allowed to discover, nothing more.

Discovery itself is treated as a privileged operation, not a public metadata endpoint.

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.