Dynamic tool discovery

For a system where agents can dynamically discover and use new tools, I'd recommend Model Context Protocol (MCP) for tool discovery and interoperability, paired with LangGraph for orchestration if you need complex, stateful agent workflows.

The key architectural decision is to separate the protocol that discovers and exposes tools from the framework that decides when and how agents use them. MCP defines a standard way for clients to enumerate available tools and invoke them, while agent frameworks manage reasoning, execution, and workflow state.github.com+2

The best options

• 

1. Model Context Protocol (MCP) — best for dynamic tool discovery

(Recommended foundation)

MCP lets agents discover tools from external servers, read their descriptions and input schemas, and invoke them through a common protocol. Servers can update their available tool lists and notify clients of changes.github.com+2

Best when tools are added by plugins, internal services, third-party integrations, or independently deployed teams.

Docs:MCP specification

---

• 

2. LangGraph — best for complex production agents

Provides explicit workflow state, branching, persistence, and control over agent execution. Pair it with MCP-compatible clients and a tool registry to discover tools dynamically.www.langchain.com+1

Best when agents need retries, long-running workflows, approval gates, or predictable control over execution.

Docs:LangGraph

---

• 

3. OpenAI Agents SDK — best for a lightweight agent runtime

A good fit if you want tool use, agent handoffs, and guardrails without implementing a full workflow engine. It supports MCP integrations.www.langchain.com+1

Best when you prefer a relatively small abstraction layer and straightforward agent execution.

Docs:OpenAI Agents SDK

Recommended architecture

For genuinely dynamic discovery—where new tools can appear after your agent is deployed—I would build a registry + progressive discovery + execution gateway around MCP.

Agent / LLM

Determines the capability needed

Discovery layer

search_tools(query) → ranked tool candidates

Keyword + semantic search + permission filtering

Tool registry / MCP clients

Fetch current schema, validate access, resolve endpoint

MCP server A

Internal APIs

MCP server B

External plugins

Execution gateway enforces authorization, timeouts, auditing, and approval policies.

This follows MCP's recommended progressive-discovery pattern: expose a small search_tools capability, then load full tool definitions only when needed. This becomes particularly valuable when you have hundreds or thousands of tools.github.com+1

How I'd implement it

1. Register tools dynamically. Each tool has a unique ID, description, input schema, server endpoint, version, required permissions, and health status.
2. Search capabilities, not every tool definition. Start with keyword search and add vector embeddings for semantic matching. Use a small model to rerank candidates only when necessary.
3. Load the full schema on demand. The agent sees only a few relevant tools at a time, instead of the entire catalog.
4. Execute through a controlled gateway. Validate arguments, check user and agent permissions, enforce timeouts and quotas, and require approval for sensitive actions.
5. Refresh and invalidate caches. Respond to tool-list change notifications and handle tools that disappear or change schema between discovery and execution.
6. Measure discovery quality. Track tool-selection accuracy, execution success, latency, token usage, and unauthorized-call attempts.

These design choices align with the MCP client guidance on progressive discovery, caching, and tool invocation.github.com+1

Which stack should you choose?

Framework comparisons also distinguish LangGraph's explicit stateful orchestration from the lighter agent SDK approach.www.langchain.com+1

One important distinction: MCP standardizes tool discovery and invocation; it does not by itself provide a complete global registry, semantic search engine, trust system, or orchestration layer. Those are parts you design around it.

One question that would change my recommendation

When you say agents should dynamically discover new tools, which scenario is closest to your goal?

1. What does dynamic discovery mean in your system?

Agents discover tools at runtime from many existing services.

New tools or plugins can be registered without redeploying agents.

Agents discover capabilities offered by other agents.

Agents can find, generate, or install tools they have never used before.

---

2. What's your primary language?

Python

TypeScript / Node.js

Multiple languages

---

3. Roughly how many tools?

Dozens

Hundreds

Thousands or more

[Recommend my architecture]

The recommended approach is to use the Model Context Protocol (MCP) with dynamic tool discovery and progressive tool loading. This allows agents to discover available capabilities at runtime, select the right tools for a task, and use new tools without hard-coding every tool into the agent.

For an agentic system that needs to scale as tools are added, the key design principle is: discover broadly, load selectively, and invoke through a standardized protocol. The official MCP documentation and AWS guidance describe this pattern, including runtime discovery and semantic tool search.github.com+2

Recommended architecture

1. User request

Understand the task and identify the required capability

2. Discovery layer

Search a tool registry or call search_tools using semantic matching

3. Load and validate tools

Fetch schemas, check permissions, and expose only relevant tools to the model

4. Execute through MCP

Call the selected tool with validated arguments and return its result

5. Re-evaluate and continue

Use the result, discover additional tools if needed, and continue the task

1. Choose the discovery strategy based on scale

AWS explicitly distinguishes these approaches and recommends filtering or semantic search to expose a scoped set of relevant tools.docs.aws.amazon.com

2. Implement MCP's discovery and invocation lifecycle

Use the standard MCP client/server protocol rather than inventing a custom integration for each tool provider.

1. Discover: call tools/list to retrieve available tools and their input schemas.
2. Index: maintain a searchable catalog containing tool names, descriptions, schemas, server identity, and access metadata.
3. Search: expose a lightweight search_tools(query) capability to the agent.
4. Inspect: fetch the full schema and documentation for selected candidates.
5. Invoke: use MCP's tools/call with the selected tool name and validated arguments.
6. Refresh: respond to notifications/tools/list_changed so newly added or removed tools are reflected in the catalog.

MCP defines the listing, invocation, and change-notification mechanisms needed for this lifecycle.github.com+1

3. Recommended production design

For a general-purpose agent, I'd use three layers:

• Discovery layer: semantic or hybrid search over a catalog of tools and MCP servers.
• Execution layer: an MCP client that loads selected schemas and routes calls to the correct server.
• Governance layer: authentication, per-tool authorization, argument validation, audit logs, and approval for sensitive actions.

Keep credentials in the host or execution broker, not in model-generated code. Treat tool descriptions and returned content as untrusted input, and require appropriate authorization before executing consequential operations.github.com+3

4. Useful implementation references

• 

Model Context Protocol

The standard protocol for discovering and calling tools across servers.

MCP documentation ·Client best practices

---

• 

OpenAI Responses API

A practical option for using remote MCP servers with an API-based agent.

MCP server integration guide

---

• 

Amazon Web Services tool discovery guidance

Compares static registration, dynamic discovery, and semantic search.

Read the implementation guidance

Bottom line: For your system, start with MCP as the interoperability layer and progressive discovery as the scaling strategy. Let the agent search for capabilities at runtime and load only the schemas it needs. This supports adding new tools without hard-coding them into every agent while keeping context usage and execution access under control.