Дайте LLM реальный, детерминированный контроль над Apache JMeter — создайте планы тестирования, запустите реальные тесты загрузки и прочитайте реальные результаты, никогда не записывая вручную XML или не открывая GUI.

… превращается в запущенный тест JMeter и реальный отчет, через типизированный инструмент вызывает MCP-клиент (Claude Code, Claude Desktop и т. д.) делает напрямую.

Почему бы просто не попросить LLM написать сам T1?

Он может — T2 — это просто XML, и любая способная модель видела множество тестовых планов JMeter. Проблема в том, как это не удается: формат JMeter - это hashTree с десятками хрупких, легко запоминающихся деталей - точные guiclass / testclass пары, имена свойств, которые не соответствуют их ярлыку GUI ThreadGroup.num_threads, а не intProp), целые * битмаски * для типов совпадений утверждения, строгое сопряжение родителей / детей с братьями и сестрами теги. Ничто из этого не является самопроверкой. Неправильное значение по-прежнему создает действительный, загружаемый XML, который просто тихо делает неправильные вещи.

Это не гипотетически — это произошло при строительстве этого проекта. Ранняя версия If Controller генерировала свойство под названием useExpression, установленное на true, которое читается как «да, оцените мое состояние.

jmeter-mcp-server

Give an LLM real, deterministic control over Apache JMeter — build test plans, run real load tests, and read back real results, without ever hand-writing .jmx XML or opening the GUI.

"Load test my API: 20 users hitting POST /orders for 2 minutes,
 5% think time, fail anything over 800ms"

…turns into a running JMeter test and a real report, through typed tool calls an MCP client (Claude Code, Claude Desktop, etc.) makes directly.

Why not just ask an LLM to write the .jmx itself?

It can — a .jmx is just XML, and any capable model has seen plenty of JMeter test plans. The problem is how it fails: JMeter’s format is a hashTree with dozens of fragile, easy-to-misremember details — exact guiclass/testclass pairs, property names that don’t match their GUI label (ThreadGroup.num_threads is a stringProp, not an intProp), integer bitmasks for assertion match types, strict parent/child pairing with sibling `` tags. None of it is self-checking. A wrong value still produces valid, loadable XML that just quietly does the wrong thing.

That’s not hypothetical — it happened building this project. An early version of the If Controller generated a property called useExpression set to true, which reads like “yes, evaluate my condition.” The real JMeter source does the opposite: useExpression=true means don’t evaluate it as an expression — just check if the string is literally "true". Every non-trivial condition silently, permanently failed. No error, no warning — the child sampler just never ran. It only surfaced by actually executing the generated plan against real JMeter and noticing a sample count of zero.

That’s the whole case for this server in one story: an LLM regenerating XML from memory re-risks that exact mistake on every single request. This server encodes the correct shape once, in a serializer (and a matching parser for the reverse direction) checked against real JMeter source and bundled examples, exercised by 166 automated tests including real JMeter runs — and exposes it as typed tools instead. Concretely:

• Correctness through one tested code path, not regenerated-from-memory XML every time.