The One MCP Server We Did Build: Your Whole Machine

In April we argued that ninety per cent of MCP servers are ceremony, and that the protocol earns its keep only where trust crosses an organisational boundary. Then we found the boundary that qualifies: Anthropic's cloud on one side, your Mac on the other. So we built exactly one server. It exposes the machine.
The One MCP Server We Did Build: Your Whole Machine
In April we published a piece arguing that most MCP servers installed by individual developers are over-engineering. One binary with subcommands beats a daemon with a manifest for almost everything a single person does on their own machine. We stand by every word of it. The qualifier we buried in paragraph four turned out to be the interesting part: MCP is the correct architecture where trust crosses an organisational boundary. Auth, schema enforcement, audit trails, the whole ceremony. We said we were not claiming to replace those cases.
This is the story of the case we did not replace. We found a trust boundary sharp enough to deserve the protocol, and we built exactly one MCP server for it.
The boundary is this: claude.ai runs in Anthropic's cloud. Your machine runs on your desk. If you pay for a Claude subscription, you have access to a very capable model that can see precisely none of your fleet: not your work queue, not your repos, not your video editor, not your terminal. Every session starts as an amnesiac tourist. The standard workaround is copy-paste ferrying, where Claude writes five prompts and you carry them by hand to wherever the work actually happens. We got tired of being the courier.
Crossing that boundary properly is exactly the multi-tenant, cross-org case the MCP spec was designed for. Anthropic's servers make the calls. Your machine answers them. Between those two parties you want bearer auth, an allowlist of what can be invoked, a way to say no, and a log that cannot be quietly edited. That is not ceremony. That is the job.
One Server, Not Thirty
The obvious way to wire a machine into claude.ai is the way the ecosystem defaults to: install an MCP server per capability. One for the filesystem, one for git, one for the work tracker, one for the video tool, and now you are supervising a daemon farm, which is the exact failure mode the April piece was about.
We did the opposite. One server, thirty tools, and every tool is a thin shell over a CLI verb that already existed and already worked. The server itself is a single Rust file on a small hub library we had lying around. It holds almost no logic. When claude.ai asks for the work queue, the server runs the same query the terminal command runs. When it asks for a video render, the server shells the same verb we type by hand. The April thesis survives intact inside the machine: capabilities live in one binary with subcommands, testable from a shell, no protocol in sight. The protocol appears at the boundary, once, where it belongs.
That inversion matters more than it sounds. It means the MCP layer never becomes a platform you maintain. It is a doorway. When we add a capability, we add a CLI verb, use it from the terminal for a day until we trust it, then expose it through the door with twenty lines of schema. The night we wired up the video suite, the tools worked over MCP on the first try, because the only new code was the doorway. Everything behind it had already survived contact with real work.
What It Actually Does
Concreteness beats architecture talk, so here is what happened the first night the loop closed.
From a claude.ai chat, Claude filed a goal into our shared work ledger: a scoped task with acceptance criteria, flagged for dispatch. Within five seconds a daemon on the Mac claimed it, opened a terminal tab named after the repository, spawned a fresh agent in it, and pasted a generated brief: the task, the criteria, and the one command that closes the loop when the work is verified. The agent read the project's maintained knowledge base, implemented the change, ran the tests, and closed its own goal with evidence. The desktop chimed. Back in the browser, claude.ai confirmed completion by reading the same ledger, and could see the live session the whole time through a sessions tool that mirrors the fleet cockpit.
Nobody carried a prompt anywhere. And the part we care most about, the part our April piece called observable parallelism: the agent did not run in a black box. It ran in a terminal tab, on screen, that a human could read, interrupt, or take over at any moment. The cloud got a protocol. The human kept the scaffold.
The same night, we pointed it at a real client problem. Twenty-six raw camera files, nineteen gigabytes, No model on earth should be streaming nineteen gigabytes to a context window. Instead, the machine transcribed every clip with Apple's on-device speech model, indexed what the presenter says in each one, and Claude, reading a one-page index instead of watching video, proposed the cut. The render ran locally through our editing pipeline and the finished MP4 landed on disk with its path reported back to the chat. Total cloud cost of understanding nineteen gigabytes of footage: roughly nothing. The subscription you already pay for does the thinking; the machine you already own does the lifting.
Hands Come Last, and Gated
The newest tool family is the one we resisted longest: GUI control. Screenshot, click, type. The perceive-and-act layer that turns "Claude can see my work queue" into "Claude can drive the machine".
This is where the trust boundary stops being an abstraction, because a remote model that can click is a remote model that can do damage, and prompt injection is not a solved problem. Our rule, borrowed from ten years on building sites before this trade: power tools get guards, and the guard is not optional equipment. So every act crosses three gates that live below the protocol, in the automation layer itself, where no remote caller can reach them. A session gate signed by the Mac's Secure Enclave: the first action from any unapproved caller fires Touch ID on the physical machine, and the grant is time-boxed. A per-target biometric list for the genuinely dangerous surfaces. And an HMAC-chained run log, so every click that ever happened is in a ledger that shows tampering. The cloud can ask. Only a fingerprint on this desk can arm.
We will be honest about what surprised us here: almost nothing at the boundary needed inventing. Bearer token over a tunnel, a firewall rule pinning the endpoint to Anthropic's published egress range (160.79.104.0/21, for the curious), and the gating we already trusted for local automation. The ceremony the April piece mocked for single-user tooling is modest when you only pay it once, at one door.
Where This Lands
The pitch, if we ever write one that fits on a landing page, is roughly: use the Claude subscription you already have, supercharge it with the CLI, and pair it with a desktop cockpit so you can watch the orchestra instead of trusting it. The model market has done its job; intelligence is abundant. What is scarce is the connective tissue between a rented mind and the machine where your actual work lives. That tissue should be yours: your knowledge base in plain markdown, your work ledger in a SQLite file you can query, your renders on your own disk, your audit log signed by your own hardware.
One protocol doorway. One machine behind it. Everything else is subcommands.
Coming soon for download