Dynamic Tool Discovery in Multi-Agent Systems: Scaling Model Context Protocol (MCP) Without Context Bloat

The enterprise transition from isolated, single-prompt generative AI chatbots to fully autonomous, multi-agent workflows represents a fundamental architectural paradigm shift. In a single-agent system, the AI relies on a static, pre-defined set of instructions and a narrow array of integrations. However, as organizations deploy multi-agent systems—where orchestrator agents dynamically delegate tasks to specialized worker agents, query real-time data lakes, and execute infrastructure automation—the static integration model structurally collapses. You cannot hardcode a dynamic enterprise topology into a static system prompt.

As the number of internal APIs, data sources, and microservices scales into the thousands, attempting to feed every possible function definition into a Large Language Model (LLM) creates catastrophic context window saturation. The resulting token bloat degrades reasoning accuracy, spikes inference costs, and introduces severe latency bottlenecks that render real-time autonomous operations impossible.

To survive this scaling cliff, AI Architects must decouple tool definitions from the LLM prompt. The solution is dynamic tool discovery MCP—a scalable architecture leveraging the Model Context Protocol to decouple agentic capabilities from foundational models. By implementing a centralized registry and hybrid semantic routing, orchestrator agents can autonomously discover, evaluate, and inject only the strictly necessary tool schemas required for a specific task at runtime.

This technical briefing dissects the architectural blueprint for scaling multi-agent systems. We will explore the mathematical realities of the context window bottleneck, the deployment of an internal MCP registry, the mechanics of hierarchical semantic routing, and the implementation of dynamic model profiling to ensure high-availability routing across enterprise LLM endpoints.

The Context Window Bottleneck: Why Hardcoded Agent Tool Definitions Fail at Scale

The standard methodology for enabling LLM function calling (or “tool use”) relies on injecting extensive JSON schema definitions directly into the model’s system prompt prior to inference. The model reads the descriptions of available tools, their expected input parameters, their required data types, and their functional boundaries, and then determines whether to output a standard text response or a structured JSON payload to trigger an external function.

In a constrained prototype with three to five tools—such as a simple weather API, a calculator, and a database query function—this approach works flawlessly. But in an enterprise environment, a capable orchestrator agent may need access to 500 distinct microservices, 200 data lake schemas, and 50 specialized worker agents to effectively navigate the corporate digital estate.

Hardcoding hundreds of tool definitions into the context window introduces three cascading architectural failures:

• Token Consumption and Latency Spirals: An average enterprise API OpenAPI specification, when converted to a JSON Schema for LLM tool calling, consumes between 150 and 400 tokens per endpoint. A registry of 500 tools requires injecting 100,000 to 200,000 tokens into the prefill context for every single user query. At scale, this prefill compute burden drastically spikes Time-to-First-Token (TTFT) latency, turning a sub-second response expectation into a multi-second bottleneck, while simultaneously burning thousands of dollars in redundant input token costs.
• Attention Mechanism Degradation (The Lost-in-the-Middle Problem): Transformer-based architectures suffer from well-documented attention degradation when processing massive context windows. Even if a model boasts a 1-million-token context limit (like Claude 3.5 Sonnet or Gemini 1.5 Pro), forcing the attention mechanism to weigh the semantic relevance of hundreds of overlapping tool definitions drastically reduces the model’s zero-shot accuracy. The model becomes prone to hallucinating required parameters, selecting the wrong tool for a nuanced task, or combining parameters from two distinct APIs into a single malformed request.
• Topological Drift and Configuration Rot: When tool schemas are hardcoded into static application code or prompt templates, they immediately decouple from runtime reality. If a backend engineering team updates a critical customer database API—changing a required `customerId` integer to a `uuid` string—the hardcoded LLM prompt remains completely unaware of the breaking change. The agent confidently generates the legacy tool call, triggering a downstream validation error and collapsing the autonomous workflow.

To overcome these systemic bottlenecks, enterprise architecture must transition away from pre-loaded context and embrace just-in-time, autonomous capability mapping.

