Provides tools for accessing BlazeMeter's performance testing API, enabling retrieval of test data, workspace and project management, test run analysis, aggregate reports, error reports, and performance metrics monitoring.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@BlazeMeter MCP Server show me the latest test run results"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This project provides a Model Context Provider (MCP) server for integrating with BlazeMeter's API, enabling programmatic access to performance test data and management features. The server exposes a set of tools that can be used by MCP-compatible clients (such as Claude Desktop and Cursor) to interact with BlazeMeter resources.
Let's set things up!
Before starting, please ensure you have:
npm (included with Node)
Warning: if you run with a lower version of Node, fetch won't be present. Tools use fetch to make HTTP calls. To work around this, you can modify the tools to use node-fetch instead. Make sure that node-fetch is installed as a dependency and then import it as fetch into each tool file.
1. Install dependencies
Run from your project's root directory:
npm installOn Linux/macOS (sh):
which nodeOn Windows (PowerShell):
Get-Command node | Select-Object -ExpandProperty SourceTo check the node version, run:
node --versionTo get the absolute path to mcpServer.js, run:
On Linux/macOS (sh):
realpath mcpServer.jsOn Windows (PowerShell):
Resolve-Path mcpServer.js | Select-Object -ExpandProperty PathRelated MCP server: JMeter MCP Server
You can connect your MCP server to any MCP client. Below are instructions for connecting it to Claude Desktop and Cursor.
Step 1: Note the full path to node and the mcpServer.js from the previous step.
Step 2. Open Claude Desktop → Settings → Developers → Edit Config and add a new MCP server:
{
"mcpServers": {
"<server_name>": {
"command": "<absolute/path/to/node>",
"args": ["<absolute/path/to/mcpServer.js>"]
}
}
}Restart Claude Desktop to activate this change. Make sure the new MCP is turned on and has a green circle next to it. If so, you're ready to begin a chat session that can use the tools you've connected.
Step 1: Note the full path to node and the mcpServer.js from the previous step.
Step 2. In Cursor, open the Command Palette and search for "MCP: Add Server" or go to Settings → MCP Servers.
Step 3. Add a new MCP server with the following configuration:
Command: <absolute/path/to/node>
Arguments: <absolute/path/to/mcpServer.js>
Step 4. Save and enable the server. Cursor will show the MCP server as available, and you can use the BlazeMeter tools directly from the Cursor interface.
Note: For both clients, ensure you use the absolute paths and Node.js v18+.
Warning: If you don't supply an absolute path to a node version that is v18+, the client may fall back to another node version on the system of a previous version. In this case, the fetch API won't be present and tool calls will not work. If that happens, you can a) install a newer version of node and point to it in the command, or b) import node-fetch into each tool as fetch, making sure to also add the node-fetch dependency to your package.json.
For production deployments, you can use Docker:
1. Build Docker image
docker build -t <your_server_name> .2. Client Integration
Add Docker server configuration to your MCP client (Claude Desktop or Cursor):
{
"mcpServers": {
"<your_server_name>": {
"command": "docker",
"args": ["run", "-i", "--rm", "--env-file=.env", "<your_server_name>"]
}
}
}Add your environment variables (API keys, etc.) inside the
.envfile.
The project comes bundled with the following minimal Docker setup:
FROM node:22.12-alpine AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm install
COPY . .
ENTRYPOINT ["node", "mcpServer.js"]To run the server with Server-Sent Events (SSE) support, use the --sse flag:
node mcpServer.js --sseList descriptions and parameters from all generated tools with:
node index.js toolsExample:
Available Tools:
Workspace: acme-workspace
Collection: useful-api
list_all_customers
Description: Retrieve a list of useful things.
Parameters:
- magic: The required magic power
- limit: Number of results returned
[...additional parameters...]This project includes tools for interacting with the BlazeMeter API. You must set the following environment variables in your .env file:
BASE_URL=https://a.blazemeter.com
BZM_USERNAME=your_blazemeter_api_key
BZM_PASSWORD=your_blazemeter_api_secret
BZM_ACCOUNT_ID=your_blazemeter_account_id # (optional, used by workspace-list)
BZM_WORKSPACE_ID=your_blazemeter_workspace_id # (optional, used by project-list)For tools where the parameter is optional, the value will be read from .env if not provided.
For tools where the parameter is required, you must provide it in the request.
Tool Name | Endpoint & Description | Required Parameter(s) |
get_workspaces |
| (optional) accountId |
get_projects |
| (optional) workspaceId |
get_test_runs |
| testId |
get_test_run_summary |
| masterId |
get_test_run_aggregate_data |
| masterId |
get_test_run_errors_data |
| masterId |
get_test_run_thresholds |
| masterId |
get_test_run_timeline_kpis |
| masterId |
Get projects from a specified workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| workspaceId | No | The ID of the workspace to retrieve projects from. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it 'gets' projects, implying a read-only operation, but doesn't disclose behavioral traits like whether it requires authentication, returns paginated results, includes all project fields, or has rate limits. The description is minimal and lacks crucial operational 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 a single, clear sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'projects' entail (e.g., structure, fields), how results are returned, or error conditions. For a tool with no structured behavioral hints, this minimal description leaves significant gaps for an AI agent.
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%, with the single parameter 'workspaceId' fully documented in the schema. The description adds no additional meaning beyond the schema, such as explaining what happens if workspaceId is omitted (since it's not required) or providing examples of valid workspace IDs.
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 ('Get projects') and the resource ('from a specified workspace'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'get_workspaces' or 'get_test_runs' which might retrieve different resources or have different scopes.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare it to sibling tools like 'get_workspaces' (which might list workspaces) or 'get_test_runs' (which might retrieve test-related data).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the aggregate report data for a specified test run (master).
| Name | Required | Description | Default |
|---|---|---|---|
| masterId | Yes | The ID of the test run (master) to retrieve the aggregate report data for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'Get[s]' data, implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns paginated results, or details the format of the aggregate report data. This leaves significant gaps for a tool with no structured safety hints.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'aggregate report data' includes, how it differs from other test run data tools, or behavioral aspects like error handling. For a data retrieval tool with no output schema, more context is needed to guide 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 input schema has 100% description coverage, clearly documenting the 'masterId' parameter. The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints, so it meets the baseline for high schema coverage without extra value.
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 verb 'Get' and the resource 'aggregate report data for a specified test run (master)', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_test_run_summary' or 'get_test_run_timeline_kpis', which likely retrieve different aspects of test run data, so it lacks sibling distinction.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare to siblings such as 'get_test_run_summary', leaving the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the errors report data for a specified test run (master).
| Name | Required | Description | Default |
|---|---|---|---|
| masterId | Yes | The ID of the test run (master) to retrieve the errors report data for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'Get[s]' data, implying a read-only operation, but doesn't clarify aspects like whether it requires authentication, has rate limits, returns paginated results, or what format the errors data is in (e.g., structured JSON, raw logs). This leaves significant gaps for an agent to understand how to handle the tool effectively.
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, efficient sentence that directly states the tool's purpose without any wasted words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes essential 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?
Given the complexity of retrieving errors data (which could involve detailed reports or logs), the lack of annotations and output schema means the description is incomplete. It doesn't explain what the returned data looks like (e.g., error messages, counts, timestamps) or any behavioral traits like error handling. This makes it inadequate for an agent to fully understand the tool's context and usage.
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 has 100% description coverage, with the 'masterId' parameter clearly documented as 'The ID of the test run (master) to retrieve the errors report data for.' The description adds no additional meaning beyond this, such as examples of valid IDs or context on where to find them. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema does the heavy lifting.
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 ('Get') and the resource ('errors report data for a specified test run'), making the purpose understandable. However, it doesn't differentiate this tool from sibling tools like 'get_test_run_summary' or 'get_test_run_aggregate_data', which might also retrieve test run data but for different aspects.
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 provides no guidance on when to use this tool versus alternatives. It mentions 'errors report data' but doesn't specify scenarios where this is preferred over other test run data tools, such as for debugging failures or monitoring error trends, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get test runs (masters) for a specified test.
| Name | Required | Description | Default |
|---|---|---|---|
| testId | Yes | The ID of the test to retrieve runs for. |
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 states the action is 'Get', implying a read operation, but doesn't specify if it's safe, requires permissions, returns paginated results, or details error handling. For a tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence with zero waste. It's front-loaded with the core purpose, making it easy to scan and understand quickly.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'test runs (masters)' entails, the return format, or behavioral traits like safety or limitations. For a tool that likely returns data, more context is needed to guide the agent effectively.
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 has 100% description coverage, with 'testId' documented as 'The ID of the test to retrieve runs for.' The description adds no additional parameter semantics beyond this, so it meets the baseline of 3 where the schema does the heavy lifting.
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 verb 'Get' and the resource 'test runs (masters) for a specified test', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_test_run_summary' or 'get_test_run_aggregate_data', which likely retrieve related but different data about test runs.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare it to siblings such as 'get_test_run_summary', leaving the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the summary report for a specified test run (master).
| Name | Required | Description | Default |
|---|---|---|---|
| masterId | Yes | The ID of the test run (master) to retrieve the summary for. |
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 states this is a 'Get' operation, implying a read-only action, but doesn't clarify aspects like whether it requires authentication, has rate limits, returns structured or unstructured data, or if the summary is cached. For a tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse. Every part of the sentence contributes essential information, earning its place.
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 lack of annotations and output schema, the description is incomplete for effective tool use. It doesn't explain what the summary report contains (e.g., metrics, status, or format), how it differs from sibling tools, or any behavioral traits like error handling. For a tool in a context with multiple similar siblings and no structured output, more detail is needed to guide the agent adequately.
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 has 100% description coverage, with the parameter 'masterId' clearly documented. The description adds no additional semantic context beyond what the schema provides, such as explaining what a 'master' test run entails or format examples. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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 ('Get') and the resource ('summary report for a specified test run (master)'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from its siblings like 'get_test_run_aggregate_data' or 'get_test_run_timeline_kpis', which likely retrieve different aspects of test run data, so it doesn't achieve full sibling distinction.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention what a 'summary report' includes compared to other test run data tools, nor does it specify prerequisites or exclusions. This leaves the agent with minimal context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the thresholds report for a specified test run (master).
| Name | Required | Description | Default |
|---|---|---|---|
| masterId | Yes | The ID of the test run (master) to retrieve the thresholds report for. |
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 states this is a 'Get' operation, implying read-only behavior, but doesn't clarify if it requires authentication, has rate limits, returns paginated data, or what the output format might be. The description adds minimal context beyond the basic action, leaving significant gaps in understanding how the tool behaves.
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, efficient sentence with no wasted words. It front-loads the key action and resource, making it easy to scan. Every part of the sentence contributes to understanding the tool's purpose, earning its place without 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?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns structured data (a 'thresholds report'). It doesn't explain what the report contains, its format, or any behavioral traits like error handling. For a read operation with no structured output documentation, the description should provide more context to aid the agent in using the tool effectively.
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 has 100% description coverage, with the 'masterId' parameter clearly documented. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract from the schema's documentation.
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 verb ('Get') and resource ('thresholds report for a specified test run'), making the purpose understandable. It distinguishes this tool from siblings like 'get_test_run_summary' or 'get_test_run_errors_data' by specifying the 'thresholds report' focus. However, it doesn't fully clarify what a 'thresholds report' entails or how it differs from other test run data tools beyond naming.
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 provides no guidance on when to use this tool versus alternatives. It mentions 'master' in parentheses but doesn't explain if this is required or how it relates to other test run tools like 'get_test_run_aggregate_data'. There is no indication of prerequisites, exclusions, or recommended contexts for selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the timeline KPIs report for a specified test run (master).
| Name | Required | Description | Default |
|---|---|---|---|
| masterId | Yes | The ID of the test run (master) to retrieve the timeline KPIs report for. |
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 states the tool 'Get[s]' data, implying a read-only operation, but doesn't clarify aspects like whether it requires specific permissions, returns real-time or cached data, handles errors, or includes pagination. For a tool with no annotation coverage, this leaves significant gaps in understanding its operational behavior.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly. There is no wasted language, and it effectively communicates the essential information in a compact form.
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 has one parameter with full schema coverage and no output schema, the description provides a basic understanding of what the tool does. However, it lacks details on behavioral aspects like data format, error handling, or performance, which are important for a reporting tool. With no annotations and no output schema, the description is minimally adequate but could be more comprehensive to fully guide usage.
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 has 100% description coverage, with the 'masterId' parameter well-documented as 'The ID of the test run (master) to retrieve the timeline KPIs report for.' The description adds no additional parameter semantics beyond implying the tool is specific to a test run, which is already covered by the schema. This meets the baseline score of 3, as the schema adequately handles parameter documentation.
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 ('Get') and resource ('timeline KPIs report for a specified test run'), making the purpose understandable. It distinguishes this tool from siblings like 'get_test_run_summary' by specifying it retrieves timeline KPIs rather than general summary data. However, it doesn't explicitly contrast with all siblings, such as 'get_test_run_aggregate_data', which might offer similar but broader metrics.
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 provides minimal guidance by specifying it's for a 'specified test run (master)', implying usage when timeline KPIs are needed for a particular run. However, it offers no explicit advice on when to use this tool versus alternatives like 'get_test_run_summary' or 'get_test_run_aggregate_data', nor does it mention prerequisites or exclusions. This lack of comparative context limits its helpfulness in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get workspaces from a specified account.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | No | The ID of the account to retrieve workspaces from. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets' workspaces, implying a read operation, but doesn't clarify permissions needed, rate limits, pagination, or what happens if the accountId is invalid. This leaves significant gaps for a tool with no annotation coverage.
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, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration.
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 no annotations, no output schema, and a simple parameter, the description is incomplete. It doesn't address behavioral aspects like error handling, return format, or usage context, which are needed for the agent to invoke it correctly beyond basic syntax.
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%, so the schema already documents the 'accountId' parameter. The description adds no additional meaning beyond implying retrieval from an account, which aligns with the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
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 verb ('Get') and resource ('workspaces'), specifying it retrieves them from a specified account. It distinguishes from siblings like 'get_projects' by focusing on workspaces, but doesn't explicitly differentiate beyond the resource name.
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage based on the tool name alone.
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.
get_projectsget_test_run_aggregate_dataget_test_run_errors_dataget_test_run_summaryget_test_run_thresholdsget_test_run_timeline_kpisget_test_runsget_workspacesScored across 8 tools
Every tool has a clearly distinct purpose targeting specific resources and report types. The six test run report tools (aggregate_data, errors_data, summary, thresholds, timeline_kpis) each retrieve different data slices without overlap, while get_projects and get_workspaces handle distinct workspace and account-level operations.
All tools follow a consistent verb_noun pattern with 'get_' prefix and snake_case naming. The naming structure is perfectly predictable: get_[resource]_[optional_specific_data] (e.g., get_test_run_aggregate_data, get_workspaces).
Eight tools is reasonable for a performance testing domain, though slightly thin for complete lifecycle coverage. The tools focus heavily on retrieval operations for test runs and workspaces, which fits the server's apparent monitoring/reporting purpose but might benefit from additional test execution or configuration management tools.
The surface provides excellent read-only coverage for test run reports and workspace/project retrieval, but has notable gaps in test creation, execution, and management operations. Agents can query existing data but cannot initiate tests, modify configurations, or perform other essential performance testing workflow actions.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Drive OctoPerf load testing from any AI agent: import, edit, validate, run scenarios, read metrics.
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
Run, debug, and triage tests from your IDE using natural language, no dashboard switching, no manual data transfers. The TestMu AI (formerly LambdaTest) MCP Server is a single remote server exposing four tool suites: HyperExecute — analyze your project, generate YAML configs and test runner commands, then monitor jobs and sessions. Automation — pull a TestID's details plus command, network, and console logs into one chat for instant root-cause analysis. Includes mobile app upload. SmartUI — explain pixel, layout, DOM, and perceptual changes in a visual regression run, with context-aware React/HTML/CSS fixes. Accessibility — audit any public URL or a local React app against WCAG and get ready-to-apply remediation steps. Connects over https://mcp.lambdatest.com/mcp using OAuth 2.1 — no API keys in your config. One-click install in Cursor; works with Claude, GitHub Copilot, Cline, and any MCP client. Tests execute on the TestMu AI cloud: 3,000+ browsers and 10,000+ real devices.
MCP server for AI access to SmartBear tools, including BugSnag, Reflect, Swagger, PactFlow, QTM4J.
