
Stallhunt
io.github.guillemPublished by GitHub account guillemv0.5.1Updated Oct 24, 2026
Evidence-backed Linux performance triage over MCP
Overview
Local Linux performance triage server that lets a coding agent query evidence-backed diagnoses of CPU, memory and I/O stalls on the machine it runs on.
- What you can do
- Query diagnoses of what is constraining useful work, who is suffering and who is likely responsible
- Read pressure verdicts on CPU scheduling contention, memory pressure and block I/O, with per-process attribution and confidence levels
- Access a resident sampler's rolling view of recent pressure for fast answers, or run without the sampler
- Work with bounded observation windows and structured JSON evidence rather than raw utilization numbers
- When to use it
- Useful when an agent is debugging a slow or overloaded Linux machine and needs to know which process is stalling others, rather than just reading top or vmstat output. It is meant for local investigation on the same host, not for remote fleet monitoring.
- Requirements
- Runs as a local process on the user's machine (stdio), distributed as a Linux MCPB package; source builds need Rust 1.85 or newer. Requires Linux 4.20 or newer with procfs mounted and readable PSI files under /proc/pressure for pressure verdicts. No accounts, API keys or environment variables are declared.
Installation
In SourceWeft
- Open Stallhunt in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
Stallhunt
Stallhunt is a Linux-first command-line performance triage tool.
Repository: https://github.com/guillem/stallhunt
Traditional tools such as top, htop, iotop, vmstat, and iostat expose measurements. They are excellent tools, but the human operator still has to answer the harder question:
What is actually constraining useful work right now, who is suffering, and who is probably responsible?
Stallhunt aims to automate that reasoning.
Install
Requirements:
- Linux 4.20 or newer with procfs mounted; readable PSI files under
/proc/pressureare required for pressure verdicts, - Rust 1.85 or newer for source builds.
See docs/install.md for cargo install, release tarballs, and the support matrix.
From a clone:
Bare stallhunt runs a default 10-second hunt. On a terminal it renders a
compact, color-coded report; piped or redirected output (stallhunt | cat,
>file, CI) is unchanged plain text. Use --json for the full structured
evidence, --verbose to expand the compact report's collapsed caveats back
to full text, or --no-color (also NO_COLOR=1) to disable color without
changing the layout:
Capture and replay a normalized observation:
Follow finding lifecycle for a bounded number of rolling windows. On a
terminal this opens a full-screen TUI (q quit, arrows/jk select,
Enter/Space show or hide detail, PageUp/PageDown/Home/End scroll,
h/? help). At 120×30 or larger it also shows the selected host/cgroup's
six process-role lists beside the lifecycle panels; piped output or
--json remain append-only text/JSON and carry the same scoped roles:
Serve Model Context Protocol tools over stdio so coding agents can query
diagnoses directly — a resident sampler keeps a rolling view of recent
pressure for instant answers (for Claude Code: claude mcp add stallhunt -- stallhunt mcp; see docs/mcp-server.md):
Source packaging for an OpenAI local plugin, a Linux MCPB extension for
compatible clients, and official MCP Registry metadata lives in the
repository. These packages deliberately keep diagnosis local instead of
hosting Stallhunt on a machine other than the one being investigated. See
docs/directory-distribution.md.
Generate shell completions:
Recording output paths are not overwritten unless --force is supplied. Ten-second hunts are the normal diagnostic path; sub-second observations are telemetry smoke tests and do not receive healthy or pressure verdicts. See docs/development.md for validation and opt-in acceptance commands.
Core idea
The primary abstraction is lost time, not utilization.
High utilization is not automatically a problem. A machine using 95% of its RAM may be perfectly healthy. A CPU at 70% utilization may still have latency-sensitive work suffering from scheduler contention. The project therefore focuses on evidence of stalled progress:
- CPU scheduler pressure,
- I/O stalls,
- memory pressure/reclaim,
- lock contention,
- network-related waits,
- eventually deeper blocking chains.
Example output shape:
This output is aspirational; the project will reach it incrementally.
Product principles
- Diagnose, do not merely display.
- Measure stalled progress whenever possible.
- Separate observation from inference.
- Show evidence for every diagnosis.
- Express uncertainty explicitly.
- Remain useful without eBPF.
- Stay cheap enough to run on a stressed system.
- Treat Git as the complete project memory.
Initial scope
The first useful release targets Linux and focuses on:
- CPU scheduling contention,
- memory pressure,
- block I/O pressure,
- per-process attribution where Linux exposes enough evidence,
- cgroup/systemd-aware grouping when practical,
- human-readable terminal output,
- versioned machine-readable JSON (the pre-1.0 shape may evolve),
- bounded observation windows,
- deterministic offline fixture/replay analysis.
Later releases may add:
- eBPF-based off-CPU analysis,
- futex/lock contention,
- syscall/blocking attribution,
- network queue/socket diagnosis,
- dependency/wait graphs,
- richer cgroup/container analysis.
Repository map
Start with AGENTS.md, then docs/README.md.
Privacy Policy
Stallhunt reads bounded local Linux telemetry and does not independently send it over the network. MCP clients may transmit tool results according to their own data policies. See the full Stallhunt privacy policy for the data, storage, sharing, retention, and contact disclosures.
License
Dual-licensed under MIT or Apache-2.0, at your option.
Current state
For the current milestone, implemented capabilities, validation, known limits,
and the next recommended task, see docs/status.md. Planned
sequencing remains in docs/roadmap.md.
Source: README.md at commit 2df52cc
Tools
0Version history
1- v0.5.1LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts