III · Tool Use & EnvironmentEmerging★

Tool Discovery

also known as Capability Advertisement, Dynamic Tool Loading

Let the agent discover available tools at runtime rather than hardcoding the tool list at agent build time.

This pattern helps complete certain larger patterns —

  • specialisesTool Use★★— Let the LLM produce typed calls against an external toolkit instead of producing free-form text the surrounding system has to parse.

Context

A team runs an agent whose tool palette changes faster than its release cycle: new internal capabilities ship weekly, partner integrations come and go, and there is a directory (an MCP server, an internal registry) that already advertises tools with typed schemas. The team wants the agent to learn about new capabilities without rebuilding and redeploying the agent itself.

Problem

Hardcoding the tool list at build time means every new capability needs a code change and a redeploy of the agent, even when the underlying tool is fully ready to go. Multiple agents in the same organisation drift out of sync because each one was last redeployed at a different moment. Without a runtime mechanism for discovery, the agent simply cannot reach tools that landed after its last release.

Forces

  • Discovery latency adds to every cold start.
  • Tool quality varies; not every advertised tool should be exposed.
  • Versioning of advertised tools.

Example

An agent's tool palette is hardcoded at build time and every new internal capability needs a redeploy of the agent. The team moves to runtime tool discovery: on startup the agent queries an internal MCP-style registry, loads advertised tools with typed schemas, and refreshes periodically. New capabilities ship by registering a tool, no agent redeploy, and the schema-typed advertisement protects against drift between agent and tool.

Diagram

Solution

Therefore:

On startup (or periodically), the agent queries a tool registry (MCP server, internal directory). The registry returns advertised tools with typed schemas. The agent loads them into its palette. Optionally cached and refreshed.

What this pattern forbids. The agent's tool palette at any moment is exactly the discovered set; off-registry tools are forbidden.

The smaller patterns that complete this one —

  • generalisesApp Exploration Phase·— Before deploying an agent against an opaque app, have it explore (or watch a human demonstrate) the app, generating a per-element documentation knowledge base; at deployment, retrieve element docs to ground actions.
  • usesModel Context Protocol★★— Standardise how agents discover and call tools so that a tool written once is usable by any conformant agent.
  • generalisesTool/Agent Registry★— Maintain a single queryable catalogue of both available tools and available agents, with metadata (capability, cost, latency, quality) the agent can use to pick the right one for a task.

And the patterns that stand alongside it, or against it —

  • complementsAwareness★— Maintain the agent's explicit knowledge of its own tools, capabilities, environment, and current context as queryable state.
  • complementsTool Loadout★★— Select a small task-relevant subset of available tools per request rather than exposing the full registry to the model.
  • complementsTool Search Lazy Loading★— Defer loading tool schemas into the context window until a search step shows they are needed.
  • alternative-toToolformer✕— Train the model to learn when and how to call tools through self-supervised data, without human annotation.
  • complementsWebAssembly Skill Runtime·— Package each agent skill as a WebAssembly module with a capability manifest, and run it inside a Wasm runtime that enforces those capabilities, so untrusted skills cannot weaken the host's sandbox.
  • alternative-toSynthetic Filesystem Overlay·— Project heterogeneous enterprise data sources into a single Unix-like tree exposed through filesystem primitives so the agent reuses path semantics it already knows instead of learning a bespoke API per source.
  • complementsDecentralized Agent Network·— Agents publish signed DID+JSON-LD identity records so any peer can discover and verify them without a central registry — the agent equivalent of the open web.
  • complementsAgent Adapter★★— An interface layer connecting an agent's tool-calling protocol to heterogeneous external tools, normalizing their schemas into one the agent expects.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

Used in frameworks

References

Provenance