Moxy

moxy

MCP proxy that aggregates multiple child MCP servers into a single unified server.

Overview

Moxy spawns child MCP servers as subprocesses, communicates with them via JSON-RPC over stdio, and presents their tools, resources, and prompts through a single unified MCP server. Child server capabilities are namespaced with a dot separator (e.g. `grit.status`, `chix.build`).

Configuration is loaded from a hierarchy of TOML moxyfiles — global (`~/.config/moxy/moxyfile`), per-directory, and project-local — with later files overriding earlier ones by server name. Moxy also discovers declarative tool configs called **moxins** from `MOXIN_PATH`, so you can add MCP tools without writing any Go code.

Why moxy

Traditional MCP servers are standalone programs that each handle their own protocol negotiation, process lifecycle, and output management. Moxy replaces that per-server boilerplate with a shared runtime that provides several features out of the box:

**Result caching and progressive disclosure.** Tool outputs exceeding the inline-token threshold are streamed into [madder](https://code.linenisgreat.com/madder) (a content-addressable blob store) and replaced with a `madder://blobs/` URI plus a head/tail summary. Agents see enough to decide whether the full output matters, and can read the full blob with `madder cat ` (or via the `madder://blobs/{digest}` resource) — without blowing up the context window on a 10,000-line `git log`. Truncation warnings are explicit so agents never mistake partial output for complete output. Moxy expects a `.default` store at startup; spinclass auto-initializes one per worktree, otherwise run `madder init .default` from your repo root.

**Composable result URIs.** The `madder://blobs/` URIs are first-class across moxin tools. A `folio.read` call can take the URI from a previous `rg.search` result as its file path; a `jq.jq` call can take one as stdin. Moxy rewrites these to file descriptors at invocation