Which integrations are available for this server?

Allows interaction with Helm, providing tools to list Helm releases in clusters. Allows interaction with Kubernetes clusters, providing tools to list pods, services, namespaces, get cluster info, and analyze component versions.

How do I use Kubernetes MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Kubernetes MCP Server list all pods in the default namespace" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Kubernetes MCP Server

by Portfolio-jaime

Overview Schema Source Related Servers Discussions Admin

Local

🚀 Kubernetes MCP Server

License: MIT TypeScript Node.js Kubernetes MCP

Un servidor MCP (Model Context Protocol) que permite a Claude Desktop interactuar directamente con clusters de Kubernetes usando kubectl y helm. Proporciona herramientas para consultar pods, servicios, releases de Helm, analizar versiones y más.

✨ Características

🔌 Integración directa con Claude Desktop via MCP
🎯 6 herramientas especializadas para Kubernetes
🔒 Servidor HTTPS con certificados auto-generados
🐳 DevContainer completo con todas las herramientas
📊 Análisis de versiones y componentes desactualizados
🛠️ Soporte para múltiples clusters (minikube, EKS, GKE, etc.)

Related MCP server: K8s MCP Server

🛠️ Herramientas Disponibles

Herramienta	Descripción	Parámetros
`get_pods`	Lista pods del cluster	`namespace` (opcional)
`get_services`	Lista servicios	`namespace` (opcional)
`get_helm_releases`	Lista releases de Helm	`namespace` (opcional)
`get_cluster_info`	Información general del cluster	-
`get_namespaces`	Lista todos los namespaces	-
`analyze_versions`	Analiza versiones de componentes	`namespace`, `component` (opcionales)

🚀 Inicio Rápido

Prerrequisitos

Node.js 18+
Docker Desktop
VS Code con extensión Dev Containers
Acceso a un cluster Kubernetes

1. Clonar el Repositorio

git clone https://github.com/tu-usuario/k8s-mcp-server.git
cd k8s-mcp-server

2. Abrir en DevContainer

# En VS Code: Cmd+Shift+P → "Dev Containers: Reopen in Container"

3. Construir el Proyecto

npm install
npm run build

4. Configurar Claude Desktop

Crear archivo ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "k8s-versions": {
      "command": "node",
      "args": ["/ruta/al/proyecto/dist/index.js"],
      "env": {
        "KUBECONFIG": "/Users/tu-usuario/.kube/config"
      }
    }
  }
}

5. Reiniciar Claude Desktop

# Cerrar Claude Desktop completamente y volver a abrir

📖 Documentación

📚 Guías Principales

Guía Rápida - Empezar en 5 minutos
Setup HTTPS - Configuración completa con servidor HTTPS
Configuración - Opciones avanzadas
API Reference - Documentación técnica completa

🎯 Ejemplos de Uso

Ejemplos Prácticos - Casos de uso reales

🏗️ Arquitectura

graph LR
    A[Claude Desktop] -->|MCP Protocol| B[MCP Server]
    B -->|kubectl| C[Kubernetes API]
    B -->|helm| D[Helm Charts]
    C --> E[Pods/Services/etc]
    D --> F[Releases]

🧪 Desarrollo

Scripts Disponibles

# Desarrollo
npm run dev              # Modo desarrollo con watch
npm run build           # Construir proyecto
npm run start           # Iniciar servidor MCP (stdio)

# Servidores HTTP/HTTPS
npm run start:http      # Servidor HTTP (puerto 3002)
npm run start:https     # Servidor HTTPS (puerto 3002)

# Testing
npm test               # Ejecutar tests
npm run test:coverage  # Tests con coverage
./scripts/test-mcp-https.sh  # Test completo del servidor HTTPS

# Calidad de código
npm run lint           # Linter
npm run type-check     # Verificación de tipos
npm run validate       # Lint + tipos + tests

Estructura del Proyecto

