Create a new JMeter test plan. Returns the planId and the id of its root TestPlan node, which you'll use as parentId for the first thread group.

List all test plans in the workspace.

Get the full element tree of a test plan, including every node's id (needed as parentId for add_* tools) and type.

Add a Thread Group (virtual users) under the given parent node (usually the TestPlan root).

Add an HTTP Request sampler under the given parent node (usually a Thread Group). To inherit protocol, domain or port from an HTTP Request Defaults config element in scope (add_http_request_defaults), leave that argument out of the call - do not pass an empty string or a placeholder, because those fields have no default of their own. Passing an explicit value always overrides the Defaults for that field.

Add a JSON Extractor post-processor under an HTTP sampler, to save a value from the JSON response into a variable.

Add an HTTP Header Manager under an HTTP sampler (or a Thread Group, to apply to every sampler in it).

Add a Response Assertion under an HTTP sampler, to fail the sample if the response doesn't match.

Add an Aggregate Report listener under the given parent (Thread Group or TestPlan). Its output is what get_execution_report reads after a run.

Add a Summary Report listener under the given parent (Thread Group or TestPlan). Its output is what get_execution_report reads after a run.

Add a CSV Data Set Config under the given parent (a Thread Group to feed every sampler in it, or a single sampler to scope it there). Each thread reads one row per iteration, exposing each column as a JMeter variable. The filename must be an absolute path readable on the machine that will run the test (execute_test_plan runs JMeter from a fresh per-execution directory, so relative paths won't resolve).

Add a User Defined Variables config element under the given parent (TestPlan root for global variables, or a Thread Group to scope them there). Values are set once, before the test starts.

Add a Constant Timer under the given parent to pace requests. Under a Thread Group it delays every sampler in it; under a single sampler it delays only that one, before it fires.

Add a Regular Expression Extractor under an HTTP sampler, to save a value from its response (body, headers, etc.) into a variable using a regex capture group. Use this instead of add_json_extractor for non-JSON (HTML/XML/plain-text) responses.

Add a Transaction Controller under the given parent (usually a Thread Group). Samplers added under it (as its children) are timed and reported as a single named transaction instead of separately.

Add a Loop Controller under the given parent (usually a Thread Group). Samplers added under it (as its children) repeat for the given number of loops each time the controller is reached.

Add an If Controller under the given parent (usually a Thread Group). Samplers added under it (as its children) only run when the condition evaluates truthy. condition is evaluated as a real JavaScript (Rhino) expression after JMeter substitutes any ${var} references, so comparisons work directly, e.g. '${count} < 10' or '"${status}" == "ok"'.

Add a JDBC Connection Configuration (pooled datasource) under the given parent, usually the Thread Group or TestPlan root. A JDBC Request references this element's dataSource name.

Add a JDBC Request sampler under the given parent (usually a Thread Group). dataSource must match a JDBC Connection Configuration's dataSource name added elsewhere in the same plan.

Add a JSR223 Sampler under the given parent (usually a Thread Group), running a script as the sample itself. Scripts default to Groovy, which only works when JMeter runs on a compatible Java (17 is the safe choice; the Groovy bundled with JMeter 5.6.x fails on very new Java such as 25+, killing each virtual user on its first script run) - the result carries a "warning" field when this server detects a mismatch. For unique or random data, prefer the built-in functions ${__UUID}, ${__RandomString} and ${__Random}, which need no script at all.

Add an FTP Request sampler under the given parent (usually a Thread Group).

Add a TCP Sampler under the given parent (usually a Thread Group), opening a raw TCP connection and sending request data.

Add HTTP Request Defaults under the given parent (usually a Thread Group or TestPlan root). Any field left blank on a later add_http_sampler call under the same scope falls back to these values.

Add an HTTP Cookie Manager under the given parent (usually a Thread Group), so samplers in scope share cookies automatically.

Add a While Controller under the given parent (usually a Thread Group). Samplers added under it (as its children) repeat while condition holds. Leave condition blank (or 'LAST') to loop while the last sampler in the loop succeeded; otherwise it's a JMeter expression re-evaluated each pass, looping until it evaluates to the literal string 'false'.

Add a Random Controller under the given parent (usually a Thread Group). On each pass it runs exactly one randomly chosen child (added under it) instead of all of them.

Add an Interleave Controller under the given parent (usually a Thread Group). Runs one child (added under it) per pass, alternating through them in order instead of running them all.

Add a Once Only Controller under the given parent (usually a Thread Group). Its children run only on each thread's first iteration and are skipped on every later one - use it for a login before a looping scenario (or in a Thread Group that loops forever / runs on a scheduler, as find_breaking_point does).

Add a setUp Thread Group under the TestPlan root. Runs once, before all normal Thread Groups start, regardless of where it sits in the tree - typically used for one-time setup (e.g. login, seeding data).

Add a tearDown Thread Group under the TestPlan root. Runs once, after all normal Thread Groups finish, regardless of where it sits in the tree - typically used for one-time cleanup.

Add an XPath Extractor under an HTTP sampler, to save a value from an XML/HTML response into a variable using an XPath expression. Set tolerant=true for real-world (non-strict) HTML.

Add a JSR223 PreProcessor under an HTTP sampler (or a Thread Group, to apply to every sampler in it), running a script before the sample. Scripts default to Groovy, which only works when JMeter runs on a compatible Java (17 is the safe choice; the Groovy bundled with JMeter 5.6.x fails on very new Java such as 25+, killing each virtual user on its first script run) - the result carries a "warning" field when this server detects a mismatch. For unique or random data, prefer the built-in functions ${__UUID}, ${__RandomString} and ${__Random}, which need no script at all.

Add a JSR223 PostProcessor under an HTTP sampler (or a Thread Group, to apply to every sampler in it), running a script after the sample. Scripts default to Groovy, which only works when JMeter runs on a compatible Java (17 is the safe choice; the Groovy bundled with JMeter 5.6.x fails on very new Java such as 25+, killing each virtual user on its first script run) - the result carries a "warning" field when this server detects a mismatch. For unique or random data, prefer the built-in functions ${__UUID}, ${__RandomString} and ${__Random}, which need no script at all.

Add a User Parameters pre-processor under a Thread Group, assigning each thread a different set of variable values (cycled by thread number), set once at thread start unless perIteration is true. Different from add_user_defined_variables, which sets the same values for every thread.

Add a JSON Assertion under an HTTP sampler, to validate a JSONPath expression exists (and optionally matches a value) in the response.

Add a Duration Assertion under an HTTP sampler, failing the sample if it takes longer than maxDurationMs.

Add a Size Assertion under an HTTP sampler, comparing a response field's byte size against a threshold.

Add a Uniform Random Timer under the given parent to pace requests with a randomized delay: delayMs +/- a random amount up to rangeMs, picked fresh before each sample.

Add a Constant Throughput Timer under the given parent, pacing requests to hit a target rate rather than a fixed per-sample delay.

Add a View Results Tree listener under the given parent (Thread Group or TestPlan). Its output is readable via get_execution_report when there's no Aggregate/Summary Report listener present. NOTE: captureFullData currently has no effect - execute_test_plan always runs JMeter with CSV output, and JMeter's CSV writer never emits response body/header columns regardless of this flag (only its XML output format can carry those); this option is a no-op until this server supports XML-format runs.

Add a Backend Listener under the given parent (Thread Group or TestPlan), streaming live metrics to an external backend (InfluxDB by default) instead of a JTL file. If args is omitted, a ready-to-edit InfluxDB argument set is used - at minimum, edit influxdbUrl before running.

Remove an element (and its subtree) from a test plan. The root TestPlan node cannot be removed.

Update an element's props with a shallow merge (or full replace). A prop value of null in props removes that key. When the node's type is one of the modeled types, the resulting props are validated against that type's schema (check the type first via get_test_plan).

Rename an element (its testname in the generated .jmx).

Move an element (and its subtree) to a new parent, optionally at a specific index among the new parent's children (default: appended last). Rejects moving a node into its own subtree.

Reorder a node's direct children. orderedChildIds must be an exact permutation of that node's current children ids.

Enable or disable an element without removing it. A disabled element is skipped by JMeter at run time.

Serialize a test plan to its JMeter .jmx XML, without running JMeter.

Import an externally authored .jmx file (e.g. exported from the JMeter GUI) as a new test plan. Element types this server doesn't model are kept as opaque UnknownElement nodes (their original XML is preserved and re-emitted as-is) instead of being dropped - check unknownElementCount/unknownElementTypes in the response to see what wasn't fully understood.

Start running a test plan with JMeter in non-GUI mode. Returns immediately with an executionId; the run continues in the background. Poll get_execution_status to know when it's done, then call get_execution_report to read the results.

Check the status of a test run started with execute_test_plan (running/completed/failed), how long it has been running, and - while it runs - a progress block computed from the results file so far: samples, error rate, avg/p95 latency, overall and recent (last ~10s) throughput, and the same per label. Poll this tool rather than tailing stdout.log. The logTail is JMeter's console output with JVM startup warnings filtered out; JMeter only prints a summary line there about every 30 seconds, so it can stay the same between quick polls. Once the run ends, call get_execution_report for the full aggregate.

Stop a running test execution (sends SIGTERM to the JMeter process).

Read and aggregate the results of a finished (or still-running) execution, computed from its Aggregate Report / Summary Report listener output: per-label and overall count, error rate, avg/min/max/median/p90/p95/p99 latency, throughput and KB/sec.

Find the concurrency level where a test plan stops meeting its SLA. Runs the plan over and over on its own, driving one thread group's thread count: first doubling the load until the SLA breaks, then binary-searching between the last healthy level and the first broken one. Returns immediately with a searchId; poll get_breaking_point_status for progress and the final breaking point. The thread group is temporarily switched to ramp-up + fixed-plateau (scheduler) mode for the search and its original settings are restored when the search ends. Requires an Aggregate Report, Summary Report, or View Results Tree listener in the plan. Rounds always run the thread group in scheduler mode with an infinite loop count, so every thread repeats its whole scenario until the plateau ends: a request meant to run once per user (e.g. a login) must sit under a Once Only Controller, and a nested Loop Controller runs its count on every repeat. Each round reports its metrics both overall and per label (byLabel, with each label's share of the samples) - check that the mix matches what the plan intends. The SLA is judged on the overall numbers, not per label.

Check a capacity search started with find_breaking_point: status (running/completed/failed/stopped), progress (rounds completed out of maxIterations, plus the in-flight round's elapsed time and percent complete), the rounds run so far with each one's load and overall + per-label metrics, and - once it finishes - the breaking point, the last healthy load, and a plain-language conclusion. breakingPoint is the lowest load that was tested and broke the SLA, not necessarily the exact edge: read breakingPointRange (healthyUpTo / brokenAt / exact) for the real precision, since levels between the two were never run when toleranceThreads is above 1. There is no completion push - poll this tool. The same data is on disk at files.meta, and each round's raw results are in files.executionsDir//.

Stop a running capacity search. Terminates the round in flight, restores the thread group's original settings, and keeps whatever bounds the search had established so far.