The thresholds shipped here are narrow — a memory ceiling and a view-count ceiling — and the value is in the shape rather than the coverage: a triage pass that says nothing when nothing is wrong. That is worth more in a performance workflow than a full metrics dump, because the dump is what you already have. Expect to edit the rules file to match your own app before it tells you anything useful.
A performance-triage server for mobile app monitoring data. You point it at a CSV of captured metrics and it applies rule-based checks, returning only the severe warnings rather than a full report — the design choice is deliberate, to keep the output from drowning the finding. The rules live in a file you can edit.
- Severe-problem detection over a performance data file you point it at by URL
- A physical memory warning when VmRSS goes over 1.3GB
- A Views-count warning when Views growth exceeds 700
- Output restricted to severe warnings, so nothing else competes for attention
- Rules editable in `.cursor/rules/quality-rules.mdc` to match your own thresholds
Python 3 and a checkout — create a virtualenv and `pip install -r requirements.txt` (package `mcp-analyze-quality`, version 0.1.0), then point your client at the venv's Python running `main.py`. No account and no key. It reads the data over HTTP, so the CSV has to be reachable: locally that means serving the directory, and for a team the README runs the server on a shared host with clients connecting over ssh.