📁 k8s-mcp-server/
├── 📁 src/                 # Código fuente TypeScript
│   ├── index.ts           # Servidor MCP principal (stdio)
│   ├── https-server.ts    # Servidor HTTPS para desarrollo
│   └── 📁 services/       # Servicios de Kubernetes y Helm
├── 📁 scripts/            # Scripts de utilidad
├── 📁 docs/              # Documentación completa
├── 📁 .devcontainer/     # Configuración DevContainer
└── 📁 dist/              # Código compilado

🎮 Ejemplos de Uso en Claude Desktop

Una vez configurado, puedes hacer preguntas como:

¿Qué pods tengo corriendo en mi cluster?

Muéstrame los releases de Helm instalados

Dame información general de mi cluster de Kubernetes

¿Hay algún problema con los pods en el namespace kube-system?

Analiza las versiones de mis componentes y dime cuáles están desactualizados

🐳 DevContainer

El proyecto incluye un DevContainer completo con:

✅ Node.js 18 + TypeScript
✅ kubectl, helm, minikube
✅ Docker-in-Docker
✅ VS Code extensions para Kubernetes
✅ Scripts de configuración automática

Usar el DevContainer

Instalar VS Code + extensión "Dev Containers"
Abrir el proyecto en VS Code
Cmd+Shift+P → "Dev Containers: Reopen in Container"
Esperar a que se construya (primera vez ~5-10 min)
Ejecutar ./scripts/start-mcp-http.sh

🔧 Configuración Avanzada

Variables de Entorno

# Configuración de Kubernetes
KUBECONFIG=/path/to/kubeconfig
KUBECTL_NAMESPACE=default

# Configuración del servidor
PORT=3002
NODE_ENV=production

# Configuración de Minikube (DevContainer)
MINIKUBE_DRIVER=docker
MINIKUBE_MEMORY=4096
MINIKUBE_CPUS=2

Múltiples Clusters

Puedes configurar múltiples servidores MCP para diferentes clusters:

{
  "mcpServers": {
    "k8s-production": {
      "command": "node",
      "args": ["/ruta/al/proyecto/dist/index.js"],
      "env": {
        "KUBECONFIG": "/path/to/prod-kubeconfig"
      }
    },
    "k8s-staging": {
      "command": "node", 
      "args": ["/ruta/al/proyecto/dist/index.js"],
      "env": {
        "KUBECONFIG": "/path/to/staging-kubeconfig"
      }
    }
  }
}

🧪 Testing

Tests Automatizados

# Tests unitarios
npm test

# Tests de integración
npm run test:coverage

# Test del servidor HTTPS
./scripts/test-mcp-https.sh

# Test completo del MCP
./scripts/test-mcp.sh

Test Manual

# Probar herramientas MCP directamente
echo '{"jsonrpc": "2.0", "id": 1, "method": "tools/list"}' | node dist/index.js

# Probar herramienta específica
echo '{"jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": {"name": "get_pods", "arguments": {}}}' | node dist/index.js

🚨 Troubleshooting

Problemas Comunes

Claude Desktop no detecta el MCP

# Verificar archivo de configuración
ls ~/Library/Application\ Support/Claude/claude_desktop_config.json

# Verificar que el MCP funcione
echo '{"jsonrpc": "2.0", "id": 1, "method": "tools/list"}' | node dist/index.js

# Reiniciar Claude Desktop
pkill -f "Claude" && sleep 3

Error de conectividad con Kubernetes

# Verificar conectividad
kubectl cluster-info
kubectl get nodes

# Verificar configuración
echo $KUBECONFIG
kubectl config current-context

Problemas con el DevContainer

# Reconstruir container
# En VS Code: Cmd+Shift+P → "Dev Containers: Rebuild Container"

# Verificar herramientas
which kubectl helm minikube node

📊 Casos de Uso

Para DevOps Engineers

Monitoreo rápido de clusters desde Claude Desktop
Análisis de versiones y components desactualizados
Troubleshooting interactivo con IA

Para Desarrolladores

Consultas rápidas sobre deployments
Verificación de servicios y pods
Análisis de configuraciones Helm

Para SREs

