get_sessions
List current webrtcperf sessions (id and stats for each running session).
LABSCO SUMMARY
Load and bad network conditions in one run, measured from inside the browser.
Because the clients are real Chromium instances, the numbers come from the RTC peer connections themselves — packet loss, round trip time, jitter buffer delay, quality limitation — rather than from a synthetic traffic generator, and the throttle rules can degrade one participant's uplink at a set moment to see what the service does about it. Two things shape where you run it: throttling needs Linux, and the machine hosting the sessions has to have the CPU and bandwidth for every client you start, or you end up measuring your own laptop.
What it is
The MCP mode of WebRtcPerf, a load-testing tool that spawns Puppeteer-driven Chromium sessions against a WebRTC service and collects the statistics its peer connections report. Four tools start, stop, list and reset sessions; everything else is the config object you hand to start_session.
What you get
- start_session takes the session config — url, tabsPerSession, throttleConfig and the rest of the tool's options — and returns the id it created
- get_sessions lists the running sessions with their stats, so a test in progress can be read without waiting for it to end
- stop_session ends one by id, and reset_stats clears the collected statistics so a new measurement window starts clean
- Statistics are aggregated across sessions with sum, mean, standard deviation, 5th and 95th percentile, min and max: bitrate, packet loss, round trip time, jitter, jitter buffer delay, sent resolution and fps, FIR and PLI counts, and quality limitation from CPU or bandwidth
- System CPU, GPU and memory alongside per-page CPU and RSS, so client-side exhaustion is distinguishable from a server-side limit
- Network throttling per session through throttleConfig: rate, delay, delay jitter and distribution, packet loss and loss burst, reordering and queue size, applied to uplink or downlink and to TCP or UDP separately
- Throttle rules carry an at value, so bandwidth can be dropped mid-test and restored later without restarting anything
- Injected page scripts, which is what lets a session get past a join screen into an actual room
Requirements
No account for the tool itself — you need whatever the service under test needs. Node.js with Chromium available, FFmpeg installed on the same machine, and it runs as npx -y @vpalmisano/webrtcperf@latest --mcp; a prebuilt Docker image and a global npm install are the other two routes. Linux is the recommended platform, and the network throttling specifically depends on the Linux Traffic Controller framework. Concurrent sessions consume CPU, memory and bandwidth in proportion to the number of clients you start. AGPL.
Setup effort
One command — npx -y @vpalmisano/webrtcperf@latest --mcp
USE CASES
01
Finding out how many participants a room can hold before quality drops
Start a session with the participant count you want, watch the aggregated bitrate, loss and round trip time as it runs, and stop it when the picture is clear.
02
Seeing what a bad connection does to one participant
Throttle that session's uplink — bandwidth, delay, loss — and compare its sent resolution and frame rate against the unthrottled participants.
03
Testing how the service recovers when bandwidth returns
Schedule throttle rules to tighten and relax at set points in the run, and watch whether the sender climbs back to its original bitrate.
04
Telling a client-side limit apart from a server-side one
Read system and per-page CPU and memory next to the quality limitation counters, which say directly whether the sender was held back by CPU or bandwidth.
05
Measuring a clean window after a configuration change
Clear the collected statistics, let the running sessions settle, and read the numbers that follow rather than an average polluted by the earlier state.
4 tools
Counted once with only startup setup. Other versions, modes or optional credentials may expose a different list.
reset_stats
Reset the collected webrtcperf stats.
start_session
Start a new webrtcperf session in-process. Config is the session config object (url, tabsPerSession, throttleConfig, etc.). Returns the created session id.
stop_session
Stop a webrtcperf session by id.
BEFORE YOU INSTALL
What to know first
Tools you get
4 tools when we connected. The four tools drive a load-testing CLI; what each session does is set by the config passed to start_session (sessions, runDuration, url, throttleConfig), not by extra tools.
Requires
npx on PATH
Where it runs
Both documented clients run the server on your machine.
CONTEXT COST
Light Standing cost
Rated by the size of the 4 tool definitions that ride along on every turn, not by how many there are
INSTALLATION
Connect your client
Server setup
TERMINAL
npx -y @vpalmisano/webrtcperf@latest --mcpMCP Clients
Cursor
CURSOR · JSON
{
"mcpServers": {
"webrtcperf": {
"command": "npx",
"args": [
"-y",
"@vpalmisano/webrtcperf@latest",
"--mcp"
]
}
}
}VS Code
VS CODE · JSON
{
"servers": {
"webrtcperf": {
"command": "npx",
"args": [
"-y",
"@vpalmisano/webrtcperf@latest",
"--mcp"
]
}
}
}
