Loading ToolBench
Server has 31 tools with consistent naming (verb_noun pattern) and reasonable descriptions (avg ~120 chars). All tools have input schemas with type definitions and enum constraints where appropriate. However, parameter descriptions are sparse or missing context; output schemas are not documented; error handling lacks recovery guidance; and no tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Composition is sound (single responsibility per tool), but descriptions could be more LLM-optimized per pattern:tool-description baseline (target 50-200 chars).
Approves a pending DeckhouseRelease by patching its spec.approved field to true
Creates a new ModuleSource resource
Creates a new ModuleUpdatePolicy resource
Creates a new NodeGroup resource
Creates a new StaticInstance resource
Deletes a ModuleSource resource by name
Deletes a NodeGroup resource by name
Deletes a StaticInstance resource by name
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. Tools marked DESTRUCTIVE (DeleteNodeGroup, DeleteStaticInstance, DeleteModuleSource) and WRITE (EnableModule, DisableModule, etc.) lack machine-readable hints for agent safety.
Output schemas not documented. Tool descriptions state what is returned (e.g., 'Returns comprehensive cluster status') but do not specify the response structure, field names, or types. LLMs cannot plan downstream tool calls without knowing available fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
Disables a module by setting spec.enabled=false on its ModuleConfig resource
Enables a module by setting spec.enabled=true on its ModuleConfig resource
Reads the ClusterConfiguration YAML from the d8-cluster-configuration Secret in kube-system namespace
Returns comprehensive cluster status including node summary, node group statuses, errored modules, pending releases, unhealthy pods count, and Deckhouse version
Retrieves a specific DeckhouseRelease resource by name
Returns detailed configuration for a specific module including name, enabled status, version, settings, and status message
Retrieves a specific NodeGroup resource by name
Reads the StaticClusterConfiguration YAML from the d8-cluster-configuration Secret in kube-system namespace (key: static-cluster-configuration.yaml)
Retrieves a specific StaticInstance resource by name
Lists all DeckhouseRelease resources with optional filtering by status
Lists module configurations with optional filtering by enabled status
Lists all ModuleSource resources
Lists all ModuleUpdatePolicy resources
Returns all Deckhouse Module runtime resources with their name, weight, source, and state
Lists all NodeGroup resources from Deckhouse API
Lists all node groups with their status, ready count, total count, up-to-date count, conditions, and any errors
Lists nodes with optional filtering by node group, status (Ready/NotReady), or role
Lists static instances with optional filtering by node group or phase (Pending, Bootstrapping, Running, Cleaning, Error)
Lists all StaticInstance resources from Deckhouse API
Lists unhealthy pods (not Running or Succeeded) with optional namespace filter and option to exclude completed pods
Toggles ModuleConfig.spec.maintenance using JSON merge patch. When enabled=true, sets spec.maintenance='NoResourceReconciliation' (pauses enable/disable transitions). When enabled=false, removes the field. Idempotent operation
Patches the kubernetesVersion field inside the ClusterConfiguration YAML stored in d8-cluster-configuration Secret. Uses read-modify-write with up to 3 retries on conflict. YAML round-trip preserves all other fields verbatim
Performs a deep merge (RFC 7396 JSON Merge Patch semantics) of supplied settings into the ModuleConfig's spec.settings. Explicit nil values delete keys; nested maps are merged recursively; other values replace entirely
Parameter descriptions are minimal or missing context. Many parameters (e.g., 'nodeGroup', 'phase', 'enabled') lack guidance on expected format, valid ranges, or when to use them. Descriptions should explain WHAT the parameter controls and WHEN to use it.
No error handling guidance. Tool descriptions do not explain what errors can occur, how to recover, or what the LLM should do next. E.g., 'Module not found' should suggest 'Call ListModuleConfigs() to see available modules.'
Duplicate tool names across handlers. ListNodeGroups and ListStaticInstances appear in both diagnostics.go and nodes.go. This creates ambiguity for LLMs and violates single-responsibility principle. Consolidate or rename to distinguish (e.g., ListNodeGroupsSummary vs ListNodeGroupsDetailed).