Loading ToolBench
Model Context Protocol server for OpenShift / Kubernetes — projects, pods, logs, deployments, routes, builds and more, with username/password (local IdP) or token auth and safe-by-default access modes and guards.
Strong tool set with clear verb-noun naming and comprehensive parameter descriptions. All 10 tools have explicit schemas with type information and parameter constraints. Tool descriptions are clear and actionable, ranging 75-250 characters. Output schemas are documented in descriptions. Security-conscious error handling with policy/auth/cluster error classification in src/server.ts toErrorResult(). Elicitation pattern implemented (makeConfirmer for high-risk operations). However, output schema structures are not formally documented as JSON Schema, developers must infer them from descriptions and code. No batch/pagination parameters on list operations despite potentially large result sets. Error messages are context-aware but could include more recovery guidance for agent-specific scenarios.
Create or update a resource from a manifest (server-side apply). Gated by OPENSHIFT_ALLOW_APPLY=true and a human confirmation. The manifest must include apiVersion, kind, and metadata.name (and metadata.namespace for namespaced kinds). Honours OPENSHIFT_DRY_RUN (validates without persisting).
Delete a resource by kind + name (+ namespace). Not recoverable. Requires admin mode and OPENSHIFT_ALLOW_DELETE=true, refuses protected namespaces, and prompts for human confirmation. Honours OPENSHIFT_DRY_RUN.
Fetch a single resource by kind + name (+ namespace for namespaced kinds), with its full spec/status. Secret values are redacted.
List recent events in a namespace — the fastest way to see why something is failing to schedule/start.
List the projects (namespaces) you can see, with name, display name and phase. Start here to find a namespace to work in.
Output schemas not formally documented as JSON Schema objects. Developers must infer return structures from prose descriptions and implementation code. This violates pattern:tool-description requirement that 'Document the output schema. LLMs need to know what fields to expect…'
list_resources and list_events lack pagination parameters (limit already present, but no offset/cursor support documented). Large Kubernetes clusters may return hundreds of objects. Description states 'capped by OPENSHIFT_MAX_RESULTS' but cap value is not visible in schema or docs.
apply_resource accepts a bare 'manifest' object with no structural constraints (type: 'object' only). No JSON Schema for apiVersion/kind/metadata requirements. LLMs cannot validate the manifest shape before calling the tool.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
List resources of a kind, optionally in a namespace and filtered by a label selector. Returns the raw Kubernetes/OpenShift list (secret values are redacted). Works for core and OpenShift kinds (pods, deployments, deploymentconfigs, routes, services, builds, imagestreams, …).
Read a pod's container logs (most recent lines). Optionally a specific container or the previous instance.
Trigger a rolling restart of a Deployment (re-creates its pods). Reversible; pods come back on their own.
Set the replica count of a Deployment or DeploymentConfig. Scaling to 0 stops the workload, so that case asks for human confirmation.
Return the authenticated user (name and groups) — confirm which identity the server is using.
Error responses in toErrorResult() are descriptive but do not include recovery guidance for specific failure modes. E.g., 'RBAC may not permit it' is noted but no hint to 'ask cluster admin for role binding' or alternative tools.
scale tool description says 'asks for human confirmation' when scaling to 0 but does not document what the confirm response format is or what happens if user declines. Elicitation pattern is implemented but confirmation/rejection flow is not explained in tool description.
Tool descriptions mention risk levels (READ_ONLY, REVERSIBLE, WRITE, DESTRUCTIVE) but these are comments in the source, not visible in registered tool metadata. Tool annotations (toolAnnotations: true) are used but schema does not show what annotations (readOnlyHint, destructiveHint, etc.) are actually applied.