Skip to content

Innovation

OctoPerf MCP Server, Fully On-Premise: AI Load Testing With a Local LLM

When we released the OctoPerf MCP Server, it ran as a hosted endpoint at https://api.octoperf.com/mcp, and most teams connect to it straight from Claude.ai or Claude Code. But a recurring question came from banks, hospitals, defense and public-sector teams: what if nothing is allowed to leave our network, not even the prompt? This article answers that question with a full walkthrough.

We will stand up a 100% on-premise, air-gapped stack, and it only takes two things to install: OctoPerf Enterprise in Docker, and a local Qwen3 large language model running in LM Studio, which doubles as the Model Context Protocol client. By the end, you will drive your load tests in plain language from a chat window, with no API key, no cloud LLM and no outbound traffic.

Webinar Replay: OctoPerf AI and the New MCP Server for Performance Testing

Last Thursday, we hosted a webinar to unveil one of the most important innovations in OctoPerf's recent history: OctoPerf AI and our new MCP Server.

If you have been using OctoPerf for a while, you know that we are not the kind of company that follows technology trends for the sake of marketing. Over the past months, AI has become impossible to ignore. At every conference, every booth seems to promote an AI-powered solution.

We deliberately took a different approach.

Playwright Virtual Users: Load Testing What Real Browsers Actually See

This is the third post in our "Features Sitting Idle" series, where we shine a light on OctoPerf features that are already in your account but rarely used to their full potential.

Features Sitting Idle - Playwright VUs

"Your Application Loads Content Through JavaScript. Your Load Test Doesn't See It."

This is a blind spot many teams discover too late. Tests pass, metrics look fine, yet real users report slowness or errors after a release.

The root cause is almost always the same: the load test was built against the HTTP protocol layer, but the user pain happens in the browser, above that layer.

Designing a Token-Efficient MCP Server: the OctoPerf Approach

In the first two articles of this series we showed what the OctoPerf MCP Server does. This one is for the builders: how we designed it, and specifically how we kept its token cost under control.

Because here is the thing nobody tells you when you start writing a Model Context Protocol server: the hard part is not exposing your API to an LLM. The hard part is not exposing too much of it. Every byte a tool returns lands in the model's context window, where it costs money, adds latency, and dilutes the model's attention. A server that naively mirrors a REST API produces an agent that is expensive, slow, and confused.

This article walks through the five patterns we applied to avoid that fate. None of them is specific to load testing: if you are building an MCP server for your own product, they should transfer directly.

OctoPerf MCP Server in Action: Browser Probes, Scheduled Runs and Smarter Reports

In our previous article we introduced the OctoPerf MCP Server and followed three skills (validation triage, auto-correlation, scenario diagnosis) through a complete workflow: from a raw HAR recording to a diagnosed 500-user load test.

This second part covers the remaining skills, and they take the story further: measuring what real users perceive during the load with a Playwright browser probe, turning the test into a recurring schedule, and letting the agent read the resulting reports widget by widget, trends included. Same format as before: the actual conversation between a user and the LLM, then the matching result in OctoPerf.