What's Running MCP
Stop AI agents from reporting dead services as live
1 follower
Stop AI agents from reporting dead services as live
1 follower
Every agent session starts blind. It reads a stale doc or an old transcript, decides your dev server is running, and health-checks a process that died three weeks ago. Model memory is a cache with no invalidation. Five read-only tools answer from the OS instead: live agent sessions (pid, uptime, cwd), every TCP LISTEN socket and its owning process, loaded daemons, load/disk. No shell, no writes, no network. MIT and free. claude mcp add --scope user whats-running -- npx -y whats-running-mcp
I run several coding-agent sessions at once, and the same thing kept happening: a session would tell me a service was live because a doc or an old transcript said so. I'd go look and the process had been dead for weeks. Model memory is a cache with no invalidation ā the OS is the only thing that actually knows.
So I wrote a shell script that just asks the machine. I ended up running it at the start of every session, so I wrapped it in MCP.
claude mcp add --scope user whats-running -- npx -y whats-running-mcp
Five read-only tools:
ā¢ whats_running ā the whole snapshot in one call, meant for session start
ā¢ agent_sessions ā which agent processes are actually alive, terminal-attached vs detached/orphan, with pid, uptime and working directory
ā¢ listening_ports ā every TCP LISTEN socket and the process that owns it
ā¢ daemons ā launchctl on macOS, systemd --user on Linux
ā¢ system_stats ā load average, uptime, root-disk free
"Why not just let the agent run ps?" Fair ā and if your setup already does that reliably, you don't need this. Three things pushed me to a server: an agent that *can* shell out mostly doesn't, because nothing tells it to distrust its own memory, whereas a tool described as "use at session start to ground yourself" actually gets called; the useful answer is four commands joined and parsed (ps, lsof for cwd, lsof for ports, launchctl), which agents get wrong in a new way each time; and it works in clients where shell access is off.
Does it phone home? No. There is no network code in it ā just under 250 lines, one file, go read it. No telemetry, no account, no signup, no paid tier.
Read-only by construction: every call is execFile with a fixed binary and fixed flags, so there's no shell and nothing to inject. The only model-controlled inputs in the entire server are one boolean and one substring filter, and that filter is applied in-process with String.includes ā it never reaches a command.
What it does do is disclose your machine to the model: process names, pids, working directories, ports. That's the whole point of it, and also why you shouldn't attach it to a client you don't trust. The README says so in the same words.
One wart you should hear from me rather than find: a probe that fails degrades to an empty result instead of an error, so "nothing is listening" and "lsof didn't run" currently look identical to the agent. For a tool whose entire pitch is *don't report false state*, that's the first thing I want to fix.
It's a brand-new repo with zero stars, so what I'm actually after is criticism: does the read-only argument hold up when you look at the source, what would you want a sixth tool to answer, and if you run agents on Linux I'd like to know how badly it does there ā macOS is my daily driver and Linux is best-effort.
github.com/stcmain/whats-running-mcp ā MIT, free, and staying that way.