perfsage-jmeter-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| diagnose_environmentA | Read-only environment diagnosis for Java, JMeter, plugins, and Docker. Use before planning work when you only need readiness details. Returns an EnvironmentReport with ready/java/jmeter/plugins fields. |
| ensure_environmentA | Diagnose and heal the local JMeter runtime (JDK, JMeter, plugins, Docker). Call when the host may lack a usable runtime. Returns a ProvisionResult describing actions taken and the resulting execution_mode. Set force_docker=true to prefer Docker when docker_available (even if native is ready). |
| import_trafficA | Import HAR, OpenAPI, or Postman traffic into a normalised Flow. Use at the start of scripting. kind=auto detects by extension/content. Returns flow JSON plus request_count. Response headers/bodies are omitted unless include_response_detail=true. |
| correlate_flowA | Detect dynamic values and rewrite the flow with JMeter variables. Use after import_traffic. Accepts a flow object or a persisted flow_path. Returns the correlation report, rewritten flow, and a new flow_path. |
| generate_jmxA | Build an Apache JMeter 5.6.3 plan from a correlated flow and workload. Use after correlate_flow. Accepts a flow object or a persisted flow_path. Returns the written path and inline jmx (or jmx_truncated when the XML exceeds 200_000 characters). |
| edit_jmxA | Apply structured edits to an existing JMX plan and write a new file. Use after generate_jmx (or with a hand-written single-ThreadGroup plan). The LLM translates natural-language asks into operations such as set_workload (fixed/ramp/stress/burst), change_method, wrap_loop, wrap_while, and add_jsr223. Writes a new plan by default; set overwrite=true only to replace plan_path. Returns path, summary, ops_applied, and next_action. |
| run_testA | Execute a JMX plan with always-on guardrails and streamable JTL output. Calls ensure_environment first. Returns RunResult fields, run_id, and the provisioning block. Loose guardrails require acknowledged_risk (alias i_understand_the_risk). Optional run_id must match [A-Za-z0-9._-]{1,64}; collisions require overwrite=true. force_docker prefers Docker when available. |
| discover_workloadA | Find a capacity knee by stepping concurrency via -Jperfsage.threads. Calls ensure_environment first. Each step reuses the same plan and overrides thread count/duration through JMeter properties. Returns DiscoveryOutcome plus provisioning and a recorded run_id. Optional run_id must match [A-Za-z0-9._-]{1,64}; collisions require overwrite=true. |
| analyze_resultsA | Summarise a JTL and rank bottleneck findings at p95/p99. Use after a completed run. Returns summary metrics and findings. |
| evaluate_sloA | Gate JTL results against an slo.properties file. Use for CI pass/fail decisions. Returns an SLOVerdict with compliance_pct. |
| correlate_with_signalpilotA | Merge Kubernetes RCA from SignalPilot for a recorded run window. Use when client-side latency needs server-side explanation. Returns a SignalPilotReport (available=False when the CLI is missing). |
| compile_reportA | Compile Markdown/HTML/JSON artifacts with a verdict-led summary. Use after analyze/evaluate. Optionally evaluates SLOs, SignalPilot, and Reveal. For discovery runs, set use_knee_results=true to analyze/SLO the knee step JTL when a knee exists (default remains the last step for compatibility). Returns verdict, written paths, and the report dict. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| setup-perf-environment | Guide the agent through diagnosing and healing the JMeter runtime. |
| record-and-script | Guide import → correlate → generate_jmx for a recorded flow. |
| find-capacity | Guide adaptive workload discovery to a recommended sustained profile. |
| explain-the-regression | Guide results analysis, SLO gating, SignalPilot, and report compilation. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| env_status | Current environment readiness report as JSON. |
| runs_resource | Newest-first list of recorded runs as JSON. |
TDQS
Scored across 12 tools
Most tools map to distinct pipeline stages (import, correlate, generate, run, analyze, report), but diagnose_environment/ensure_environment and correlate_flow/correlate_with_signalpilot have overlapping names and related purposes. Descriptions clarify the boundaries, so an agent can usually select correctly.
All tool names are snake_case and verb-first, following a predictable pattern like diagnose_environment, generate_jmx, and evaluate_slo. correlate_with_signalpilot is a minor deviation from the simple verb_noun shape but still fits the overall style.
Twelve tools are well-scoped for a JMeter performance-testing workflow. Each tool covers a meaningful stage from environment readiness to traffic import, JMX generation, execution, analysis, SLO evaluation, and reporting, with no obvious bloat.
The tool surface covers the full load-test lifecycle: environment provisioning, test creation, execution, workload discovery, results analysis, SLO gating, and report compilation. There are no obvious dead ends or missing core operations for the stated domain.