Three changes, and two of them are the same idea arriving in stages: a tool that ships a set of commands can now tell the pit what to call them, and installing it is when that happens.
Alchemy joins the roster
moshcode install alchemy
moshcode alchemy auth
One binary covering four things: onchain data across EVM and Solana — balances, NFTs, transfers, prices, blocks, logs, traces, simulations, raw RPC — Alchemy apps, networks, allowlists and webhooks, an agent-ready wallet that sends, swaps, calls contracts, approves and bridges cross-chain, and x402 payments in USDC under a spend cap.
The package's own bin is named alchemy, so the pit word and the executable are the same thing. No product/binary split to explain, the way /secrets fronts logicsrc and /spinifex fronts spx.
Two fields are deliberately absent. There is no upgrade, because npm install -g is idempotent and re-running the install is the upgrade — the same shape mcpjam has. And there is no installHelp, because that line exists to name a missing installer the way alpaca names Go and gradient names python3; npm is not missing, moshcode runs on it. The package does declare node >=22, which npm warns about rather than refuses. Hearing that from the CLI on first run is better than hearing it from an install that already succeeded.
alchemy auth opens a browser, links your account and saves the selected app's API key. Nothing works before that. Scripts and agents want --json --no-interactive, which is what makes it read like the rest of the roster in a pipeline.
Where CoinPay is the payments product moshcode ships alongside, this is the read side of the same world — the chain itself rather than one wallet's ledger.
A tool proposes its pit aliases; the pit disposes
Several tools in the roster are a set of commands rather than one binary, and have short words in mind for them at the prompt. Until now the only way to get those words was to let the tool write ~/.moshcode/aliases.json itself — a file it does not own, and the same objection that keeps railway setup agent out of /install.
So a tool declares an aliases spec, moshcode runs it, reads the JSON and merges it. Declared rather than probed: an aliases --json guessed at every installed CLI would eventually hit one where those words mean something else entirely.
A name you bound yourself always wins, and is named in the report rather than silently kept. Both are plausible readings of the word, and the pit's own aliases carry flags a generic suggestion knows nothing about. Names that collide with a pit command, an engine or a tool are refused for the same reason /alias set refuses them: built-ins resolve first, so such an alias would be dead on arrival.
…and adopting them is part of installing it
The first cut of the above made it its own verb, /alias install <tool>. That was the wrong call, and this release corrects it in the same breath as shipping it.
Seven commands behind one dispatcher are not reachable from the pit until the words that reach them exist. Wiring them up is part of installing the tool, not a second thing to remember afterwards. So /install <tool>, /tools install <tool> and moshcode install <tool> now adopt whatever the tool proposes — and /upgrade does the same, because an upgrade is exactly where a tool gains commands, and a roster adopted once at install time goes stale the first time it ships something new. That is precisely how cli-tools' own generate-names never reached anybody.
It is quiet by construction, which is what makes it safe to hang off an install. A tool that offers nothing — every engine, most tools, alchemy included — prints nothing. One that cannot be asked stays silent rather than following a successful install with an error about a nicety.
/alias install <tool> remains, for anything installed before this existed.
/tools install <name> now routes to the installer rather than answering unknown tool "install". It is the obvious thing to type after /tools has just printed the roster.
Two test fixes this surfaced
Both real. test/tools.test.mjs used a fake shell as a spy that a tool's own shebang could overwrite, and its runner never isolated $HOME — so a successful install inside the suite could rewrite the aliases of whoever ran it.