Skip to main content

Models, MCP servers, and policy

Public documentation preview — incomplete. The package and optional AI SDK peers remain private and unpublished. This configuration is illustrative; no live model/server compatibility or authorization is provided by the docs.
Use a predictable separation: connect model adapters, supply a trusted MCP server array, and declare routing preferences and authorization under policy. This is a configuration pattern, not a working provider/server fixture: it needs an authorized OpenAI-compatible endpoint, private compatible AI SDK peers, credentials, and two already running Streamable HTTP MCP servers exposing the stated tools. It is not necessary for the model-free local quickstart. The source-controlled examples/code.ts module illustrates this pattern for maintainers with repository access; it is not a public release or tested live walkthrough. Adapt the exact tool names and schemas to your servers.
This configuration fragment fails on missing environment variables; the host must still approve its endpoints and model IDs before construction. Keep credentials server-side; use trusted, authenticated context for each request, constrain your actual tenant/resource permissions and increment the policy revision when grants change. Do not use MCP-provided metadata or model output to create server configurations or grant access. Close the router in an operation-level finally. No constructor connects or sends a model request. createBoundedModel forwards a host-supplied fetch, but the host must restrict destinations, exposure, spending and logging. The direct AI SDK generateText model is separate and not bounded by router modelAccess. See model bindings, filtering, scoped execution, and AI SDK hosting.