How to soak-test your MCP server before AI agents do it for you

Description and use

mcpload soak testing uncovers memory, session, and latency issues in MCP servers that single‑client tests miss.

Problem

MCP servers are often tested with a single client and a few manual tool calls, which misses issues that arise under concurrent, long‑running sessions such as memory leaks, session‑not‑found errors, and latency spikes.

Outcome

The soak test on a laptop‑based server with 2 CPUs and 1 GiB memory processed 3,780 sessions and 49,227 requests with no errors, memory remained flat (~136 MiB), and p95 latency stayed around 21 ms. Scaling to 80 concurrent agents increased latency sharply but still produced zero errors, indicating the server’s healthy limits.

Workflow

• Install mcpload from GitHub releases
• Start the MCP server in Docker with fixed resources
• Run a one‑minute smoke test to verify basic functionality
• Execute a 38‑minute soak test with warm‑up, steady load, and cool‑down phases
• Analyze memory and latency metrics from the soak output
• Optionally test load balancer scenarios, never‑closed sessions, and burst traffic
• Integrate mcpload into CI with a GitHub Action for automated testing

Evidence

Most MCP servers get tested the same way: connect one client, call a few tools by hand, ship it.

Source

A leak is flagged only if memory grows steadily during the load window (slope above a limit, with a good linear fit) or doesn’t come back near its baseline during cool‑down.

Source

3,780 sessions, 49,227 requests, 0 errors

Source

Memory flat: ~136 MiB, growing 0.12 MiB/min against a 1 MiB/min limit, and back near baseline after cool‑down

Source

p95 latency steady at ~21 ms for all three tools over the full 30 minutes

Source