Auditoría de clusters y versions
Detección de problems con IA assistance
Documentación automática de infraestructura

🤝 Contribuir

Fork el proyecto
Crear feature branch: git checkout -b feature/nueva-funcionalidad
Commit cambios: git commit -am 'Agregar nueva funcionalidad'
Push al branch: git push origin feature/nueva-funcionalidad
Crear Pull Request

Desarrollo Local

# Instalar dependencias
npm install

# Desarrollo con auto-reload
npm run dev

# Ejecutar tests
npm test

# Lint código
npm run lint

📄 Licencia

Este proyecto está bajo la Licencia MIT - ver el archivo LICENSE para detalles.

🙏 Agradecimientos

Model Context Protocol por el protocolo MCP
Anthropic por Claude Desktop
Kubernetes y Helm por las herramientas
Comunidad open source por las librerías utilizadas

📞 Soporte

Issues: GitHub Issues
Discussions: GitHub Discussions
Documentation: /docs

¿Te gusta este proyecto? ⭐ Dale una estrella en GitHub!

Available Tools

6 tools

analyze_versionsC

Analizar versiones de componentes en el cluster

ParametersJSON Schema

Name	Required	Description	Default
`component`	No	Componente específico a analizar (opcional)
`namespace`	No	Namespace específico (opcional)

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. "Analizar" implies a read-style analysis, but the description does not disclose side effects, output behavior, or whether the analysis compares against a baseline or only reports current versions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence with no redundant words or filler. It is concise, but its brevity comes at the cost of important behavioral and usage detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description should explain what kind of analysis is performed and what an agent can expect as a result. It leaves the agent unable to anticipate return format or confidently choose this tool over compare_versions or get_outdated_components.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both params are already documented in the input schema. The description adds no additional meaning beyond the schema, though the cluster context weakly implies the parameters refine the analysis scope.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource ("versiones de componentes en el cluster") and a verb ("Analizar"), giving a basic sense of what the tool does. However, "analyze" is vague and does not distinguish this tool from sibling tools like compare_versions or get_outdated_components, which also operate on component versions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus its version-related siblings. The optional component and namespace parameters imply some filtering behavior, but no context, prerequisites, or exclusions are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compare_versionsC

Comparar versiones de componentes

ParametersJSON Schema

Name	Required	Description
`component`	Yes	Nombre del componente
`targetVersion`	Yes	Versión objetivo
`currentVersion`	Yes	Versión actual

TDQS

C2.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. The word 'compare' implies a read-only operation, but the description does not state side effects, authorization needs, return behavior, or whether it fetches data from the cluster. This leaves critical behavioral uncertainty for an agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded, with no filler or waste. However, it is under-specified: it conveys only a minimal restatement of purpose and omits necessary usage and behavioral context. Its brevity is helpful but not balanced with substance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter tool with no output schema and no annotations, coupled with confusingly similar siblings, this description is incomplete. It does not explain what the comparison does, what result the agent should expect, or how this differs from analyze_versions. The schema alone cannot fill these contextual gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters are already documented by the schema. The description adds no extra meaning such as version format, how 'current' and 'target' relate, or what a successful comparison requires. It neither compensates for schema gaps nor contradicts them, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource ('compare component versions'), but it is essentially a Spanish paraphrase of the tool name and does not distinguish this tool from analyze_versions or get_outdated_components. It is not a full tautology because it names 'components' as the object, but it gives no detail about the scope or nature of the comparison.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use this tool versus its siblings, such as analyze_versions or get_outdated_components. The intended use is only implied by the name and description, with no exclusions, prerequisites, or alternative routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_cluster_infoB