Architecting an Internal MCP Registry for Real-Time Capability Indexing

To build a resilient multi-agent topology, technical leaders are standardizing on the Model Context Protocol architecture (MCP). Open-sourced as a standard boundary interface, MCP acts as a universal translator between foundation models and external data sources, enterprise tools, and specialized infrastructure. Instead of writing custom integration glue-code for every new API, MCP standardizes how AI models discover, authenticate against, and interact with external systems.

However, simply standardizing the protocol is not enough; the enterprise requires a centralized, self-updating LLM tool registry to act as the single source of truth for all available agentic capabilities. This registry operates as a dynamic control plane within your broader enterprise autonomous discovery framework.

The Mechanics of the Centralized Tool Registry

The internal registry is not a static database updated by manual pull requests. It is an active, event-driven catalog that continuously crawls the enterprise infrastructure to discover and index capabilities:

• Continuous OpenAPI and gRPC Ingestion: The registry’s ingestion workers continuously monitor internal developer portals, Git repositories, and API gateways. When a new microservice is deployed or an existing OpenAPI 3.1 specification is updated, the registry automatically parses the endpoints, extracts the JSON schemas, and registers them as available MCP tools.
• Standardized Capability Manifests: Every discovered tool is normalized into a standard capability manifest. This manifest includes not just the JSON schema required for LLM invocation, but also critical operational metadata: execution latency SLAs, required OAuth2 scopes, rate limits, and the internal team responsible for maintaining the endpoint.
• Stateful Connection Management: The MCP registry abstracts the complexity of authentication and connection lifecycle management away from the agent. When an agent requests to use a specific HR database tool, the registry verifies the agent’s workload identity (via SPIFFE/SPIRE), negotiates the secure connection to the underlying MCP server, and brokers the transaction without exposing raw API keys to the language model.

By decoupling the tool definitions from the LLM prompt and centralizing them in a live registry, platform engineers ensure that agents are always operating against the true, real-time state of the enterprise topology.

Hierarchical Semantic Routing: Hybrid Vector + Graph Retrieval for Top-K Tool Injection

With a comprehensive, self-updating MCP registry containing thousands of enterprise tools, the architecture must now solve the retrieval problem: How does an orchestrator agent identify and load the exact 3 to 5 tools it needs to solve a user’s prompt without loading the other 9,995?

The answer is hierarchical semantic discovery. Rather than feeding raw tool schemas to the orchestrator, the workflow intercepts the user’s initial prompt and executes a high-speed, multi-modal retrieval process to assemble a bespoke, context-optimized toolkit inject.

Step 1: Dense Vector Retrieval for Semantic Intent Mapping

When an internal capability is added to the MCP registry, the system automatically generates a dense vector embedding of the tool’s description, parameters, and historical usage logs. These embeddings are stored in a high-performance vector database (such as Qdrant, Milvus, or Pinecone).

When a user prompts the orchestrator agent with, “Calculate the Q3 cloud infrastructure spend for the European division and forecast Q4 based on current deployment trends,” the semantic router embeds this intent. It executes a similarity search across the tool registry’s vector space, immediately surfacing tools related to “AWS billing APIs,” “European region data warehouses,” and “financial forecasting models,” while completely ignoring tools related to HR onboarding or code compilation.

Step 2: Knowledge Graph Traversal for Dependency Resolution

Vector similarity alone is insufficient for complex enterprise operations because APIs rarely operate in isolation. If the vector search retrieves the `get_cloud_billing_data` tool, the agent might lack the prerequisites to execute it. Perhaps the billing API requires a specific `temporary_auth_token` that can only be generated by a separate identity microservice.

To resolve this, the hierarchical router queries a temporal property graph (such as Neo4j or Amazon Neptune) where all tools are mapped as nodes, and their operational prerequisites are mapped as directed edges (e.g., REQUIRES_AUTH_FROM, EXPECTS_DATA_SHAPE_FROM). The graph traversal ensures that if Tool C is retrieved, Tool A and Tool B—the mandatory prerequisites—are automatically bundled into the context payload.

