Loading ToolBench
MCP server for Cyclops UI that provides tools to manage Kubernetes modules, templates, and template stores through the Model Context Protocol
Cyclops MCP server has good naming conventions and mostly well-defined tool schemas, but suffers from several definition quality gaps. All 9 tools follow verb-noun naming (get_, list_, create_, update_) which is correct. Tool descriptions are present but vary in quality and depth. Parameter schemas are well-typed with enums where appropriate (template_type, template store types). However, output schemas are not documented, critical for LLM planning. Descriptions lack prerequisite guidance and next-step hints. Error handling documentation is absent. Security considerations around Kubernetes access and cluster credentials are not addressed in tool definitions.
Create new Module. Before calling this tool, make sure to call get_template_schema to validate values for the given template
Create a Module manifest based on values. Before calling this tool, make sure to call get_template_schema to validate values for the given template
Fetch Module by Name
Returns JSON schema for the given template. Needs to be checked before calling create_module tool
Fetch Template Store by Name
Lists all Kubernetes resources owned by the given Module
List All Cyclops Modules
Output schemas are not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., module_id, resource_ids) without explicit return type documentation.
Tool descriptions lack prerequisite guidance and error recovery instructions. E.g., create_module says 'Before calling this tool, make sure to call get_template_schema' but does not explain what error the LLM will face if it skips this step, or how to recover.
No error handling documentation. Tools do not indicate what errors are retryable, user-fixable, or fatal. No guidance for LLM recovery paths (e.g., if create_module fails with 'template not found', should the agent call list_template_store?).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 56 | - | v1 |
List Template Stores from cluster
Update Module by Name
No documentation of pagination or result limits. list_modules, list_module_resources, and list_template_store do not specify max results, pagination parameters, or how to handle large datasets. This violates LLM context-window best practices.
Security: No permission or scope documentation. Tools interact with Kubernetes cluster resources, which have access control implications, but no tool describes what permissions/roles are required or how to audit calls.
Parameter descriptions for 'values' (JSON string format) lack format guidance. LLMs often struggle with JSON string parameters, descriptions should clarify: 'Valid YAML/JSON format, must be stringified. Example: {"replicas": 3}'.
Ambiguous tool purpose distinction: create_module and create_module_manifest are similar. The description says create_module_manifest 'Create a Module manifest' but does not explain when to use it vs create_module. LLMs will conflate them.