Loading ToolBench
komodo-mcp exposes 5 tools with complete JSON schemas and descriptions. Naming follows verb_noun convention (komodo_discover, komodo_read, komodo_write, komodo_execute, komodo_terminal). Descriptions are present and substantive (80-200 chars), explaining WHAT each tool does and noting destructiveness. However, parameter descriptions are minimal or absent for several fields (e.g., 'params' in komodo_read/write/execute lacks detail on expected structure), and output schemas are not documented. Error handling is present (normalizeKomodoError, failure() function) but lacks recovery guidance. Tool composition is reasonable, discover enables inspection before mutation, but the generic 'params' object across multiple tools reduces clarity about valid parameter structures.
Discover every native read, write, and execute operation supported by the installed Komodo client. Pass an exact operation name to retrieve its parameter documentation before calling it.
Call any native Komodo execution, including deploy, build, pull, lifecycle, backup, restore, prune, and destroy operations. Some choices are destructive. Set wait=true to return completed updates and logs.
Call any native Komodo read operation. Use komodo_discover with the exact operation name first when its parameters are not already known.
Run a command through native Komodo terminals on a server, container, Stack service, or Deployment. This is unrestricted remote command execution and may be destructive.
Call any native Komodo write operation, including create, update, rename, permission, variable, secret, and delete operations. Some choices are destructive.
Generic 'params' parameter lacks structure documentation. komodo_read, komodo_write, and komodo_execute all accept a 'params' object with no schema, type constraints, or description of expected keys. LLMs cannot infer valid parameter names or types without explicit documentation.
Output schemas not documented. Tool descriptions do not specify what fields are returned or their types. LLMs cannot plan downstream tool calls or extract required data without knowing response structure.
Error handling lacks recovery guidance. normalizeKomodoError() exists but error responses do not suggest next steps (e.g., 'Try komodo_discover first' or 'Check operation name'). Agents receive errors with no actionable path forward.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2025-06-18+ | v2 |
komodo_terminal accepts unrestricted command execution with minimal constraints. While 'max_output_bytes' is bounded, there is no dry-run mode, confirmation step, or audit logging visible in the code. Destructive operations should support confirmation patterns.
Parameter descriptions for 'target' in komodo_terminal are verbose but lack clarity on which target type is appropriate for different use cases. No guidance on when to use 'server' vs 'container' vs 'stack' vs 'deployment'.