Loading ToolBench
MCP server for DevOps operations including Docker, Helm, Ansible, Jenkins, and Terraform
Server has 6 tools with schemas visible in source code. All tools have basic descriptions (10-79 chars) and input parameter definitions using Zod. However, descriptions are uniformly short and lack LLM-friendly context about WHEN to use each tool, what prerequisites exist, and how tools chain together. Parameter descriptions are minimal. Output schemas are not documented, tools return JSON but the structure is not formally specified. No error recovery guidance. Risk levels are declared but no tool annotations (readOnlyHint/destructiveHint) are present in the code. Naming follows verb_noun pattern, which is good, but overall definition quality falls into the 'Fair/C' range due to thin descriptions and missing output schema documentation.
Execute an Ansible playbook with optional inventory and extra variables
Build a Docker image from a Dockerfile in the specified context directory
List Docker containers with optional filtering by status
List Helm releases across namespaces with optional filtering
Trigger a Jenkins build job with optional parameters and wait for queue info
Run terraform plan and return a structured summary of changes
Output schemas not documented. Tools return JSON via text content type, but the exact structure (fields, types, nesting) is not declared or described. LLMs cannot plan downstream tool calls or extract required fields without trial-and-error.
Descriptions are between 34 - 79 characters, below the 50 - 200 char baseline for LLM optimization. Descriptions lack WHEN to use, prerequisites, and chaining hints. For example, 'Execute an Ansible playbook with optional inventory and extra variables' says WHAT but not WHEN or HOW it relates to other tools.
No tool annotations present in code. Risk levels (READ_ONLY, WRITE) are declared in metadata but not exported to the MCP protocol. readOnlyHint and destructiveHint annotations (current spec pattern) are missing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Error responses lack recovery guidance. ansible_run_playbook and docker_build return 'Error: <reason>' but do not suggest next steps. Per pattern:recovery-guide, errors should guide the agent: 'Playbook not found at X. Check the path or call list_ansible_playbooks() to discover available playbooks.'
No pagination support in list tools. docker_list_containers and helm_list_releases may return unbounded results. No limit, offset, or page_size parameters. Per pattern:paginated-result, list tools should accept limit and offset/cursor, and return a total count or next_cursor.
Parameter descriptions are minimal (1 - 2 sentences). E.g., 'Kubernetes context to use' for kubeContext does not explain format, constraints, or how to discover valid contexts. Per review:param-validation-rules, descriptions should state expected format, range, and allowed values.
No dry-run or confirmation step for destructive operations. docker_build, ansible_run_playbook, and jenkins_trigger_build can modify or trigger external systems but lack a check_mode or dry_run pattern (except ansible has checkMode). Per pattern:confirmation-request, irreversible operations should support confirmation.
Credentials passed as tool parameters. jenkins_trigger_build accepts 'token' and 'username' as parameters. Per pattern:secret-injection, credentials must never be tool parameters, use server-side secret injection via environment variables or vault. Agent traces log all parameters; secrets in params leak into logs.