Skip to main content

​
Assign models to servers and tools

Public documentation preview — incomplete. The SDK and optional AI SDK peers remain private and unpublished. Binding guidance does not grant permission to invoke a model or tool.
Model aliases identify host-configured adapters (models[alias] = { routing?, ranking? }); they do not discover providers or create credentials. Configure the models, server array and policy first. For execute, routing preference precedence is:
  1. Explicit per-call model override.
  2. Exact remote { serverId, toolName } or registered { localKey } rule in policy.modelBindings.tools.
  3. policy.modelBindings.servers[serverId].
  4. Router-level model default.
The example binds database-server to database, billing-server to general, and its get_customer_balance tool specifically to billing. A billing request scoped to that exact tool therefore uses models.billing.routing. For a local tool, configure { localKey: 'balance', model: 'billing' } under policy.modelBindings.tools when constructing the router; it can target a localKey that is registered later. There is no post-registration binding mutation API on an existing router. Bindings are not authorization and do not decide the ranker for filterTools or switch a host’s generateText model. policy.modelAccess is a separate, intersecting restriction on model-backed operations. Global, selected-server and eligible-tool allowlists must all permit the chosen adapter; a filtered-out or empty selected server can still constrain exposure. Restrictions are checked before ranking/top-K and inference, so limit: 1 does not bypass them. Lexical model-free filtering does not send tool data to a model. A missing, unsupported or changed target never silently falls back to a different binding. Always obtain a current bound descriptor and recheck host authorization before a real call. See filtering and bounded execution.