Static definition
Package a known tool set with the agent. This is the simplest path for a small, stable catalog, but every definition change requires a controlled update.
Runtime selection
Dynamic tool discovery without loading every schema
Dynamic discovery resolves tool definitions at runtime instead of fixing the entire tool set at agent publish time. The design goal is not maximum choice. It is the smallest current, eligible set that can satisfy this intent.
Three patterns
Choose static, dynamic, or search-based discovery deliberately
The patterns can coexist. A production agent may keep a small static core, refresh tools from approved servers, and search a larger eligible catalog only after a capability gap.
Runtime server discovery
Initialize an approved MCP server and retrieve its current tool list. This reflects server changes, so new definitions must pass runtime validation before exposure.
Search function
Search an indexed, policy-filtered catalog for the current intent, then register only a few relevant definitions with the agent for this decision.
Context discipline
Do not make the model rank every known tool
A full catalog consumes context before the user task is solved and gives irrelevant or ineligible definitions a chance to influence selection. Retrieval should happen outside the model's final choice set.
Filter policy
Remove disallowed protocols, write actions, stale definitions, unavailable providers, and tenant-ineligible connections.
Retrieve candidates
Match a sanitized capability intent against the remaining definitions using deterministic and semantic signals.
Rerank evidence
Apply behavior review, citations, latency, current health, and comparable outcome history before producing the shortlist.
Expose minimally
Give the agent only the few eligible definitions needed for the decision, then keep provider execution direct.
Definition drift
A changed tool is a new trust decision
Dynamic discovery shortens the time between provider publication and client visibility. That makes diffing, validation, and fail-closed activation part of the runtime architecture.
Detect
Retain a digest of the exact definition and observe list-change signals or periodic refreshes. A renamed field or altered description is evidence of change.
Revalidate
Reapply schema limits, risk classification, instruction-content checks, provider attestation, and independent behavior review.
Activate or hold
Publish the changed definition only after every required gate passes. Otherwise retain the last eligible version or remove the connection from results.
Runtime boundary
Dynamic does not mean autonomous trust
Fresh definitions are useful only when the runtime can refuse them. Availability and semantic relevance do not replace authorization or evidence.
No automatic activation
A new tools/list entry cannot become selectable solely because an already connected server published it.
No permission broadening
User-specific or role-specific tool lists remain bounded by the current identity and task. Discovery cannot grant a new role.
No context dumping
Do not inject every discovered schema into the prompt. Filter and rank before model exposure.
Primary sources
References
The comparison uses current primary documentation from MCP, AWS, and Microsoft. Platform behavior can differ; use the contract for the runtime you deploy.
AWS MCP tool discovery guidance
Primary platform guidance comparing static definition, dynamic discovery, and search-based tool registration.
Read the primary sourceMicrosoft dynamic tool discovery
Primary platform documentation for runtime definition refresh, validation, governance, and auditing of changed tools.
Read the primary sourceMCP architecture overview
Primary protocol reference for tools/list and list-changed notifications that make dynamic discovery possible.
Read the primary source