Step 3: Just-in-Time Top-K Context Injection

The output of this hybrid vector-graph retrieval is a strictly filtered list of the Top-K (typically 3 to 5) most relevant and mathematically necessary tool schemas. The orchestrator injects only these highly specific JSON definitions into the LLM’s system prompt dynamically.

This process reduces the token overhead from 150,000 tokens down to 1,500 tokens. TTFT latency drops from seconds to milliseconds, compute costs are slashed by 90%, and the LLM’s attention mechanism remains hyper-focused on a narrow, pristine set of capabilities, drastically improving tool-calling accuracy and eliminating execution hallucinations.

Dynamic Model Profiling: Routing by Token Throughput, Quantization, and Latency SLAs

In a mature multi-agent architecture, the concept of “the tool” extends beyond standard microservices or database queries; other AI agents and specialized models are themselves discoverable tools. An orchestrator agent must be capable of dynamically delegating a sub-task to a heavily quantized local model for basic data extraction, or routing a complex reasoning task to a massive frontier model via an external API.

Achieving this requires deploying multi-agent routing tables powered by continuous dynamic model profiling. Static routing logic (e.g., if task == "summarize" then use "llama-3-8b") breaks down when internal GPU clusters become saturated or when external API providers experience rate-limit degradation.

The Telemetry-Driven Routing Engine

The enterprise MCP registry must continuously profile the health, availability, and performance characteristics of all internal and external LLM endpoints. This is achieved by combining kernel-level eBPF observability with application-layer telemetry to track real-time operational metrics:

• Context Window Utilization and Token Throughput: The profiler tracks the real-time tokens-per-second (TPS) velocity of internal vLLM or TensorRT-LLM clusters. If the cluster hosting a 70B parameter model is experiencing heavy KV-cache pressure and TPS drops below a critical SLA threshold, the router automatically down-grades the task to a faster, smaller parameter model to preserve workflow velocity.
• Quantization and Precision Awareness: Not all tasks require FP16 (16-bit floating point) precision. The MCP registry maps the exact quantization levels (e.g., INT4, AWQ, FP8) of active model endpoints. When an orchestrator delegates a massive log-parsing task where slight precision loss is acceptable, the routing table directs the payload to a heavily quantized, high-throughput INT4 endpoint, saving critical VRAM for complex reasoning workloads elsewhere.
• Cost-Per-Million-Token (CPMT) Optimization: In hybrid cloud environments utilizing multiple foundation model providers (AWS Bedrock, Azure OpenAI, Google Vertex AI), the routing engine continuously monitors dynamic API pricing and rate-limit quotas. The router executes a real-time arbitrage calculation, routing non-critical agentic queries to the endpoint offering the lowest CPMT that still meets the strict TTFT latency requirements of the workflow.

Autonomous Agent Negotiation

By exposing these real-time multi-agent routing tables through the MCP architecture, enterprise agents can engage in autonomous capability negotiation. If a specialized Financial_Analysis_Agent receives a task that exceeds its maximum context window limit, it can query the registry, discover a Data_Reduction_Agent equipped with a larger context window, and autonomously delegate the summarization phase before executing the final financial calculation.

This dynamic profiling transforms a static, brittle AI pipeline into a fluid, self-optimizing multi-agent ecosystem capable of surviving underlying hardware congestion, network partitioning, and API throttling without human intervention.

The Architectural Verdict for Multi-Agent Scaling

The era of manually injecting massive, static JSON schemas into LLM context windows is over. Attempting to brute-force multi-agent orchestration by relying purely on ever-expanding context limits ignores the fundamental economics of compute latency, token pricing, and transformer attention degradation.

To deploy autonomous agents securely and reliably at an enterprise scale, technical leaders must architect a decoupled control plane. By embracing dynamic tool discovery MCP, building a self-updating capability registry, and enforcing hierarchical semantic routing, the enterprise ensures that its AI agents remain hyper-focused, cost-efficient, and perpetually synchronized with the true operational state of the organization’s infrastructure.