The capture comes off the AudioContext output node, so there is no room, no mic and no export step between what the app produced and what gets measured. The cost of that is setup: it only works on an app you are running, with the middleware mounted and one line added to the page.
An MCP server plus a browser SDK that taps the Web Audio graph of a running web app. Your dev server mounts an Express middleware, the page calls WebEar.init(), and the agent can record a short clip and measure its loudness, tone, band balance and timing.
- capture_audio — record 500ms to 30s of what the app is putting out right now
- analyze_audio — RMS, peak dB, clipping, spectral centroid, frequency bands, BPM and timing jitter
- describe_audio — a plain-English read of the same clip
- diff_audio — compare two captures and flag what changed in loudness, tone, timing and clipping
- mix_coach — the measured report and the heard description together
- Client init covers raw Web Audio, Tone.js, a Three.js AudioListener, an explicit AudioContext, or a plain script tag
The npm package webear over stdio, plus the Express middleware mounted in your dev server and one init call in the page. The registry manifest lists CODEDSWITCH_API_KEY as required and WEBEAR_BASE_URL — the address of that dev server — as optional. Without a key, analyze_audio still returns duration, loudness, peak level and clipping locally when ffmpeg is on your PATH; the spectral, band, BPM and jitter figures, describe_audio, diff_audio and mix_coach need one. Keys come from a free codedswitch.com account, whose free tier is 50 analyses a day.
One command plus a key — npm install webear, then supply credentials