Integrates with ArgoCD to manage KubeAid-managed applications, offering tools to list, describe, and sync ArgoCD Application resources, including checking sync status, health, and drift.
Provides tools to inspect and manage Kubernetes cluster resources, including namespaces, nodes, pods, deployments, events, and custom resources, using kubeconfig credentials.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@kubeaid-mcp which apps are out of sync?"
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.
An MCP server for KubeAid-managed Kubernetes clusters. Plug it into Claude Code, Claude Desktop, Cursor or any MCP-compatible client and ask questions like "which apps are out of sync?", "why is kube-prometheus degraded?" or "sync the cert-manager app" — the model answers by calling this server's tools, which talk to your cluster through your own kubeconfig credentials.
Built in TypeScript on the official
@modelcontextprotocol/sdk
and @kubernetes/client-node.
Author: Deep Poharkar
KubeAid runs clusters the GitOps way: every application is an ArgoCD
Application generated from your kubeaid-config repo, and auto-sync is
disabled by default — drift between Git and the cluster is normal and waits
for a deliberate sync. A generic Kubernetes assistant doesn't understand
that workflow. This server does:
The ArgoCD Application CR is a first-class citizen: sync status, health,
failing conditions and drifted resources are one tool call away.
Syncing is modeled as the explicit "deploy now" decision it is in KubeAid —
gated behind an opt-in flag, with dry_run support, and never allowed on
contexts you mark as protected.
The bundled prompts encode KubeAid operational habits: review drift before syncing, fix things in the kubeaid-config repo rather than hand-editing the cluster.
Related MCP server: mcp-kubernetes-server
Read tools — always registered:
Tool | What it does |
| Kubeconfig contexts the server can target, with default and write-protection flags. |
| Every KubeAid-managed ArgoCD app with sync status, health, revision and auto-sync flag. Supports |
| One app in depth: sources, error conditions, drifted/unhealthy resources, last sync result, deploy history. |
| Namespaces with status and age. |
| Nodes with Ready status, roles, kubelet version, internal IP. |
| Pods with kubectl-style derived status (CrashLoopBackOff etc.), ready count, restarts, node, age. |
| Per-container states and last-crash details, conditions, and the pod's recent events. |
| Tail container logs; |
| Deployments with ready/up-to-date/available counts. |
| Recent events, optionally warnings-only, per namespace or cluster-wide. |
| Any resource by apiVersion/kind/name — including CRDs like |
Write tools — registered only when KUBEAID_MCP_ALLOW_WRITES=true:
Tool | What it does |
| Trigger an ArgoCD sync (the KubeAid "deploy now" action). Supports |
| Set a deployment's replica count. |
| Rolling-restart a deployment/statefulset/daemonset. |
| Delete a stuck pod so its controller replaces it. |
Every tool takes an optional context argument to target any cluster in your
kubeconfig from a single server process.
Prompts appear as slash commands / menu items in the client and walk the model through a workflow using the tools above:
Prompt | Workflow |
| Root-cause a Degraded/OutOfSync app: conditions → resources → pod logs → recommendation. |
| List all drifted apps, assess the risk of each pending sync, then ask before syncing anything. |
| Sweep nodes, apps, pods and warning events; report findings by severity. |
Requires Node.js 20+.
git clone <your-repo-url> kubeaid-mcp
cd kubeaid-mcp
npm install
npm run buildclaude mcp add kubeaid -- node "$(pwd)/dist/index.js"Read-only by default. To enable writes while keeping production untouchable:
claude mcp add kubeaid \
-e KUBEAID_MCP_ALLOW_WRITES=true \
-e KUBEAID_MCP_PROTECTED_CONTEXTS=prod-cluster-1,prod-cluster-2 \
-- node "$(pwd)/dist/index.js"Enable Settings → Developer → Local MCP servers, then add to the config file that page opens:
{
"mcpServers": {
"kubeaid": {
"command": "node",
"args": ["/absolute/path/to/kubeaid-mcp/dist/index.js"],
"env": {
"KUBEAID_MCP_ALLOW_WRITES": "true",
"KUBEAID_MCP_PROTECTED_CONTEXTS": "prod-cluster-1"
}
}
}
}Fully quit and reopen the app afterwards.
All configuration is environment variables, read once at startup:
Variable | Default | Meaning |
| client-node default lookup ( | Kubeconfig path. |
| follows current-context live | Pin a fixed default context. When unset, |
|
| Namespace holding ArgoCD's |
|
| Register the mutating tools at all. |
| none | Comma-separated contexts that refuse every mutating call, even with writes enabled. |
Three independent layers:
Capability gating — with writes disabled (the default), mutating tools are never registered, so the model cannot even see them.
Protected contexts — every mutating handler re-checks the target
context against KUBEAID_MCP_PROTECTED_CONTEXTS and refuses protected
ones, whatever the model asks for.
Client confirmation — tools carry MCP readOnlyHint/destructiveHint
annotations, so well-behaved clients prompt you before risky calls.
The server holds no credentials of its own; it can only do what your kubeconfig identity is already authorized to do via RBAC.
npm run typecheck # strict TS, no emit
npm run build # compile to dist/
npm run smoke # spawn the server, MCP handshake, list tools + prompts
KUBEAID_MCP_ALLOW_WRITES=true npm run smoke # verify write tools registerThe smoke test needs no cluster — it drives the raw JSON-RPC protocol over stdio.
check_chart_updates: compare deployed chart versions against the upstream
KubeAid argocd-helm-charts directory.
Sealed-secrets helpers: list SealedSecret status, flag failed unseals.
Prometheus/Alertmanager tools: surface firing alerts from the kube-prometheus stack KubeAid ships.
KubeAid by Obmondo — the cluster management stack this server is built for.
Argo CD — the GitOps engine underneath KubeAid.
MIT © 2026 Deep Poharkar
Full detail for one ArgoCD Application: Git/Helm sources, sync and health status, error conditions, the resources that are OutOfSync or unhealthy, last sync operation result and recent deploy history. Use this to diagnose why an app is Degraded or a sync failed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Application name (as shown by list_argocd_apps). | |
| context | No | Kubeconfig context to target; omit for the server's default context. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral detail by enumerating what the tool returns: Git/Helm sources, sync/health status, error conditions, OutOfSync or unhealthy resources, last sync result, and deploy history. This goes beyond the annotations and helps set expectations for a diagnostic read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence front-loads the tool's purpose and enumerates its key outputs, while the second provides a concrete diagnostic use case. It is dense but easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing the main content categories and a clear use case. It does not detail the exact return format or pagination behavior, but for a diagnostic read tool with two well-documented parameters, the provided information is sufficiently complete for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters have clear descriptions in the schema: 'name' references list_argocd_apps, and 'context' explains default behavior. The tool description adds no additional parameter semantics, but the schema already carries the full burden, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Full detail for one ArgoCD Application' which clearly identifies the verb (provide/detail), the resource (ArgoCD Application), and singular scope. It distinguishes itself from siblings like list_argocd_apps by emphasizing 'one' application and from generic describe_resource by specifying ArgoCD-specific content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use this to diagnose why an app is Degraded or a sync failed.' This provides clear contextual guidance, though it does not explicitly mention when not to use it or name alternative tools such as describe_resource or get_events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deep-dive one pod: per-container state (waiting/termination reasons, last crash exit code), conditions and the pod's recent events.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Pod name. | |
| context | No | Kubeconfig context to target; omit for the server's default context. | |
| namespace | Yes | Namespace of the pod. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds specific details about return content (per-container state, termination reasons, crash exit codes, conditions, events) which goes beyond annotations, providing useful behavioral transparency about what to expect from the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that immediately states the purpose and lists the specific details returned. No filler or redundancy. Perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only describe tool, the description covers what it returns (per-container state, reasons, exit codes, conditions, events) and the scope (one pod). Given the annotations already indicate read-only, this is sufficient. Slight gap: it doesn't mention the namespace/name parameters explicitly, but schema covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (namespace, name) are fully described in the schema. The description does not add extra parameter semantics beyond what the schema already provides, so it stays at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a 'deep-dive' on a single pod, specifying per-container state, waiting/termination reasons, last crash exit code, conditions, and recent events. This is specific and distinguishes it from siblings like list_pods (which lists) and get_events (which retrieves events).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for in-depth pod inspection, but does not explicitly state when to use it over alternatives like describe_resource or get_events. No exclusion criteria are given, so the agent must infer when this is the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch any Kubernetes resource (including CRDs like SealedSecret or Certificate) by apiVersion, kind and name. Returns the full object.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Resource kind, e.g. "Service", "SealedSecret". | |
| name | Yes | Resource name. | |
| context | No | Kubeconfig context to target; omit for the server's default context. | |
| namespace | No | Namespace; omit for cluster-scoped resources. | |
| api_version | No | apiVersion, e.g. "v1", "apps/v1", "bitnami.com/v1alpha1" (default "v1"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description is not required to restate safety. It adds the behavioral detail that it 'Returns the full object', which is useful. The description does not introduce any contradictions with annotations, and it provides enough context beyond the structured fields (e.g., that it works with CRDs).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that starts with the core purpose ('Fetch any Kubernetes resource') and then adds the essential qualifying detail about CRDs and required identifiers. There is zero wasted wording; every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's general scope, the description is complete for an agent to understand its usage: it fetches any resource, returns the full object, and the schema provides all parameter details. It might have mentioned that it supports both namespaced and cluster-scoped resources, but the schema already clarifies this via the optional namespace field. The absence of an output schema is mitigated by the statement that it returns the full object, so no additional return-value documentation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds extra meaning by noting that it works for CRDs and providing examples (SealedSecret, Certificate), which clarifies the expected kind values. It also highlights the interplay of apiVersion, kind, and name, reinforcing the required parameters beyond the schema's individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch'), the resource ('any Kubernetes resource'), and the key identifying parameters (apiVersion, kind, name). It explicitly includes CRDs like SealedSecret or Certificate, which distinguishes it from sibling tools that target specific resource types (e.g., describe_pod, describe_argocd_app). The purpose is unambiguous and stands out from the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it can be used for any resource, but it does not explicitly mention when to prefer this over the more specific describe tools (like describe_pod) or when not to use it. No alternatives or exclusions are stated, leaving the usage guidance somewhat implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent cluster events, newest last. Filter to one namespace and/or Warning-type events only.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Kubeconfig context to target; omit for the server's default context. | |
| namespace | No | Namespace to inspect; omit for all namespaces. | |
| only_warnings | No | Return only Warning-type events. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral details like 'newest last' and the filtering capability, providing useful context beyond the schema. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core purpose and then the filtering option. No wasted words, every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (read-only list with optional filters) and annotations cover safety. The description adequately explains purpose and filters; it might mention the output format (a list) but that is implied. It is complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description reinforces namespace and only_warnings usage but adds no new syntax or format details beyond what the schema provides. A baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves recent cluster events, newest last, which is specific and distinct from sibling tools like list_pods or get_pod_logs. It mentions the resource (cluster events) and ordering, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on filtering ('Filter to one namespace and/or Warning-type events only'), implying when to use it for scoped event lookup. It lacks explicit exclusions or alternatives, but the sibling context and the filter note make the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tail a container's logs. Set previous=true to read the prior (crashed) instance's logs — essential for CrashLoopBackOff.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Pod name. | |
| lines | No | How many lines to tail (default 100). | |
| context | No | Kubeconfig context to target; omit for the server's default context. | |
| previous | No | Read logs from the previous, crashed container instance. | |
| container | No | Container name; required only for multi-container pods. | |
| namespace | Yes | Namespace of the pod. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already confirm read-only and non-destructive behavior; the description adds valuable context about the previous flag and its role in crash debugging. It does not cover streaming/pagination, but the annotations lower the bar and the added context is meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both necessary and directly informative. The first states the core action; the second gives a high-value usage tip without wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description and schema collectively provide enough for a logs tool: tailing behavior, line count, namespace/container targeting, and crash-instance option. Minor gap: no mention of output format, but that is generally implied and not critical for log retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, so the baseline is 3, but the description enriches the 'previous' parameter by explaining its purpose and relevance to CrashLoopBackOff, which goes beyond the schema's bare definition. No other parameters need extra explanation given the schema quality.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Tail' and names the resource 'container's logs', with a clear distinction from sibling tools like describe_pod or get_events. It also adds meaningful scope by mentioning 'previous (crashed) instance's logs', making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for using the previous flag ('essential for CrashLoopBackOff') and implies the tool is for reading logs. It does not explicitly compare to alternatives, but the log-specific context and sibling names make the usage clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the ArgoCD Applications KubeAid manages in this cluster, with sync status (Synced/OutOfSync), health (Healthy/Degraded/...), deployed revision and whether auto-sync is on. KubeAid disables auto-sync by default, so OutOfSync apps are usually awaiting a deliberate sync. Start here for any GitOps question.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Kubeconfig context to target; omit for the server's default context. | |
| project | No | Filter by ArgoCD project name. | |
| only_problems | No | Return only apps that are OutOfSync or not Healthy. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this read-only and non-destructive (readOnlyHint=true, destructiveHint=false). The description adds valuable behavioral context: KubeAid disables auto-sync by default, so OutOfSync apps are typically awaiting a deliberate sync. It also discloses the return fields, which is useful given no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no fluff. The first sentence fronts the action and resource, the second adds context, and the third gives usage direction. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with optional filters and no output schema, the description is complete enough. It lists the return fields (sync status, health, deployed revision, auto-sync), provides domain context, and gives usage guidance. Minor gaps like pagination are not critical for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all three parameters with descriptions (context, project, only_problems), so the description does not need to repeat them. It adds no extra parameter-level meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with the resource 'ArgoCD Applications' and scope 'KubeAid manages in this cluster', clearly distinguishing it from sibling tools like describe_argocd_app. It also lists the exact fields returned, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear directive 'Start here for any GitOps question', indicating this is the entry point for such queries. It also explains the auto-sync behavior to help interpret results, though it does not explicitly name alternatives like describe_argocd_app for app-specific details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the kubeconfig contexts (clusters) this server can target, including which one is the default and which are write-protected.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true and destructiveHint false, and the description does not contradict them. It adds useful behavioral context by specifying that output includes default and write-protected status and that the context list is limited to what this server can target.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb and object, and every clause adds meaningful detail about scope and output contents. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple, parameterless read-only listing tool. The description conveys what is listed, the scope limitation, and key output features (default and write-protected), which is sufficient for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so there are no parameters requiring clarification. With zero parameters, the description does not need to compensate for schema gaps, matching the baseline for parameter-less tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('List') with a clear object ('kubeconfig contexts') and adds scope ('this server can target'). It is clearly distinct from the sibling node/pod/deployment tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: to see available target contexts, the default, and write-protected ones. It does not explicitly name alternatives or exclusions, but the sibling list makes its unique purpose evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List deployments with ready/up-to-date/available replica counts and age.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Kubeconfig context to target; omit for the server's default context. | |
| namespace | No | Namespace to inspect; omit for all namespaces. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark readOnlyHint=true and destructiveHint=false, aligning with the non-mutating list operation. The description adds output details (replica counts, age) but no hidden behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, tightly packed with the operation's scope and returned fields; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A read-only list tool with clear parameter coverage in the schema and adequate output guidance in prose. No output schema exists, but the listed fields are simple and the behavior is likely clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The JSON Schema already describes both parameters (context, namespace) with 100% coverage. The description adds no new meaning beyond what the schema fields already say.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb ('List') and resource ('deployments'), with the scope of returned data (state, replica counts, age) stated. It does not explicitly distinguish itself from sibling list tools, but the resource type is named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies a read-only listing operation by context, but does not state when to choose it over alternatives or specify any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List namespaces in the cluster with their status and age.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Kubeconfig context to target; omit for the server's default context. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as read-only and non-destructive, which covers side effects. The description adds output details (status and age) but doesn't mention pagination, filters, or authentication caveats. Given the annotations carry the safety signal, a 3 for neutral value is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, lean sentence that states the purpose and output aspects without any filler. It is front-loaded and entirely relevant, earning a top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only list operation. With annotations covering side effects and the schema documenting the only parameter, the description supplies enough context (status, age) and does not require deeper detail. The tool is complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has full (100%) coverage for the single 'context' parameter with an explicit description, so the description does not need to repeat it. It adds no new parameter meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists namespaces in the cluster and includes status and age, which is specific and distinguishes it from sibling list tools (list_nodes, list_pods, etc.) that target other resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes when to use the tool (when you need a list of namespaces) and given the resource in the name, no alternative is needed. However, it does not explicitly mention when not to use it or direct to siblings for other resources, but the context is unambiguous enough for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List cluster nodes with Ready status, roles, kubelet version and internal IP.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Kubeconfig context to target; omit for the server's default context. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds output detail (Ready, role, version, IP) but no additional behavioral boundaries beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, clear and directly informative; no redundancy with schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For the tool's narrow scope (list nodes), the schema covers the only parameter; the description gives the returned fields, and the siblings provide related operations. Lacks an output schema, but optional for such outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides full description of 'context' (the kubeconfig context; omit for server default). Description reinforces target semantics in readable terms, though plain schema would likely be enough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'list' with a specific resource ('cluster nodes') and includes the key result fields (Ready, role, kubelet version, internal IP), distinguishing it from node/pod listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context is given (list nodes), but no explicit when-to-use guidance or named alternatives; sibling names 'list_pods' and 'get_nodes' imply adjacent functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pods with derived status (CrashLoopBackOff, ImagePullBackOff, Terminating, ...), ready count, restarts, node and age.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Kubeconfig context to target; omit for the server's default context. | |
| namespace | No | Namespace to inspect; omit for all namespaces. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this read-only, safe behavior without contradiction. It adds value by disclosing the exact output fields (derived status, ready count, restarts, node, age), which helps the agent understand what information will be returned. This goes beyond the structured annotations by providing the output contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that begins with the primary action ('List pods') and then lists the key output fields in a scannable format. No words are wasted, and the most important information (what it does) is front-loaded. Excellent balance of brevity and information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read-only list operation, the description covers purpose, output fields, and the critical namespace scoping behavior (including the default). It does not mention pagination or limits, which might be a minor gap for large clusters, but the annotations and schema fill in the safety and parameter details. The description is complete for the tool's apparent simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters (context and namespace) with clear descriptions, providing a solid baseline. The description enriches the namespace parameter by explicitly stating that omitting it means 'all namespaces', which is not explicit in the schema. This extra semantic detail is valuable for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists pods with derived status (CrashLoopBackOff, Terminating), ready count, restarts, node, and age. This specific verb+resource combo and the detailed output fields distinguish it from sibling tools like list_deployments or describe_pod. It immediately conveys the exact scope and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning the namespace parameter behavior ('omit for all namespaces'), but does not explicitly state when to use this tool versus siblings like describe_pod or list_deployments. There is no explicit 'use this when' or alternative naming. The guidance is present but implicit, requiring the agent to infer the tool's position among its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0describe_argocd_appdescribe_poddescribe_resourceget_eventsget_pod_logslist_argocd_appslist_contextslist_deploymentslist_namespaceslist_nodeslist_podsEach tool targets a distinct resource/action - nodes, events, ArgoCD apps, pods, deployments, generic resource fetch, contexts, namespaces - with no overlapping purposes. The list/describe pairs for pods and ArgoCD apps are clearly separated by summary vs. detail, and describe_resource is explicitly generic.
Naming follows a consistent verb_noun pattern: list_* for summary listings, describe_* for detailed views, and get_pod_logs as a specific action. Even though get_events uses 'get' instead of 'list', the pattern is predictable and readable, so deviation is minor and not confusing.
With 11 tools, the set is well-scoped for a Kubernetes diagnostic server. Each tool addresses a common troubleshooting need (node health, pod issues, logs, ArgoCD sync, deployments) without excess or missing core operations.
The surface covers the main diagnostic workflows: listing and describing nodes, pods, deployments, and ArgoCD apps; retrieving events and logs; fetching any resource via describe_resource; and listing contexts/namespaces. For a read-only troubleshooting tool, this is comprehensive with no critical dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
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.
MCP server for Argo RPG Platform — connects AI assistants to campaign data via OAuth2
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/deep-poharkar/kubeaid-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
