jmeter-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JMETER_HOME | Yes | JMeter installation directory (must contain bin/jmeter) | |
| JMETER_MCP_WORKSPACE | No | Where plans and executions are stored. Defaults to ./jmeter-workspace relative to wherever the server process starts |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_test_planA | 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_test_plansA | List all test plans in the workspace. |
| get_test_planA | Get the full element tree of a test plan, including every node's id (needed as parentId for add_* tools) and type. |
| add_thread_groupC | Add a Thread Group (virtual users) under the given parent node (usually the TestPlan root). |
| add_http_samplerC | Add an HTTP Request sampler under the given parent node (usually a Thread Group). |
| add_json_extractorA | Add a JSON Extractor post-processor under an HTTP sampler, to save a value from the JSON response into a variable. |
| add_header_managerB | Add an HTTP Header Manager under an HTTP sampler (or a Thread Group, to apply to every sampler in it). |
| add_response_assertionC | Add a Response Assertion under an HTTP sampler, to fail the sample if the response doesn't match. |
| add_aggregate_report_listenerA | 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_summary_report_listenerB | Add a Summary Report listener under the given parent (Thread Group or TestPlan). Its output is what get_execution_report reads after a run. |
| execute_test_planA | 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. |
| get_execution_statusA | Check the status of a test run started with execute_test_plan (running/completed/failed), plus the tail of its log. |
| stop_executionA | Stop a running test execution (sends SIGTERM to the JMeter process). |
| get_execution_reportA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
Each tool targets a distinct action and resource: test plan lifecycle (create/list/get), adding different element types (thread group, sampler, extractor, etc.), and execution/reporting (execute/status/report/stop). Despite similar 'add_' prefixes, each add tool clearly specifies the element it creates, leaving no ambiguity about which tool to use.
All tools follow a consistent verb_noun pattern in snake_case: create_, list_, get_, add_, execute_, stop_. The naming convention is uniform and predictable, making it easy for an agent to infer tool purpose from the name alone.
With 14 tools, the server covers the full test plan workflow—creation, building, execution, and result retrieval—without being bloated. Each tool serves a clear purpose, and the count is well within the typical range for a focused domain.
The set supports creating and reading test plans, adding common elements, and running/stopping executions, but lacks update and delete operations for both plans and elements. This means agents cannot modify or remove existing configurations, forcing recreation of a plan for any change. While the core create-run-report cycle is covered, the absence of edit/removal capabilities is a notable gap.