Loading ToolBench
MCP server for Flux Operator that provides tools to manage and query Flux CD configurations, Kubernetes resources, and documentation
The Flux Operator MCP server exhibits significant quality issues across all definition dimensions. Tool definitions lack comprehensive parameter schemas, descriptions are minimal or absent, and critical metadata for LLM selection is missing. Of the 10 tools, only 1 (docs-search) shows any visible parameter schema in the provided source code. The remaining 9 tools have descriptions that are present but generic (10-50 characters, well below the 50-200 character baseline for LLM-optimized descriptions). No input/output schemas are documented in the source code provided. Tool names follow verb_noun convention (positive), but parameter validation, error handling guidance, and idempotent operation semantics are not visible. The server does not implement tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite having tools with clearly distinct risk profiles (READ_ONLY, WRITE, DESTRUCTIVE). Security tools (k8s-delete-resource) lack confirmation or dry-run support. Composition is reasonable (each tool has one responsibility), but output field naming consistency and pagination support are not evident from the source.
Search the Flux Operator documentation index
Describe a specific Flux CD resource
List Flux CD resources in the cluster
Trigger manual reconciliation of a Flux resource
Resume a suspended Flux resource
Suspend a Flux resource
Apply a Kubernetes resource
Delete a Kubernetes resource
Get a Kubernetes resource
Critical: Input schemas missing for 9 of 10 tools. Only docs-search shows any parameter schema (query: string). Remaining tools (flux-list-resources, flux-describe-resource, flux-reconcile, flux-suspend, flux-resume, k8s-get-resource, k8s-list-resources, k8s-apply-resource, k8s-delete-resource) have no visible input schema in source code. Per hard scoring rule, schema score MUST be 0 for tools with no input schema.
Critical: Descriptions are extremely sparse (10-50 characters). Examples: 'List Flux CD resources in the cluster' (39 chars), 'Describe a specific Flux CD resource' (35 chars), 'Trigger manual reconciliation of a Flux resource' (48 chars). These fall far below the 50-200 character baseline for LLM-optimized descriptions and do not explain WHEN to use each tool, dependencies, or expected outcomes. LLMs cannot distinguish flux-list-resources from k8s-list-resources based on these descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
List Kubernetes resources
High: No parameter descriptions visible for 9 of 10 tools. docs-search provides a parameter description ('Search query string') but the remaining tools show no parameter metadata in the source. LLMs cannot determine what parameters to pass or how to construct them. For example, flux-reconcile, flux-suspend, flux-resume, k8s-get-resource, k8s-delete-resource likely require a resource name/ID, but this is not documented.
High: No output schemas or return value documentation visible. LLMs cannot plan downstream tool calls (e.g., does flux-list-resources return resource IDs that flux-describe-resource accepts?). Response field naming consistency is unknown. Pagination support is not documented, risking context window overflow if tools return large result sets.
High: No tool annotations (readOnlyHint, destructiveHint, idempotentHint) implemented despite tools having explicitly documented risk levels (READ_ONLY, WRITE, DESTRUCTIVE). Agents cannot determine which tools are safe to retry. DESTRUCTIVE tools like k8s-delete-resource lack confirmation or dry-run support, violating the confirmation-request pattern.
High: No error handling guidance visible. Tools like k8s-delete-resource and k8s-apply-resource operate on critical infrastructure but provide no recovery hints, error classification (retryable/user-fixable/fatal), or actionable error messages. An LLM encountering an API error has no guidance on what to attempt next.
Medium: Parameter naming for resource identifiers is inconsistent and undocumented. Tools like flux-describe-resource, k8s-get-resource, and k8s-delete-resource almost certainly require a resource name or ID, but whether they accept names, IDs, both, or something else is not documented. The rubric requires suffixing identifier parameters with type (e.g., resource_id, resource_name).
Medium: Tool composition relies on assumptions about output field naming and IDs. If flux-list-resources returns 'resource_id' but flux-describe-resource expects 'id', the chain breaks. The rubric requires response field naming to match downstream parameter names (mxe:response-field-naming). No documentation of this contract is visible.