jschoubben
80b02740ab
The runtime serves a tools verb per module with names, descriptions and schemas (design 34 §3), and refuses a module naming its own tool tools. Discovery asks catalog_modules then each module, naming what did not answer. One MCP handler over two transports: stdio (mesh mcp) and loopback HTTP (mesh serve, the mesh-console module, novox/hq ADR 0152); serve refuses any bind but loopback. tools/call may go through a running console with --console and no credential.
47 lines
2.4 KiB
Markdown
47 lines
2.4 KiB
Markdown
# mesh-tools
|
|
|
|
The Novox Mesh **tool runtime** — the per-node process that makes a module's tools actually serve.
|
|
|
|
A module ships its tools (built on [`@novox/mesh-sdk`](https://git.novox.be/novox/mesh-sdk)); this
|
|
runtime is what loads them and puts them on the mesh. It:
|
|
|
|
1. connects the mesh broker (novox/hq ADR 0001) — a concrete AMQP implementation of the sdk's
|
|
`Broker` contract;
|
|
2. imports the assigned modules' compiled tool entrypoints, each of which registers its tools as it
|
|
loads;
|
|
3. serves them through the sdk's `serveTools` harness, answering `tools.invoke` over the broker.
|
|
|
|
Everything hard — dispatch, collection, duplicate-name safety — is the sdk's. This is the thin
|
|
wrapper that binds the broker and loads the modules. Keeping the AMQP client here, out of the sdk,
|
|
is deliberate: a broker-client change never rebuilds a module (ADR 0039).
|
|
|
|
## Running it
|
|
|
|
```
|
|
MESH_BROKER_URL amqp://… the mesh broker
|
|
MESH_TOOL_MODULES /a/tools/index.js,… the assigned modules' compiled tool entrypoints
|
|
```
|
|
|
|
`node dist/main.js`, or the container (`Dockerfile`). On a node the host resolves both variables
|
|
and starts it like any other supervised workload.
|
|
|
|
## `mesh` — the tools for whoever is on a machine
|
|
|
|
The same package carries the client (novox/hq design 25 §7, design 34): `mesh tools`, `mesh call
|
|
<module>.<tool> [json]`, `mesh mcp` (an MCP server over stdio for a program a person starts) and
|
|
`mesh serve` (the **console**: MCP over HTTP on a machine's loopback, started by the mesh as the
|
|
`mesh-console` module on the credential in `MESH_BROKER_FILE` — novox/hq ADR 0152). `mesh serve`
|
|
refuses to bind anything but loopback. With `--console <url>`, `tools` and `call` go through a console
|
|
already on the machine and need no credential.
|
|
|
|
Discovery asks the modules: every runtime answers a `tools` verb for each module it serves, with names,
|
|
descriptions and schemas from the code that answers them, and the console asks the catalogue which
|
|
modules the mesh holds and each module what it serves. A module that does not answer is named, never
|
|
dropped. A module may not name a tool of its own `tools`; the runtime refuses it at load.
|
|
|
|
## Verified
|
|
|
|
`npm test` stands up LavinMQ (the mesh's broker) and proves the whole path over real AMQP: the
|
|
runtime serves a registered tool, a separate connection invokes it by name and gets the result, and
|
|
an unknown tool is refused over the wire.
|