The browser edition of toolnexus

toolnexus is an agent SDK for your server. toolnexus-web is the same idea built for the browser tab — and it brings the model with it.

It is its own library, not a wrapper: nothing here imports toolnexus. It follows the same tool schema and borrows toolnexus’s design wherever that design can run inside a page.

	toolnexus	toolnexus-web
Runs	on your server, in 7 languages	in the browser tab
Model	any provider endpoint	local (WebGPU / WASM) — the weights are in the tab
Tools	MCP, skills, native, HTTP, A2A	native tools today; more of the toolnexus surface as it fits the browser
Data leaves the machine	to your model provider	never

What can and cannot come to the browser

A browser page has no processes and no filesystem, so the line is drawn by the platform, not by preference:

• Can come over: the tool-calling loop, hooks, streaming, retries, conversation memory, native tools, MCP over HTTP, remote A2A agents, in-process sub-agents, and skills loaded from a URL or passed in memory.
• Cannot: stdio MCP servers (they spawn processes) and reading mcp.json or a skills/ folder from disk.
• Only here: in-tab inference on GPU or CPU, embeddings, RAG, and offline knowledge bundles.

The same tool, both sides

The authoring APIs differ, but both compile to the identical OpenAI function envelope — so a tool you designed for one is the same tool in the other.

// toolnexus — server side
defineTool({
  name: 'get_weather',
  description: 'Get current weather for a city',
  inputSchema: { type: 'object', properties: { city: { type: 'string' } }, required: ['city'] },
  run: ({ city }) => fetchWeather(city),
})

// toolnexus-web — in the tab
chat.tool('get_weather', 'Get current weather for a city',
  { city: 'string' },
  ({ city }) => fetchWeather(city));

Reach for toolnexus-web when the data must not leave the machine; reach for toolnexus when a model endpoint is fine and the hard part is the tools.

toolnexus docs →