Obtener información general del cluster

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full burden of behavioral disclosure. It implies a read-only operation via 'Obtener,' but it does not explain the return structure, potential sizes, or any operational caveats. The description essentially restates the tool name without adding meaningful behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence with no filler or redundant elaboration. It is front-loaded, though the word 'general' is imprecise and reduces clarity without adding much value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no annotation context, yet the description does not specify what 'general cluster information' includes. An agent cannot tell whether this returns node status, resource usage, versions, or something else, making the definition incomplete for correct use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the input schema is empty, so schema coverage is trivially 100%. With no parameters, there is nothing the description must clarify; the baseline of 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: 'obtener información general del cluster' (get general cluster information). It broadly distinguishes the tool from resource-specific siblings like get_pods and get_helm_releases, though 'general information' remains vague about what exactly is returned.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives such as get_pods or get_outdated_components. There are no exclusions, prerequisites, or context clues beyond the generic phrase 'general cluster info.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_helm_releasesC

Obtener información de releases de Helm

ParametersJSON Schema

Name	Required	Description	Default
`status`	No	Filtrar por status (deployed, failed, etc.)
`namespace`	No	Namespace específico (opcional)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Obtener información' implies a read operation, but it does not explain whether namespaces are required, what the default scope is, whether status filtering is applied by default, or what the returned data looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, direct sentence with no filler or repetition. It is efficient and front-loaded with the core action and resource, though it could be more informative without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with two parameters and no output schema or annotations, the description is too minimal. An agent cannot tell what it will receive, what the default namespace behavior is, or what filtering expectations exist beyond the raw schema. More behavioral and usage context is needed for reliable invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters status and namespace are already documented in the schema. The description adds no further semantic detail about parameter behavior, such as how omitting namespace affects results or what status values are accepted, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb ('Obtener') and a specific resource ('releases de Helm'), making it easy to distinguish from siblings like get_pods or get_cluster_info. It is slightly vague about whether it lists, summarizes, or details releases, but the resource target is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus siblings such as analyze_versions, compare_versions, or get_outdated_components. There is no mention of prerequisites, intended use cases, or conditions that would make this tool the right choice versus an alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_outdated_componentsC

Obtener componentes desactualizados

ParametersJSON Schema

Name	Required	Description	Default
`namespace`	No	Namespace específico (opcional)

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the tool's name and does not explain whether the operation is read-only, what 'outdated' means, how results are computed, or what impact the call has. The verb 'get' weakly implies read-only, but that is not explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short, but it is under-specified rather than effectively concise. A single phrase with no supporting context does not earn its place as a useful tool description for an AI agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, no annotations, and sibling tools that could overlap, the description is incomplete. It does not state what kind of components are checked, what response to expect, or how namespace affects the result, leaving important gaps for correct invocation and interpretation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the only parameter, namespace, is documented as optional with a clear meaning. The description itself adds no extra semantics beyond the schema, but since the schema already covers the parameter, this is adequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear action ('Obtener' / get) and a resource ('componentes desactualizados' / outdated components), so the agent knows the basic intent. However, 'componentes' is vague and does not specify what kind of components (pods, Helm releases, cluster resources) or how it differs from siblings like analyze_versions or compare_versions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use this tool versus the sibling tools. The description only mentions the optional namespace parameter and provides no exclusions, prerequisites, or context about when this is the right choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_podsB

Obtener información de pods en Kubernetes

ParametersJSON Schema

Name	Required	Description	Default
`selector`	No	Selector de labels (opcional)
`namespace`	No	Namespace específico (opcional, por defecto todos)

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry behavioral disclosure itself. 'Obtener información' communicates that this is a read-style operation, but it does not mention return format, pagination, default namespace behavior, or any access requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It is concise and easy to parse, though it could use the brevity to include additional behavioral or usage detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with two optional parameters and a fully documented schema, the description is minimally adequate. However, it omits return value expectations and does not provide enough context for an agent to choose confidently between this and related Kubernetes tools without relying on the name.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents both parameters. The description adds no extra parameter context, which meets the baseline for a fully covered schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource (pods) and domain (Kubernetes) and implies a read operation ('Obtener información'). It is distinct enough from siblings like get_helm_releases or get_cluster_info, though 'información' is less specific than 'list' or 'describe'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use this tool versus alternatives, but the resource name 'pods' makes the intended use reasonably clear by implication. It does not mention exclusions or when a sibling would be preferable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv1.0.0Sep 6, 2026
- First observedanalyze_versions
- First observedcompare_versions
- First observedget_cluster_info
- First observedget_helm_releases
- First observedget_outdated_components
- First observedget_pods

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3/5.0

