Loading ToolBench
MCP server for Kubernetes cluster management, providing tools to extract, analyze, and apply Kubernetes resource configurations in YAML format
AgentK-Server provides 5 Kubernetes-focused tools with reasonable descriptions and basic parameter schemas. However, there are significant gaps: parameter descriptions lack validation constraints and format specifications, output schemas are not documented, error handling is minimal, and there is no demonstrated per-tool error recovery guidance. Tool naming is action-verb-based and clear, which is a strength. Parameter enums are present for resource types, but descriptions do not specify constraints like minimum/maximum lengths, format requirements, or mutually exclusive relationships. The server implements HTTP transport with FastMCP, which is current-spec compliant. Overall, the server is functional but falls short of production-grade quality, most tools lack the detail needed for reliable agent decision-making and error recovery.
Aplica um recurso Kubernetes no cluster a partir de um conteúdo YAML fornecido. Esta função permite criar ou atualizar recursos no cluster Kubernetes utilizando definições em formato YAML. Suporta múltiplos recursos separados por '---'.
Remove um recurso específico do cluster Kubernetes
Extrai todos os YAMLs dos recursos especificados de todos os namespaces do cluster. Esta função obtém TODOS os recursos dos tipos especificados em TODOS os namespaces do cluster e retorna suas definições completas em formato YAML. É útil para backup completo, análise de configurações ou migração entre clusters.
Lista os nomes dos recursos Kubernetes disponíveis no cluster por tipo. Esta função retorna apenas os nomes dos recursos organizados por tipo. Por exemplo: {"pods": ["pod-1", "pod-2"], "services": ["service-1"]}
Obtém a configuração YAML de um recurso específico do Kubernetes por tipo e nome. Esta função permite extrair a definição completa em YAML de um recurso específico do cluster Kubernetes, útil para análise, backup ou replicação de configurações.
Missing output schemas for all tools, LLMs cannot plan downstream calls or extract chaining IDs (team_id, channel_id, message_id equivalents). This forces agents to guess output structure and wastes context on unstructured responses.
Destructive operation (deletar_recurso_kubernetes) lacks confirmation workflow. No dry-run option, no reversibility guidance, no permission checks visible. Agents can permanently delete cluster resources without safeguards.
Parameter descriptions lack validation constraints. E.g., yaml_content has no length limits, resource_type lacks enum documentation in some tools, namespace lacks clarity on when it applies. LLMs cannot infer valid input formats.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 30 | - | v1 |
No error recovery guidance in tool descriptions. E.g., what happens if a namespace does not exist? If a resource type is invalid? If YAML is malformed? No actionable recovery hints provided to LLMs.
Large result risks not addressed. extrair_yamls_todos_recursos_cluster retrieves ALL resources across ALL namespaces without pagination, limit, or streaming. Large clusters could return megabytes of YAML, exhausting context windows and delaying agent response.
deletar_recurso_kubernetes description is critically short (45 chars, near hard-rule threshold). No mention of irreversibility, side effects, or required permissions. Does not meet production standards for DESTRUCTIVE operations.
Parameter dependencies not documented. E.g., namespace is 'not applicable' for cluster-wide resources, but the schema does not enforce this, an LLM could pass namespace for a nodes query and be confused by the result. Conditional parameter logic should be explicit.