Loading ToolBench
MCP server for KEDA (Kubernetes Event-Driven Autoscaling) with Cluster Autoscaler integration and webhook support for graceful termination
The KEDA MCP server has serious gaps in definition quality. While 12 tools are registered with input schemas visible in server.go, the definitions suffer from: (1) Missing or incomplete parameter descriptions across most tools; (2) No documented output schemas, forcing LLMs to guess what fields they'll receive; (3) Generic, short descriptions that don't provide actionable selection guidance; (4) No error handling guidance or recovery patterns; (5) Missing parameter type constraints and validation rules. The schema definitions in the code are present but basic. Per-tool scores range from 28 - 58, averaging 42. This is below the C-grade threshold and typical of early-stage community servers.
Install Cluster Autoscaler for automatic node scaling
Scale node group (adjust min/max/desired capacity)
Check Cluster Autoscaler status and node group information
Apply zero scaling to a deployment (scales to 0 when no traffic)
Install KEDA core and HTTP Add-on components
Remove zero scaling from deployment and restore original service routing
Check KEDA installation status and component health
No output schemas documented. LLMs cannot predict what fields they will receive from any tool (e.g., what does keda_status return? Is it status string, structured object with nested fields, list?). This violates the pattern:tool requirement and forces LLMs to operate blindly.
Parameter descriptions are generic or missing detail. E.g., 'kubernetesVersion' is described as 'Kubernetes version for compatibility (optional)' but doesn't specify: format (v1.29.0?), range, constraints, or how it affects behavior. 'cloudProvider' is 'Cloud provider (aws, azure, gcp, generic)' with an enum constraint visible in schema but not explained in text. LLMs need actionable constraints in descriptions, not just in JSON Schema.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 28 | - | v1 |
Check status of test deployment, service and pods
Clean up all test resources (deployments, services, pods)
Create a test nginx deployment for KEDA testing
Create a test service for deployment
Simulate HTTP traffic to test service
No error handling or recovery guidance. Tools like test_cleanup and keda_remove are destructive, but descriptions don't state what happens on partial failure, if the operation is idempotent, or what the LLM should do if it fails. No guidance on retryability or next steps.
Missing or incomplete state-change declarations. Tools like keda_apply, keda_remove, test_create_* are writes but descriptions don't explicitly state 'This modifies your cluster'. Agents need clear signal of which calls have side effects vs. read-only.
No parameter validation rules or constraints stated in descriptions. E.g., replicas field for test_create_deployment has a default but no min/max bounds documented. requestCount for test_simulate_traffic defaults to 10 but no range given, can an LLM pass 1000000? Should it? NodeGroup names have no format spec.
Tool descriptions are below the 100-char baseline for LLM selection. Examples: 'Check KEDA installation status and component health' (54 chars), 'Check Cluster Autoscaler status and node group information' (59 chars). These lack context on WHEN to call the tool vs a similar tool, what it returns, or dependencies. Baseline is 194 chars (median); these are <40% of that.
Parameter descriptions contain no guidance on format or accepted values. E.g., namespace parameter appears in 11 tools but is only described as 'Kubernetes namespace', is this the namespace name or UID? Examples in the codebase (e.g., 'default', 'keda') suggest name, but not stated. deploymentName is similarly vague.
No documentation of tool dependencies or prerequisites. E.g., does keda_apply require keda_install to have succeeded first? Can test_simulate_traffic run without test_create_service having been called? These workflows are implied but not documented, forcing LLMs to guess ordering.