Scored 2026-09-06 09:35 across 6 tools

Disambiguation3/5

The three get_* tools target distinct Kubernetes concepts, but analyze_versions, compare_versions, and get_outdated_components overlap heavily around version analysis, making it easy to confuse them. Descriptions help somewhat, but the boundaries between 'analyze', 'compare', and 'outdated' are not crisply defined.

Naming Consistency4/5

Most tools follow a clear verb_noun pattern like get_pods, get_helm_releases, and get_outdated_components. However, analyze_versions and compare_versions break the 'get_' prefix convention, introducing minor inconsistency while remaining readable and predictable.

Tool Count5/5

Six tools is a well-scoped number for a focused Kubernetes server. Each tool appears purposeful, and the count is within the ideal range for an agent to understand and navigate without overload.

Completeness3/5

The toolset covers cluster, pod, and Helm information plus version analysis, but it lacks common Kubernetes resources like deployments, services, nodes, and namespaces. It also has no mutation or upgrade operations, which may leave agents unable to act on version findings.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Google GKE A
com.googleapis.container
The Google GKE MCP server is a managed Model Context Protocol server that provides AI applications with tools to manage Google Kubernetes Engine (GKE) clusters and Kubernetes resources. It exposes a structured, discoverable interface that allows AI agents to interact with GKE and Kubernetes APIs, enabling them to inspect cluster configurations, retrieve Kubernetes resource YAMLs, monitor operations like cluster upgrades, diagnose issues, and optimize costs—all without needing to parse text output or use complex kubectl commands.
Cloud Platforms Virtualization Observability
232
Evidra
io.github.vitas
Fail-closed policy guardrails for AI agents running kubectl, terraform, helm, and argocd.
Autonomous Agents Security Cloud Platforms
2
Helm MCP A
io.github.Kubedoll-Heavy-Industries
Give your AI assistant access to real Helm chart data. No more hallucinated values.yaml files.
Developer Tools Cloud Platforms Virtualization
52
mcp A
com.googleapis.compute
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Cloud Platforms Networking & Infrastructure OS Automation
292

Related MCP Servers

Kubernetes MCP Server
Cloud Platforms Developer Tools OS Automation
thekaranpargaie
F
license
B
quality
D
maintenance
Enables managing Kubernetes clusters through natural language by providing tools to list resources, view logs, port-forward services, scale deployments, and execute kubectl operations via AI assistants.
Updated 10 months ago (2025-11-28 05:31 UTC)
81
-
K8s MCP Server
Cloud Platforms Shell Access Command Line
apecloud
A
license
Not graded
quality
D
maintenance
Enables LLMs like Claude to securely execute Kubernetes CLI tools (kubectl, helm, istioctl, argocd) across multiple clusters through dynamic kubeconfig support, allowing natural language Kubernetes management and operations.
Updated a year ago (2025-06-17 06:11 UTC)
5
MIT
Kube MCP
Cloud Platforms Developer Tools Monitoring
icy-r
A
license
A
quality
C
maintenance
Enables AI assistants to interact with and manage Kubernetes clusters, supporting operations on pods, deployments, services, configmaps, secrets, namespaces, metrics, and events with built-in safety features for destructive actions.
Updated 9 months ago (2025-12-02 16:22 UTC)
9
13 npm
1
MIT
Kubernetes MCP Server
Cloud Platforms Virtualization Developer Tools
mjrestivo16
A
license
B
quality
D
maintenance
Enables AI assistants to interact with Kubernetes clusters through 50 specialized tools for comprehensive cluster management. Supports both local kubectl and remote SSH-based execution for managing pods, deployments, services, and other Kubernetes resources.
Updated 9 months ago (2025-12-04 07:03 UTC)
49
MIT