Point Claude Code, Qwen Code, Cursor, or any MCP client at https://docs.jmeter.ai/api/mcp and your agent answers JMeter questions grounded in this documentation, with a source link for every answer. Free, no API key, no signup.
Compute required thread concurrency, pacing delays, ramp-up schedules, and JVM heap recommendations based on target RPS/TPS and SLA response times using Little's Law.
| Name | Required | Description | Default |
|---|---|---|---|
| targetRps | Yes | Target throughput in requests / transactions per second (RPS/TPS). | |
| thinkTimeMs | No | Think time / user pause between requests in milliseconds (default: 0). | |
| safetyFactor | No | Headroom safety buffer multiplier (default: 1.25 = 25% buffer). | |
| avgResponseTimeMs | Yes | Expected average response time in milliseconds. | |
| testDurationMinutes | No | Steady-state test duration in minutes (default: 10). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden. It states the calculation outputs but doesn't disclose return format, rounding behavior, or how inputs like thinkTimeMs and safetyFactor affect results. It provides a reasonable high-level behavior but lacks deeper edge-case or output details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-front-loaded sentence that efficiently lists the tool's outputs and input basis. No filler or redundant phrasing; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must compensate. It lists output categories but doesn't specify the exact return structure, units, or how recommendations are derived beyond mentioning Little's Law. This leaves some practical uncertainty for an agent deciding whether to invoke the tool and how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage, so the description doesn't need to add parameter meaning. It does reinforce the key inputs (target RPS/TPS and SLA response times) by mentioning them, but doesn't elaborate on optional parameters like thinkTimeMs or testDurationMinutes beyond schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'compute' and clearly names the resource: workload model with concrete outputs (thread concurrency, pacing delays, ramp-up schedules, JVM heap). This distinguishes it from sibling tools like plan_distributed_testing or search_jmeter_docs, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: when you have target RPS/TPS and SLA response times and need to derive load parameters via Little's Law. It doesn't explicitly compare to alternatives or state exclusions, but the context is unambiguous enough for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert one or more cURL commands or HAR (HTTP Archive 1.2) JSON traces into a valid, production-ready Apache JMeter .jmx test plan XML with HTTP Request Defaults, Header Managers, Cookie Managers, timeouts, and assertions. Supports GET, POST, PUT, DELETE, PATCH, and RFC 9838 QUERY methods.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | cURL command string (single, multiline, or batch) or HAR 1.2 JSON text (max 1MB). | |
| threads | No | Thread concurrency / virtual users (default: 1). | |
| loopCount | No | Loop count (-1 for infinite, default: 1). | |
| testPlanName | No | Name of the JMeter Test Plan (default: "cURL Converted Plan"). | |
| rampUpSeconds | No | Ramp-up time in seconds (default: 1). | |
| durationSeconds | No | Test duration in seconds (0 = disabled, default: 0). | |
| parameterizeAuth | No | Extract Bearer token into ${AUTH_TOKEN} variable (default: true). | |
| parameterizeHost | No | Extract common host into HTTP Request Defaults and ${BASE_URL} (default: true). | |
| includeAssertions | No | Add HTTP 200/201/204 Response Code assertions (default: true). | |
| filterStaticAssets | No | Filter out images/css/fonts when parsing HAR (default: true). | |
| includeCookieManager | No | Include HTTP Cookie Manager (default: true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. It discloses the generated artifacts, components such as defaults and managers, timeouts, assertions, and supported methods. It does not mention potential error behavior or whether the output is returned inline or written to a file, but it gives a solid picture of what the tool does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the input, output, generated components, and supported methods without filler. The action is front-loaded and every phrase adds relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a conversion tool with 11 parameters and no output schema, the description covers the input and output shape well. It could mention how the result is returned and what happens on invalid input, but the core contract an agent needs is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already fully documented. The description adds broad context about input format and HTTP method support, but does not explain individual parameters beyond what the schema already states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (convert), a concrete input (cURL/HAR 1.2), and a concrete output (JMeter .jmx test plan XML). It differentiates this tool from the other JMeter siblings that handle snippets, properties, planning, and linting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes when this tool is appropriate: when the agent needs to turn raw cURL commands or HAR traces into a JMeter plan. It lacks an explicit exclusions or mention of alternatives, but the boundary is easy to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full markdown text of one docs.jmeter.ai page. Accepts the page URL (e.g. https://docs.jmeter.ai/topics/api-load-testing/) or a bare path (e.g. topics/api-load-testing).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page URL or path, e.g. https://docs.jmeter.ai/user-manual/functions/ or user-manual/functions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. It discloses that the tool returns full markdown content and accepts either a URL or bare path. It does not mention error behavior, placeholder safety, or whether network errors are possible, but for a read-only fetch the core behavior is reasonably covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences including examples. The core purpose is front-loaded in the first sentence, then the second quickly clarifies accepted input format. No extraneous details or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema) and the description covers both the input forms and the output. It doesn't explain what happens when the page doesn't exist or whether authentication is need, but for a straightforward fetch operation this is enough to compose a correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the schema itself already describes the url parameter and provides examples. The description reiterates the same input forms (the full URL or a bare path) and adds one illustrative example, but adds no new meaning beyond what the schema already conveys. With full coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb ('Fetch'), names the exact resource ('docs.jmeter.ai page'), and specifies the output format ('full markdown text'). It clearly differentiates this tool from the sibling 'search_jmeter_docs' by indicating it retrieves one specific page via URL/path rather than general search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes the use case: fetching one documentation page by URL or bare path. It gives explicit examples of valid inputs. However, it does not explicitly state when to prefer this over sibling tools like search_jmeter_docs, though the distinction is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch production-ready, performant Groovy scripts for JMeter JSR223 samplers, preprocessors, and postprocessors (e.g., JWT parsing & expiration, HMAC-SHA256 signing, dynamic header injection, nested JSON array extraction, custom CSV failure logging).
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Filter by keyword or topic (e.g. "jwt", "hmac", "header", "json", "csv", "logging"). If omitted, returns all recipes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the tool's purpose and does not mention read-only behavior, return format, limitation, version compatibility, or any other side-effect context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one well-structured sentence followed by a parenthetical list of concrete examples. It is front-loaded and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one optional parameter and no output schema, so the description does most of the work. It covers the main scope well, but a short note about what a returned recipe looks like would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of the query parameter with examples. The description adds some contextual color by mentioning topics like JWT, HMAC, and JSON extraction, but it does not meaningfully expand parameter semantics beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Fetch production-ready, performant Groovy scripts for JMeter JSR223 samplers, preprocessors, and postprocessors.' The example use cases clearly distinguish it from sibling tools like search_jmeter_docs or lint_jmx_snippet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by naming the tool's scope and the kinds of tasks it supports. It does not explicitly state when not to use it or mention alternatives, so it misses the fullest possible guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a JMeter test plan XML string or snippet against best practices and performance anti-patterns (e.g., active GUI listeners, legacy BeanShell, uncompiled JSR223, missing timeouts, zero ramp-up, Thread.sleep in scripts).
| Name | Required | Description | Default |
|---|---|---|---|
| jmxContent | Yes | JMX XML string or test plan snippet to analyze. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It mentions validation but does not state whether it modifies anything, returns a report, or requires specific permissions. It also does not describe potential side effects or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently lists the tool's purpose and key checks. It is well-structured and free of unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain what the tool returns, such as a list of violations or a pass/fail status. Given that no output schema is specified, this omission is a significant gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description already covers the parameter adequately, and the tool description adds minimal extra semantics beyond clarifying it is a JMeter test plan. Since schema coverage is 100%, the baseline is 3 and the description does not enhance it significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates JMeter test plan XML against best practices and anti-patterns, listing specific examples. It is distinct from sibling tools that focus on calculation, retrieval, or tuning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you have a JMX string to check for issues, but it does not explicitly state when to prefer this over sibling tools or when not to use it. The examples provide context but no direct guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get immediate root causes, OS/JVM config fixes, and remediation steps for common JMeter exceptions (e.g. "BindException", "SocketTimeoutException", "OutOfMemoryError", "NoHttpResponseException", "SSLHandshakeException", "401/403 after recording").
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Error message, exception name, or status (e.g. "bindexception", "heap", "timeout", "401"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It communicates that this is a lookup-oriented, informational tool returning remediation content, and it scopes the result set to 'common JMeter exceptions.' However, it does not state fallback behavior when the query has no matching exception, how matches are determined, or explicitly confirm that the operation has no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the main deliverable (root causes, config fixes, remediation steps) and uses parentheses for concrete examples. It earns its place, though it is sentence-long and the title overlaps slightly with the description's focus.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a one-parameter lookup tool with no output schema and no annotations, the description sufficiently tells the agent what content to expect and what inputs are relevant. It could be more complete by stating behavior when no exception is matched, but the simplicity of the tool does not demand much more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single query parameter with useful examples (bindexception, heap, timeout, 401), so schema coverage is complete. The description adds no additional parameter syntax or format details beyond the schema, but no gap exists, so baseline scoring is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action and resource: it says to 'Get immediate root causes, OS/JVM config fixes, and remediation steps' for JMeter exceptions. The examples clarify the exact exception types and the 401/403 after recording case, clearly distinguishing this diagnostic playbook from documentation or property lookup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: users should invoke this tool when they need root causes and fixes for JMeter exceptions and status errors. It does not explicitly name excluded alternatives like search_jmeter_docs or lookup_jmeter_property, so it stops short of full exclusion guidance, but the implied use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search or lookup curated JMeter properties (e.g. "httpclient4.idletimeout", "jmeter.save.saveservice.*", "remote_hosts", "summariser"). Returns category, defaults, and recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Property name or keyword to search (e.g. "ssl", "timeout", "jtl", "influxdb"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states that it returns category, defaults, and recommendations, which is useful. However, it does not disclose whether the lookup is read-only (likely safe), whether it requires network access, or any limitations (e.g., only curated properties, not exhaustive). The description adds some value but could be more transparent about the scope of the curated set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences, and front-loaded with the purpose. It includes examples and states the return content. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is fairly complete. It explains what it does, what it returns, and provides examples. It could mention that the lookup is for curated properties only, but that is implied by 'curated'. The lack of output schema means the description should hint at return structure, which it does (category, defaults, recommendations). Overall, adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the parameter 'query' is well-documented in the schema. The description adds examples of property names and keywords, which reinforces the schema. However, it does not add significant new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to search or lookup curated JMeter properties, with examples of property names. It distinguishes itself from siblings like search_jmeter_docs (which likely searches documentation) and get_jmeter_page (which likely retrieves a specific page). However, it could be more explicit about the distinction from search_jmeter_docs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need to find JMeter properties and their recommendations. It does not explicitly state when not to use it or mention alternatives. Given the sibling tools, it could have noted that for general JMeter documentation, use search_jmeter_docs, but it doesn't. The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate Master-Worker RMI port assignments, user.properties, CLI commands, firewall/security group rules, and Docker Compose manifests for distributed load testing.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Sample transmission mode (default: "StrippedBatch"). | |
| workerIps | Yes | Comma or space-separated list of worker / injector IP addresses (e.g. "10.0.1.10, 10.0.1.11, 10.0.1.12"). | |
| disableSsl | No | Disable RMI SSL (default: false). Only for isolated labs. | |
| serverPort | No | RMI registry port on workers (default: 1099). | |
| environment | No | Target infrastructure environment for firewall/CLI rules (default: "aws"). | |
| controllerIp | No | Controller / Master node IP or hostname (default: "10.0.0.5"). | |
| clientRmiLocalPort | No | Pinned controller callback port (default: 60000). | |
| serverRmiLocalPort | No | Pinned worker engine port (default: 50000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries full burden to disclose side effects—but it's categorized as 'Plan' (implying a pure, non-mutating operation). The description doesn't disclose whether this actually provisions resources, only outputs manifests, or requires cloud credentials. Given the sibling 'plan' semantics and lack of destructive annotations, an agent might assume it's safe, which is likely correct (it generates configs), but the description never explicitly states there are no network mutations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, action-first, densely packed with specific artifact names. Front-loaded with 'Generate' then enumerates deliverables. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 8 params, schema covers all of them with types, defaults, and formats. The description adds the 'Master-Worker' architectural context and the full inventory of generated outputs (user.properties, CLI, firewall rules, Docker Compose). The lack of an output schema means the agent can't know the exact structure of the response, but the described artifacts (CLI commands, YAML) are self-explanatory enough. Slight deduction because it doesn't explicitly state what happens with default parameters or the 'Plan' intent (non-execution).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter is documented in the schema with defaults and descriptions. The description adds the 'Master-Worker RMI' framing and mentions 'firewall/security group rules' and 'Docker Compose manifests' which are not directly in parameter names, giving context that parameters like clientRmiLocalPort and serverRmiLocalPort are the RMI ports referenced. However, it doesn't fully explain how the parameters translate into the generated artifacts (e.g., how environment affects output).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific and action-oriented: 'Generate Master-Worker RMI port assignments, user.properties, CLI commands, firewall/security group rules, and Docker Compose manifests' for distributed load testing. This clearly distinguishes it from sibling tools like calculate_workload_model or lookup_jmeter_property by naming the exact artifacts produced.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly signals this is a planning/artifact generation tool for distributed test setup, but it doesn't explicitly state when to prefer it over alternatives (e.g., use when setting up JMeter distributed mode) or when NOT to use it (e.g., single-node tests). Sibling differentiation is implied but not explicit—'Plan Distributed Testing' is self-evident in context but not contrasted with related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Apache JMeter documentation on docs.jmeter.ai. Returns the most relevant pages with titles, URLs, and snippets. Use for any question about JMeter test plans, components, functions, properties, distributed testing, reports, or troubleshooting.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query, e.g. "how to correlate dynamic values" or "thread group ramp up" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It clearly states the output format ('recent pages with titles, URLs, and snippets') and implies a read-only operation. It does not mention any side effects or limitations, but for a search tool this is reasonably transparent. The lack of statement about being non-mutating is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first defines the action and source, second describes the output and intended use. No filler or irrelevant information. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with a single parameter and no output schema, the description adequately covers what it does and returns. It mentions the domain (docs.jmeter.ai) and the types of results. It could be enhanced by noting how results are ordered or if there are limits, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single 'query' parameter, including an example. The description adds no additional parameter context beyond what the schema already contains. Per the rubric, baseline 3 is appropriate when schema coverage is high and the description doesn't supplement it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search') and the resource ('Apache JMeter documentation on docs.jmeter.ai'). It specifies the return type ('pages with titles, URLs, and snippets'), which fully distinguishes it from sibling tools like get_jmeter_page (which likely retrieves a specific page).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use it: 'Use for any question about JMeter test plans, components, functions, properties, distributed testing, reports, or troubleshooting.' However, it does not mention alternatives or exclusions, such as pointing to get_jmeter_page for retrieving a known page. So it has clear context but no contrast with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate production sysctl.conf, limits.conf, systemd overrides, and Docker/K8s configs tuned for high-concurrency JMeter load testing (fixing ulimit nofile, BindException port exhaustion, somaxconn backlog, and JVM swappiness).
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Machine role: "injector" (JMeter client) or "target_sut" (default: "injector"). | |
| ramGb | No | Host machine RAM in GB for TCP buffer sizing (default: 16). | |
| concurrency | No | Target concurrent connections/threads (default: 10000). | |
| trafficType | No | Traffic profile (default: "http_churn"). | |
| targetDistro | No | Linux distro or container target (default: "ubuntu_debian"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is the sole source for behavioral disclosure. It states 'generate' but does not clarify whether the output is written to files, printed to stdout, or if the tool requires elevated permissions. No side effects or prerequisites are mentioned, leaving the agent uncertain about the tool's execution model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that lists the primary output and the problems it solves. There is no unnecessary filler or redundancy, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description must fully explain the tool's behavior. It does not clarify the return format (e.g., a combined text block, multiple files, or a configuration object) or whether the tool actually modifies the system. This missing information leaves the agent with incomplete context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover all parameters (role, ramGb, concurrency, trafficType, targetDistro) clearly. The description adds no extra meaning to these parameters, but the existing schema is sufficient. Since schema coverage is 100%, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates specific config files (sysctl.conf, limits.conf, systemd overrides, Docker/K8s configs) for high-concurrency JMeter load testing, and lists the concrete issues it addresses (ulimit nofile, port exhaustion, etc.). This distinguishes it from sibling tools that handle other aspects like workload calculation or documentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool over alternatives. It lacks situational context or comparisons with sibling tools (e.g., calculate_workload_model, plan_distributed_testing) that might be relevant for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
convert_curl_or_har_to_jmxtune_linux_osplan_distributed_testingcalculate_workload_modelget_jmeter_pageget_jsr223_recipelint_jmx_snippetlookup_error_playbooklookup_jmeter_propertysearch_jmeter_docsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Each tool addresses a clearly distinct need: conversion, validation, workload math, distributed planning, OS tuning, docs search/page retrieval, error lookup, property lookup, and script recipes. Even the doc-related tools are complementary: search returns links, while get_jmeter_page fetches full content.
All tool names follow a consistent lowercase snake_case verb_noun pattern: calculate_, convert_, get_, lint_, lookup_, plan_, search_, tune_. The verbs clearly signal the action and the nouns clearly signal the target, making the set predictable.
Ten tools is well-scoped for a JMeter-specific MCP server. Each tool targets a meaningful area: test plan generation, validation, workload modeling, distributed execution, OS tuning, documentation, and troubleshooting. None feel redundant or superfluous.
The surface covers the main JMeter workflow: converting HTTP input to JMX, linting it, fetching scripting recipes, planning distributed runs, tuning the OS, and researching docs/errors. A minor gap is the lack of a general raw JMX builder or meaningful coverage for non-HTTP protocols, but most practical JMeter use cases are addressed.