One hub, one address per server
Each configured MCP server is served at its own path on the daemon, over Streamable HTTP. A session's configuration holds a URL per server instead of a command to run.
The fleet's shared MCP hub
One roost. Every session.
Roost is one small daemon that serves every MCP server to every Claude Code session, so a new session costs a few URLs instead of a few dozen processes.
Internal to Renkara. Roost is a tool Renkara Media Group builds and runs for itself. It is not for sale, and there is nothing to buy or join.
The picture
Sessions in front, servers behind
One daemon sits between every session and every server. Sessions talk to it over HTTP, and it keeps at most one process per server.
- Sessions connect to the daemon over HTTP on the loopback interface, one URL per server.
- The daemon holds a router, saved catalog snapshots, and a supervisor.
- Servers run as one shared child each, started on the first call. A server nobody is using has no process.
Features
One daemon in front of every MCP server.
Roost multiplexes sessions onto shared, lazily started MCP servers. It runs as a background process on one Mac, listens on the loopback interface only, and is operated with a small command-line tool. These are the jobs it does today.
Fewer processes, same tools
Tool names stay the same
The client's config key is the server's key in Roost, so every tool keeps its mcp__server__tool name. No session, permission rule, or document that names a tool needs an edit.
At most one process per server
In the default shared mode, one child process per server is multiplexed across every session. Sessions share the child's single connection, whose request IDs cannot collide.
Three modes
Shared is the default. Per-session gives a stateful server its own child for each session, and passthrough relays to a server that already runs somewhere else at a URL.
A server runs only while someone uses it
Starts on the first real call
A child starts when a tool is first called, never when a session only lists tools. Listing is answered from a saved snapshot of the server's catalog, so opening a session wakes nothing.
Stops when idle
A child that has been idle past its time limit (30 minutes by default) is stopped, unless a request is still running on it. A server can be marked keep-warm to be exempt.
Catalogs stay current
Snapshots refresh when a server starts, when its watched files change, and on demand. If a running server's code changed since it started, a refresh restarts it so the catalog matches the code on disk, and says so.
Sessions hear about changes
When a refresh adds, removes, or changes tools, Roost sends a list-changed notice to live sessions on a best-effort basis.
One bad server cannot take down the rest
A circuit breaker per server
After three failures in a row the breaker opens and calls fail fast with the child's last error lines. After 60 seconds one probe call is let through, and only a successful call closes the breaker again.
Deliberate stops are not failures
A restart, an idle stop, a reload, or a shutdown that interrupts a request fails that request with a message to retry. It never counts against the server.
Self-healing daemon
Under launchd's keep-alive the daemon is respawned after a crash. A kill -9 test measured about six seconds, and sessions reconnect on their own when the daemon comes back.
A way back that always works
Switching the fleet over saves a backup of every client config first. One command restores the old direct-start configs, so the hub is never a one-way door.
Ten commands and two endpoints
Prove it before switching
roostctl verify starts each server directly, diffs its tool list against what Roost serves, and must pass for every server before the fleet is switched. A failure names which half failed and the innermost error.
See what it is doing
roostctl status and top show each server's mode, process, memory, warm or cold state, last use, calls, spawns, median latency, tool count, and last restart with its reason.
Change servers without a restart
Edit the config file, run roostctl reload, and servers are added, removed, or changed in the running daemon.
Diagnose in one command
roostctl doctor checks the config, the port, the launchd job, the daemon's own health, snapshot ages, the open-file limit, and whether any server's interpreter sits on a path that package upgrades move.
How it works
From a session's first call to an idle child
Connect
A session opens a server's URL on the loopback interface. Roost answers the initialize and the tool list from its saved snapshot. No child starts.
Call
On the first tool call, the supervisor starts that server's one shared child and sends the call through its connection.
Share
Every other session's calls to the same server use the same child. The breaker watches each call.
Reap
When no one has used the child for its idle limit, Roost stops it. The next call starts it again.
Accessibility
Built so everyone can use Roost.
Roost has no screen to look at: it is a background daemon, a command-line tool, and two plain-text status endpoints. Here is what that means for access today, read from its code, and what nobody has checked. We do not claim a conformance level for Roost.
Supported
Keyboard operation
Everything is done from the keyboard. The ten roostctl commands are typed in a terminal, and the health and status endpoints answer ordinary requests. Nothing needs a pointer.
Not yet tested
Screen reader landmarks and labels
roostctl prints plain text, one row or one line per item, which a terminal screen reader can read. Nobody has tried one. The live view, roostctl top, redraws the whole screen on a timer, and how that reads aloud has not been checked.
Not yet tested
Contrast in light and dark
roostctl sets no colors of its own, so contrast is whatever the terminal theme provides. No measurement exists.
Partly supported
Reduced motion
roostctl status, doctor, and verify print once and stop. Only roostctl top redraws, on an interval you choose with a flag, and it does not animate anything.
Not yet tested
Text resize and zoom
Text size is the terminal's own setting, so a larger font works as it does for any command. Roost itself has no layout to break, but no one has tested it at a larger size.
Not supported
Mobile and touch
Roost is a macOS background process. It has no phone or tablet version and no remote interface: it listens on the local machine only.
Tech specs
Under the hood
| Daemon |
|
|---|---|
| Command-line tool |
|
| Configuration |
|
| Running and testing |
|
| Stands in for | A private copy of every MCP server in every session, Restarting a session to pick up a changed tool list |
Works with
Part of the Renkara fleet
FAQ
Questions people ask
Is Roost available to other teams?
No. Roost is internal to Renkara and is not offered for sale. This site describes what it does and how it is built. Write to contact@renkara.com with questions.
Why does this site have no screenshots?
Roost has no screen. It is a background daemon with a command-line tool and plain-text status endpoints, so there is no interface to capture. The diagram on the home page is drawn from the code and design notes.
What does the saving actually look like?
When Roost was designed, 22 servers were configured and four sessions were open, and the machine was running 92 server processes using 5.85 GB of memory. That was projected to about 17 GB at a dozen sessions. Roost's requirement is under 1 GB across ten or more sessions, with the daemon itself measured at 59 to 83 MB.
What happens if Roost stops?
New sessions cannot reach their servers until it is back. Under launchd it respawns in about six seconds, and sessions reconnect by themselves. If it cannot come back, roostctl revert restores every client's old direct-start configuration from the backup made before the switch.
Can anything on the network reach it?
No. The daemon binds the loopback interface only, and the admin endpoints are loopback-only too. Secrets for the servers live in a configuration file readable by one user.
Contact
Questions about this tool?
Write to Renkara Media Group and a person will answer.