One tool is the whole capability, so the reason to look at this is the transport work around it: it implements the Streamable HTTP spec on the root route with real session handling and keeps the older SSE route alive for clients that need it, with an nginx config in the README for putting it behind a proxy. That makes it as useful as a reference for wiring up a remote MCP server as it is for reading a load average.
A small Go server that answers one question: what is this machine doing right now. It returns CPU details — core count, model, load — and memory totals, used and available. The interesting part is the transport coverage: the same binary serves stdio for local clients, Streamable HTTP on `/` with `Mcp-Session-Id` session management and resumable streams, and the older HTTP+SSE protocol on `/sse` for clients that have not moved yet.
- `get_system_info` returns CPU core count, model and load together with total, used and available memory
- Streamable HTTP on `/` — POST and GET on one route, sessions via the `Mcp-Session-Id` header, DELETE to end one
- Legacy HTTP+SSE on `/sse` for older clients, alongside the new route rather than instead of it
- Structured logging with a `component`, `session_id`, `method`, `duration` and `status` on every event
Go toolchain to build: `go build -o system-info-server .`, or use the Docker image built from the repo. Running the binary with no arguments gives stdio; setting `PORT` switches it to HTTP. `LOG_LEVEL` and `ENVIRONMENT` control logging — production emits JSON with RFC3339 timestamps, development emits coloured console output. No account, no key, nothing external: it reads the host it runs on.
Build from source — clone the repository and build it, then point your client at the binary