MCP, for assistants
An assistant that can open your point cloud is more useful than one you have to describe it to. The engine speaks the Model Context Protocol, over the same operations the REST API serves.
The REST API and the MCP server are two front doors onto one typed contract, so an HTTP client and an AI assistant reach the same operations with the same names, schemas and errors.
That is the property worth understanding before anything else on this page: there is no second implementation and no subset. A tool an assistant calls and a route a script posts to are the same operation, with the same request shape, the same errors and the same behaviour.
Point a desktop assistant at it
A host such as Claude Desktop spawns the engine and talks to it over standard input and output. Add the server to the host's own configuration file:
From the engine repository's README, at the pinned commit
{
"mcpServers": {
"lazweaver": {
"command": "/usr/local/bin/lazweaver",
"args": [
"mcp", "--stdio",
"--queue-url", "/var/lib/lazweaver/queue",
"--input", "/var/lib/lazweaver/in",
"--output", "/var/lib/lazweaver/out"
],
"env": {
"LAZWEAVER_LOCAL_ONLY": "1",
"LAZWEAVER_TENANT": "local"
}
}
}
}The queue, input and output locations are directories on the machine the assistant runs on, so a laptop can run the whole loop without an object store. The tenant is the process's own, named by an environment variable.
Over HTTP instead
The same server can be bound to an address and spoken to over streamable HTTP, on its own or beside the REST API in one process. The bearer token names the tenant, exactly as it does for REST, so a hosted assistant reaches the same data its key would reach through the API and no more.
What an assistant can do
| Tool | What it does |
|---|---|
upload_url | where to put a file, and the identifier every later call names it by |
inspect | the header: bounds, point count, returns, classes and the coordinate reference system |
validate | integrity and sanity checks over the file |
stats | class histogram, intensity, elevation percentiles and density |
dry_run | what a preset would do and what it would write, without running it |
stages | every stage the engine can run, and what each one takes |
presets | the named sets of options a job can be submitted with |
submit | start a job from a preset, a stage list or a tier |
status | where the job is: state, phase and percent |
wait | poll until the job finishes, emitting progress from the ledger as it moves |
events | the findings and lifecycle events, with stable codes |
logs | the run's own log lines |
report | what the run found, as a structured record |
artifacts | everything the job wrote, each with a URL to fetch it |
cancel | stop at the next step boundary |
jobs | this tenant's jobs, newest first |
Waiting is a tool rather than a loop the assistant writes: it polls the run ledger and emits progress as the phase and the percent move, so a host shows something moving instead of nothing for the length of a job.
What it can read
Beside the tools, a job's status, its events, its logs and its report are addressable as resources under a lazweaver:// scheme, and so is the catalogue of stages. A host that supports resources can attach one to a conversation rather than calling a tool to fetch it.
The prompt that comes with it
The server ships a prompt that walks an assistant through the whole loop: inspect the file, ask the user for a coordinate reference system when the file does not carry one, validate, dry run, choose a preset, submit, wait, and summarise the report and the findings at the end. It is there because the useful conversation about a point cloud has a shape, and an assistant that invents its own each time asks for the wrong things.
Source
Everything on this page is from the engine repository's own documentation at the version this platform is pinned to. The API reference on this page is generated from the engine's OpenAPI document at the version this platform is pinned to, at build time.