k6-mcp-server
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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| execute_k6_testB | Execute a k6 load test. Args: script_file: Path to the k6 test script (.js) duration: Duration of the test (e.g., "30s", "1m", "5m") vus: Number of virtual users to simulate |
| execute_k6_test_with_optionsB | Execute a k6 load test with custom duration and VUs. Args: script_file: Path to the k6 test script (.js) duration: Duration of the test (e.g., "30s", "1m", "5m") vus: Number of virtual users to simulate |
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 2 tools
The two tools are essentially identical in purpose and functionality, both executing k6 load tests with the exact same parameters (script_file, duration, vus). The only difference is the tool name, which creates confusion rather than clarity. An agent would have no meaningful basis to choose between them.
Both tools follow a consistent snake_case pattern with 'execute_k6_test' as the base, which is readable. However, the second tool's name 'execute_k6_test_with_options' is redundant since the first tool already accepts options (duration and VUs), making the naming somewhat inconsistent in logic despite matching the format.
With only 2 tools, the server feels thin for a load testing domain, as it lacks operations like listing tests, getting results, or managing test configurations. The tools are redundant, so the effective count is even lower, failing to cover basic workflows beyond a single execution action.
The server is severely incomplete for k6 load testing, missing essential operations such as retrieving test results, monitoring test status, or managing test scripts. It only offers execution with no way to access outcomes, leaving agents unable to perform a full testing lifecycle.