Loading ToolBench
MCP server for running k6 load testing scripts, validating scripts, browsing k6 documentation, and searching Terraform resources
The k6 MCP server has 6 tools with basic documentation but significant quality gaps. All tools have descriptions and simple input schemas, but lack the rigor expected of production-grade tools. Descriptions are generic and often vague (e.g., 'Run a k6 script' without stating what 'run' means or what output to expect). No output schemas are documented, callers cannot know what to expect from responses. Parameters lack detailed type constraints, ranges, or format specifications. Error handling guidance is absent. The schema definition for run_script shows only 'script' and 'iterations' parameters, but the description mentions 'optional parameters like iterations and virtual users', unclear which other parameters are supported or required. No tool declares whether operations are idempotent, retryable, or destructive in a structured way (no toolAnnotations). The server exposes a low-risk tool surface (mostly read-only; run_script is the only write operation), but lacks the composition patterns and chaining support (response IDs, follow-up references) that agents need for multi-step workflows.
Get the documentation content for a specific slug from the k6 documentation
Get information about the k6 installation including version, k6_version, and login status
List all documentation sections from the k6 documentation with optional version filtering
Run a k6 script with optional parameters like iterations and virtual users
Search for k6 Cloud-related Terraform resources in the Grafana Terraform provider
Validate a k6 script for syntax errors and issues
run_script description is vague and incomplete. It says 'Run a k6 script with optional parameters like iterations and virtual users' but only shows 'script' and 'iterations' in the schema. Does 'virtual users' (vus) map to a parameter? What are the full list of parameters? What does the output contain, metrics, logs, summary? The description does not state what happens when the script runs, does it block? Stream results? Return a summary? This ambiguity prevents LLMs from planning properly and causes incorrect parameter passing.
No output schemas documented for any tool. Callers have no way to know what structure they receive. For example, info tool returns JSON with 'version', 'k6_version', 'logged_in' (visible in e2e test), but this is not declared in tool metadata. list_sections returns 'tree', 'count', 'version', 'available_versions', inferred from tests, not documented. Without schema declarations, agents cannot plan downstream tool calls or extract required fields for composition.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Missing parameter details for run_script. The description mentions 'optional parameters like iterations and virtual users' but only 'script' and 'iterations' appear in the schema. No mention of vus, duration, rps, timeout, or other k6 execution flags. If vus is not a parameter, the description is misleading. If it is, the schema is incomplete. Either way, the tool definition is inconsistent with the description.
Descriptions lack guidance on WHEN to use each tool and WHAT to expect. For example, validate_script says 'Validate a k6 script for syntax errors and issues', what kind of issues? What does 'issues' mean (performance warnings, deprecated APIs, style issues)? Should agents call this before run_script? Does it modify any state? The description does not answer these questions, forcing LLMs to guess.
No error handling guidance. If run_script fails (syntax error, resource timeout, assertion failure), what should the agent do? Should it retry? Call validate_script first? Try a different input? No error responses are documented. If search_terraform finds nothing, should the agent fall back to get_documentation? These recovery paths are left to chance.
No tool annotations (destructiveHint, idempotentHint, readOnlyHint). run_script modifies state (executes code, consumes resources), this should be marked destructive and non-idempotent. info and get_documentation are read-only, should be marked as such. Without annotations, agents cannot reason about safety, retry strategies, or cost implications.
Parameter descriptions are minimal or absent. 'script' parameter in validate_script and run_script just says 'The k6 script content to validate/execute', no mention of size limits, encoding, expected format (JS module, JSON config), or what happens if the script is invalid. 'term' parameter in search_terraform just says 'Search term for Terraform resources', what fields are searched? Is it regex or literal? Case-sensitive? These gaps force LLMs to make assumptions.
list_sections and get_documentation descriptions do not explain the relationship between them. Should agents call list_sections first to discover available slugs before calling get_documentation? What happens if you call get_documentation with an invalid slug? The composition path is unclear.