Apache JMeter 上で LLM をリアルに、決定的な制御 — テスト計画をビルドし、実際のロードテストを実行し、実際の結果を読み込みます。 決して手書きなし [.jmx]]) XML または GUI を開きます。

…実行中のJMeterテストと実際のレポートに、タイプされたツールを介してMCPクライアント(Claudeコード、Claudeデスクトップなど)を直接呼び出します。

#[.jmx自体を書くためにLMを尋ねるのではなく、なぜですか?

「.jmx」は単なるXMLで、JMeterテストプランが豊富に見つかりました。 問題は how で失敗します: JMeter のフォーマットは hashTree] で、 分かりやすく分かりやすい詳細 — 厳密に [guiclass/[testclass]] のペア、 GUI ラベルに一致しないプロパティ名 ([ThreadGroup.num_threads) は [[intProp]])、 ではなく intProp ではなく intProp] で、 親しいチャイルドのペア [T9] をアサートチャイルドのペア [T9] [T6] ペア] と一致します。 どれもセルフチェックです。 誤った値はまだ有効で読みやすいXMLを生成し、ただ静かに誤ったことをします。

それは仮説ではなく、このプロジェクトを構築しました。 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.