Loading ToolBench
MCP server for managing RHOAI (Red Hat OpenShift AI) workbenches, hardware profiles, custom images, PVCs, pods, and resource consumption monitoring on Kubernetes clusters
The server exposes 18 tools with reasonable structure and documented input schemas. Naming follows verb_noun conventions consistently (ListHardwareProfiles, CreateHardwareProfile, etc.). Descriptions are present for all tools and range from 30 - 70 characters, meeting the 10 - 1024 character guideline. However, descriptions are terse and lack WHEN-to-use context. Parameter descriptions are minimal, many array/object parameters lack granular field descriptions (e.g., 'Array of hardware profile resources' with no explanation of what each field does). Output schemas are not explicitly documented; only inputs are visible. Error handling guidance is absent, no recovery suggestions or error categorization. Tool composition is reasonable (each tool has a single responsibility), but responses lack pagination, field chaining IDs, and token cost optimization. Security posture is weak: no permission gates documented, no audit trail hints, and no evidence of input sanitization guidance.
Creates a custom notebook image from a Docker image location
Creates a new hardware profile with specified resources
Creates a new persistent volume claim in a namespace
Deletes a hardware profile by name
Deletes a custom notebook image if it is not a default image and not in use
Deletes a persistent volume claim
Lists all hardware profiles available in the cluster
Lists all available notebook images in the cluster
Descriptions are terse and omit WHEN-to-use guidance. 'Lists all hardware profiles available in the cluster' lacks context for LLM tool selection (e.g., 'Call before creating a workbench to check available hardware options').
Nested object/array parameters lack field-level descriptions. CreateHardwareProfile accepts 'Resources' array with complex nested objects (ResourceName, ResourceIdentifier, ResourceType, DefaultCount, MaxCount, MinCount), but no explanation of what each field controls or valid ranges.
Output schemas not explicitly documented. Source code shows function signatures return structured types (e.g., core.ListHardwareProfilesOutput), but the MCP tool definition does not document what fields or structure the response contains. LLMs cannot plan downstream calls without knowing the output shape.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Lists all namespaces in the Kubernetes cluster
Lists persistent volume claims in a specified namespace
Lists all pods in a specified namespace
Aggregates total resource consumption metrics for all workbenches in the entire cluster
Aggregates resource consumption metrics for all workbenches in a namespace
Aggregates resource consumption metrics for all workbenches owned by a specific user
Gets resource consumption metrics for a specific workbench
Updates an existing hardware profile with new name and/or resources
Updates an existing image name and/or description
Updates a persistent volume claim size and/or name, with validation that size can only increase
No error handling guidance. Tools offer no recovery suggestions (e.g., 'If hardware profile not found, call ListHardwareProfiles to see available options'). LLMs cannot self-correct without actionable error messages.
No pagination support declared. List tools (ListHardwareProfiles, ListImages, ListPods, ListPVCs) do not specify limit, offset, or cursor parameters. No total_count returned. Large result sets risk context window exhaustion.
No permission gates or scope declarations. Tools like DeleteHardwareProfile and DeletePVC are destructive but show no evidence of permission checks or scope metadata (e.g., 'requires:delete:kubernetes-resources'). Audit trails absent.
No confirmation or dry-run support for destructive operations. DeleteHardwareProfile, DeleteImage, and DeletePVC offer no confirmation step or dry-run mode. Agents cannot safely plan before executing irreversible actions.
Parameter validation constraints not documented. Size parameter in CreatePVC ('e.g., 10Gi') is described generically; no regex pattern, examples of valid formats (Gi, Mi, Ki), or min/max constraints stated. Similarly, ResourceType, ResourceIdentifier lack enums or constraints.
No response field chaining documented. If ListResourceConsumptionPerWorkbench is called, what IDs does it return to enable follow-up operations like UpdatePVC? Output shape unknown.