perfdigest-mcp

# perfdigest Local **MCP server** that makes development-loop reports **token-efficient** for LLM coding agents — profiler output first, and since v1.2 the rest of the loop's feedback artifacts too (build traces, build diagnostics, benchmark results, CI run logs, repo change state). It sits between the tool and the agent: reads the report from disk and returns a small, structured, numeric digest the agent can act on, while keeping a pointer back to the raw report for lazy expansion. It is a **translator/router, not a judge** — interpretation ("is this kernel memory-bound?") is the model's job. perfdigest only provides efficient, deterministic access to clean numeric metrics across vendors and languages. ## Two operations — keep them separate perfdigest deliberately splits what an agent does with a profiler into two tiers: 1. **Digest (read a report) — universal, available on every machine.** A report's origin is irrelevant to digesting it. An NVIDIA `.ncu-rep` (or its CSV export) captured on a CI/remote GPU runner can be pulled to a **Mac** and digested there — that is how you do CUDA work on a Mac via CI. Tier-1 is never gated by local hardware, only by whether a reader's dependency imports. 2. **Capture (produce a report) — platform-verified.** You cannot run `ncu` on a Mac, Metal on Linux, or hardware PMU counters under WSL2. `platform_capabilities` and `suggest_profile_command` gate this so the agent never spends context on a capture that can't run here, and redirect it to "capture elsewhere, digest here." ## The four feedback channels (v1.2 — the Development Observatory) Every change a session makes propagates through the same four stages, each with its own verbose artifact: *what changed* (RepoState) → *does it build, at what cost* (BuildDigest) → *does it pass* (CIDigest) → *how fast is it* (PerfDigest). perfdigest digests all four through the **same seven tools** — a backend is a registry row, not a new API surface. One principle…