self-update-mechanism

The YouTeacher MCP server ships a tool, update_self, that lets the server upgrade its own binary from inside a running session. The idea is that the assistant driving the MCP can pull the newest release and swap it in place without the user opening a terminal.

How it works

The tool runs four steps:

  1. Fetch the tarball. It issues a GET /api/mcp-package against the same YouTeacher environment the auth client is already signed into. That endpoint is admin-gated on the server side and streams out the latest @youteacher/mcp release tarball.
  2. Cache it on disk. The bytes are written to ~/.youteacher/cache/youteacher-mcp-latest.tgz, creating the cache directory if it doesn't exist.
  3. Install over the global. It shells out to npm i -g <path> to install the cached tarball on top of the existing global install. npm rewrites the binary entry point; the process already in memory keeps running the old code until it exits.
  4. Exit so the client respawns it. About 250 ms after the tool responds (a delay that lets the response flush first), the process calls process.exit(0). The MCP client — Claude Code, Claude Desktop, or Cursor — sees the server die and respawns it on the next tool call, at which point the freshly installed binary is live.

The response reports the previous version, the byte count, and the cache path, and warns that a tool call issued in the exit window may briefly fail with "server not running" and should just be retried.

Why this shape

An MCP server can't hot-swap the code it is currently executing — the running Node process holds the old module in memory. So instead of trying to reload, the tool leans on a property the MCP client already has: it restarts a server that has died. Exit-and-respawn turns "upgrade a live process" into "install the new files, then let the supervisor bring up a clean one." The version is read from the package's own package.json when the tool runs, before the install, so the reply can name what was running before the swap.

Constraints

  • npm must be on the PATH of the user that spawned the MCP server.
  • The npm global prefix must be user-writable. An nvm-managed Node install satisfies this; a system-wide Node install may need elevated permissions and will fail the install step here.
  • The assistant must wait for the next user prompt before issuing another tool call, or it races the self-exit.

If the package fetch returns a non-2xx status, or npm i -g exits non-zero, the tool returns the error text instead of exiting, so a failed upgrade leaves the running server intact.

about this entry

One of sijie's wiki entries. The AI on this site is grounded in the same corpus and answers in sijie's voice, with citations back to entries like this one — answering costs sijie money, so it waits behind a code: enter an access code →

self-update-mechanism