Tool Server
Connect Kaya to model providers and external tools
Configure tools in the host that runs your Kaya program. Each session needs explicit grants for the providers and operations it can use.
| Host | Configure tools with |
|---|---|
| Command Line | A kaya-tool-server manifest and daemon attachment |
| WebAssembly | Explicit private browser configuration and admitted catalog |
Command Line
The native standalone installation includes kaya-tool-server alongside
kaya and kayad. The server connects the daemon to model providers, files,
and other external tools.
Local setup
Configure a server manifest with the providers and model aliases you want to use. Keep provider credentials in the tool-server environment, referenced by the manifest.
Set KAYA_TOOL_SERVER_MANIFEST to the manifest's absolute path. When no explicit
KAYA_TOOL_CLIENT_MANIFEST is set, kayad can start and supervise its local
tool server using the manifest's admitted text-model routes.
Follow the local setup instructions for a complete inline manifest, environment settings, and a first run.
Independently managed server
Use an explicit client manifest when you manage the tool server separately, need multiple admissions, or want a narrower set of model aliases. The server manifest configures providers; the client manifest selects the attachment endpoint, authentication, and default session grants.
See explicit client configuration for the server and daemon startup commands.
Models, grants, and settings
A provider credential does not grant a session access to a model. The server must bind the model alias, and the session must have the corresponding tool grant. Existing sessions retain their captured grants when configuration changes.
- Models & Providers: connector families, model bindings, and credentials.
- Runtime Settings: defaults, grants, sandbox settings, and environment variables.
- Command Line: running programs and managing the daemon.
WebAssembly
The public browser runtime accepts original native-format toolServer document
text through its explicit private configuration. It supports one unscoped native
admission, explicit supported model endpoints and admitted generation/decision
bindings. It does not attach an arbitrary native tool server, launch native
processes or supply unavailable media/MCP services. Unsupported configuration
returns a typed refusal.
runtime.catalog() returns the actual filtered protocol-one provider descriptors
and digest without inference or new session authority. Its availability is
separate from per-session ToolMap grants; client-authored ToolMaps remain disabled
by default. The website's native configuration form uses this same parser and
catalog, not a hardcoded substitute.
Supply your own browser-provider credentials privately at runtime. Never bundle an application's shared backend secret into frontend source. Browser endpoints must allow the page origin through CORS. Saved-state replies contain presence only; authored documents, headers, environment values and named secrets stay in the original Worker/private store.
See WebAssembly Setup and WebAssembly Usage for the current status.