MCP server
The read-only MCP projection: what it serves, how a client connects, what it will not do, and the budget it answers within.
For whoever is connecting an assistant or an agent to the record — an integrator, or an operator who wants fleet state answerable without relaying it by hand.
After reading it you can stand the surface up, connect a client, prove who that client is, and know what a call costs.
Before you start: an installed machine and a reachable record. The pages below are in the order a first connection needs them.
The product serves its own record over MCP, so an assistant or an agent can read fleet state without a human relaying it — and only read: this surface answers questions and takes no act. Everything a client needs is below, in the order a first connection needs it.
| you want | read |
|---|---|
| what the surface is for and what it refuses on principle | Design principles |
| how a client connects, over which transports | Transports |
| who the client is, and how it proves it | Authentication · Authorization |
| the exact tools, their arguments and their refusals | Protocol surface |
| what a call costs and what gets truncated | Response budget |
| calls end to end, with real answers | Worked examples |
| what the record behind it holds | The record |
| standing it up and keeping it up | Runbook |
| the words this surface uses | Glossary |
⚠ It is read-only by construction, not by configuration. A client cannot gate, merge or dispatch through this surface — those are acts, and acts have their own doors with their own human decisions.
What this section does not cover
⚠ It takes no act, so nothing here gates, merges or dispatches. Those doors are Working with git and the console. ⚠ Nothing here describes the client you connect — the surface is the product's half of the contract.