Celilo started as a command-line tool, and for a while the CLI was the product. But more and more things need to talk to Celilo — the CLI itself, the end-to-end test harness, and integrations like an MCP tool that lets an assistant drive it. Each of those shouldn’t have to scrape command output or invent its own protocol. Celilo as a Server gives them one typed API to speak to instead.
Why a shared API
When every caller goes through the same versioned interface, they all get the same guarantees: a well-defined request, a structured response, and clear authentication. The CLI becomes one client among several rather than a special case, and adding a new front end — a web UI, an automation, a remote responder — means speaking an existing protocol rather than building a private back door.
What it changes
The goal is to wrap Celilo’s core operations behind a stable, versioned protocol with per-key, deny-by-default access — so a caller can do exactly what it’s been granted and nothing more. Remote access is secured at the boundary, the same way for everyone. This is early, foundational work; the first slice is the protocol and the core operations, with more surface following behind it.