Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Komodo MCP demonstrates solid tool definition quality overall with comprehensive schema coverage and consistent parameter typing. 37 tools covering Docker/Komodo container management. Strengths: all tools have clear descriptions (avg ~100 chars), all parameters include type definitions and descriptions, input schemas are complete and well-structured. Notable gaps: descriptions are somewhat terse (below ideal 150-200 char range); some tools lack output schema documentation; error handling guidance is minimal; no idempotent/destructive operation hints in tool definitions despite having risk markers in metadata; composition could be tighter (some tools overlap in intent, e.g., stop_stack vs stop_container). Naming is consistently verb-noun and unambiguous. Parameter naming follows conventions (server, container, stack patterns). No required parameters expose secrets. Risk classification (READ_ONLY, WRITE, DESTRUCTIVE) is metadata-only and not reflected in schema annotations.
Descriptions are consistently terse (60-100 chars), below optimal 150-200 char range for LLM tool selection. While descriptions exist, they lack sufficient context on WHEN to use each tool and what distinguishes it from similar tools (e.g., komodo_stop_stack vs komodo_stop_container lack differentiation guidance).
Tool risk annotations (WRITE, DESTRUCTIVE) exist in metadata but are not reflected in schema via toolAnnotations (idempotentHint, destructiveHint, readOnlyHint). This prevents clients from applying special handling (confirmation, dry-run) for dangerous operations.
Expand all tool descriptions to 150-200 characters. Include WHAT the tool does, WHEN to use it (vs similar tools), and expected return type. Example: 'komodo_stop_stack: Gracefully stop all containers in a running stack (preserves state). Use this instead of delete_stack if you plan to restart later. Returns updated stack status.' Current: 'Stop a running stack (keeps containers, just stops them)'.
Add toolAnnotations to schema definitions for destructive/write operations. Reference: @modelcontextprotocol/sdk tool registration API supports destructiveHint, idempotentHint, readOnlyHint. Example: komodo_delete_stack should have destructiveHint=true so clients can gate it behind confirmation or dry-run.
Document output schemas in tool descriptions or as separate schema definitions. For get_stack: 'Returns: {stack_id, name, status, services[], containers[], created_at, updated_at}'. For list_stacks: 'Returns: {stacks: [{id, name, status, service_count}], total_count}'. Include field types and descriptions.
Add error recovery hints to tool descriptions. Example: komodo_get_stack description should include: 'If stack not found, call komodo_list_stacks to discover available stacks.' Similar hints for get_container_log, get_stack_log, etc.
Implement pagination for list_* tools. Add limit (default 20, max 100) and offset/cursor parameters. Document in description: 'Returns max 20 stacks per call. Use offset parameter to retrieve additional pages.' Return a total_count field so agents know when to stop paginating.
Spec posture evidence
Inferred effective spec: 2025-06-18+.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 30 points across a rubric change (v1 → v2)
84/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
A
84
2025-06-18+
v2
2026-03-09
D
54
-
v1
Delete a stack (removes all associated containers)
komodo_delete_volumedestructiveauth50/100
Delete a Docker volume from a server
komodo_deploy_stackwriteauthsource verified87/100
Deploy or redeploy a stack (pulls images and starts containers)
Output schemas are not documented for any tools. Descriptions do not specify what fields are returned, data types, or structure. This forces LLMs to infer response structure and makes chaining tools (e.g., get_stack → deploy_stack) error-prone.
No error handling guidance in any tool descriptions. When a tool fails (e.g., 'stack not found'), LLMs have no guidance on next steps (retry? search? ask user?). Descriptions lack actionable recovery hints like 'If not found, call komodo_list_stacks to discover available stacks'.
Configuration update tools (komodo_update_config, komodo_update_stack_config) accept a generic 'config' object parameter without specifying which keys are valid, constraints on values, or warnings about secret-like keys. Description says 'must not contain secret-like keys' but provides no examples of what 'secret-like' means or how to validate.
List tools (list_stacks, list_servers, list_containers, list_images, list_networks, list_volumes) do not expose pagination parameters (limit, offset/cursor). Large result sets will exceed context windows. Descriptions do not document result limits or pagination behavior.
Destructive operations (delete_stack, delete_container, delete_image, delete_network, delete_volume, prune_system) lack confirmation/dry-run support. No tool descriptions mention confirmation steps or undo mechanisms. An LLM could irreversibly delete resources without user approval.
Add confirmation workflow for destructive operations. Either: (a) add a dry_run parameter to delete_* tools, or (b) create separate preview/confirm tools (preview_deletion, confirm_deletion). Document in descriptions: 'This operation is irreversible. Call komodo_preview_delete_stack first to review what would be deleted.'
Clarify config parameter constraints for komodo_update_config and komodo_update_stack_config. Enumerate valid keys, provide schema for config object, or add examples: 'config must be {retry_policy?, timeout_seconds?, environment?: {key: value}}, do not include passwords or API keys; use server-side secret management.'
Add dependency hints to tool descriptions. Example: komodo_deploy_stack should say 'Ensure the Docker image is available on the target server; use komodo_pull_image if needed.' This prevents LLM from attempting invalid sequences.
For log retrieval tools (get_stack_log, get_container_log, search_logs), document log format and timestamp handling. Example: 'Returns: {lines: [string], count, truncated: bool}. Timestamps are ISO 8601 if timestamps=true; include clarification on log line limits and when truncation occurs.'
Add natural-language identifier support where applicable. komodo_get_stack description: 'Accepts stack name or ID. If you only have a partial name, call komodo_list_stacks and pass the full name or UUID.' This reduces unnecessary lookup round-trips.