Provides tools for interacting with Kubernetes clusters, including listing namespaces, pods, deployments, services, and nodes, reading pod logs and events, scaling and restarting Deployments, deleting pods, and applying Deployment or ConfigMap manifests.
Click on "Deploy 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., "@k8s-mcp 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.
Open-source MCP server owned by Pawan Gunjkar (pawangunjkar@gmail.com · GitHub). MIT licensed.
Developers list pods, read logs, and restart their own Deployment from the editor. The server loads kubeconfig, or in-cluster config when that file is missing. Secret values are never returned. Pod delete requires confirm=true.
Sibling servers: github-mcp, jenkins-mcp, linux-ssh-mcp, db-mcp, observability-mcp.
Item | Value |
Package |
|
Runtime | Python 3.10+, FastMCP, official Kubernetes client |
Auth |
|
Reads | namespaces, pods, logs, events, deployments, services, nodes, secret names |
Writes | scale, rollout restart, delete one pod, apply Deployment or ConfigMap |
Related MCP server: Kubernetes MCP Server
flowchart TB
subgraph L1["Layer 1 — Editor"]
IDE["Cursor or Claude Desktop"]
end
subgraph L2["Layer 2 — MCP"]
SRV["k8s-mcp FastMCP server"]
HUB["K8sHub session"]
end
subgraph L3["Layer 3 — Cluster API"]
CFG["kubeconfig or in-cluster"]
API["Kubernetes API server"]
end
subgraph L4["Layer 4 — Workloads"]
POD["Pods and logs"]
DEP["Deployments"]
SVC["Services"]
end
IDE -->|"k8s_list_pods / k8s_pod_logs"| SRV
IDE -->|"k8s_scale / k8s_restart"| SRV
SRV --> HUB
HUB --> CFG
CFG --> API
API --> POD
API --> DEP
API --> SVCflowchart LR
FAIL["Pod not ready"] --> EV["k8s_events"]
EV --> LOG["k8s_pod_logs"]
LOG --> FIX{"Restart or scale?"}
FIX -->|restart| RS["k8s_restart"]
FIX -->|scale| SC["k8s_scale"]
RS --> DEP["Deployment"]
SC --> DEPk8s_list_namespaces, k8s_list_pods, k8s_pod_logs, k8s_events, k8s_list_deployments, k8s_list_services, k8s_list_nodes, k8s_list_secret_names
Secret names are listed. Secret values are not returned.
Tool | Effect |
| Set Deployment replicas |
| Roll a Deployment via |
| Delete one pod. Requires |
| Create or patch a Deployment or ConfigMap from YAML |
{
"mcpServers": {
"k8s": {
"command": "uv",
"args": ["run", "--directory", "C:/AI_Workspaces/Anti_Workspace/k8s-mcp", "server.py"],
"env": {
"KUBECONFIG": "C:/Users/you/.kube/config",
"K8S_CONTEXT": "dev",
"K8S_NAMESPACE": "ecs"
}
}
}
}If KUBECONFIG is empty, the server loads the default kubeconfig and falls back to in-cluster config.
Create or patch a Deployment or ConfigMap from YAML.
| Name | Required | Description | Default |
|---|---|---|---|
| session_name | No | default | |
| manifest_yaml | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool mutates resources ('Create or patch'), but fails to mention that it requires an active connection, how it handles existing resources, whether it is idempotent, or what errors might occur. The behavior beyond the core action is opaque.
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 with no filler. It front-loads the action and resource scope, making it immediately scannable. Every word contributes to the core purpose.
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 mutation tool with no annotations and a 0% schema coverage, the description is severely incomplete. It omits session_name semantics, connection prerequisites, YAML format expectations, and success/failure behavior. An agent would struggle to use it correctly without additional information, despite having an output schema.
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 0%, so the description must compensate. It clarifies that manifest_yaml is the YAML content, but it does not explain session_name at all. The agent is left guessing the purpose of session_name, and the description adds minimal value beyond what the parameter names imply.
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 states a specific verb ('Create or patch') and resource types ('Deployment or ConfigMap'), clearly distinguishing it from siblings like k8s_scale, k8s_restart, and k8s_delete_pod. It is immediately evident what this tool does and how it differs from other operations.
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 no guidance on when to use this tool versus alternatives, no mention of prerequisites like being connected to a cluster, and no exclusions or conditions. It only states capability, leaving usage context entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a kubeconfig context, or in-cluster config when no kubeconfig is available.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | ||
| namespace | No | default | |
| kubeconfig | No | ||
| session_name | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does reveal the in-cluster fallback, but it omits significant side effects such as establishing a session via session_name, changing the active connection, or any persistence/replacement semantics. For a connection-management tool, this is insufficient transparency.
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 with no redundancy or filler. It earns its place as a concise summary, though it is too brief to cover the tool's full behavior and parameter semantics.
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?
Despite having an output schema, the tool has 4 parameters with 0% schema description coverage and no annotations. The description is too minimal to let an agent confidently invoke the tool correctly; it does not explain the meaning of context, namespace, session_name, or what 'connect' changes about the environment.
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 0%, so the description must compensate by explaining the four parameters. It only mentions 'kubeconfig' generically and provides no meaning for context, namespace, or session_name. An agent cannot infer parameter formats, relationships, or defaults beyond the schema itself.
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 and resource: 'Load a kubeconfig context, or in-cluster config when no kubeconfig is available.' It clearly identifies the tool's role as establishing/loading a Kubernetes connection context, distinguishing it from siblings like k8s_disconnect, k8s_status, and the various listing/action 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 does not provide guidance on when to use this tool versus alternatives. It mentions a fallback to in-cluster config when no kubeconfig is available, but that is a behavioral condition rather than usage guidance. No mention of prerequisites, sequence with other k8s tools, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one pod so the controller recreates it. confirm=true is required.
| Name | Required | Description | Default |
|---|---|---|---|
| pod | Yes | ||
| confirm | No | ||
| namespace | No | ||
| session_name | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the destructive action (delete), notes the confirmation requirement (confirm=true), and mentions that the controller recreates the pod—mitigating the destructive effect. However, it does not discuss potential downtime, graceful vs. forced termination, or whether the operation is reversible. These are meaningful gaps for a deletion 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?
Two sentences with no fluff. The core action is front-loaded ('Delete one pod'), the consequence is stated ('so the controller recreates it'), and the essential prerequisite is appended ('confirm=true is required'). Every word earns its place; the structure is clean and efficient.
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 description covers the core action and confirmation, but it omits crucial context for a destructive operation: it does not mention the risk of downtime, what happens to the pod's data (non-persistent), or how it relates to the overall Kubernetes state. It also leaves two parameters (namespace, session_name) unexplained. While an output schema exists, the description still falls short for an agent making a high-stakes decision to delete.
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 coverage is 0%, so the description must explain all parameters. It directly addresses the 'confirm' parameter ('confirm=true is required'), which is helpful, but it does not clarify 'pod', 'namespace', or 'session_name'. While 'pod' is obvious from the tool name, 'namespace' and especially 'session_name' are left unexplained, leaving an agent uncertain about their meaning and defaults.
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 states a specific verb ('Delete') and resource ('one pod') and adds the key consequence ('so the controller recreates it'). It clearly distinguishes from sibling tools like k8s_scale or k8s_restart by indicating the deletion-driven recreation mechanism. This is a clear, unambiguous purpose.
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 no explicit guidance on when to use this tool versus alternatives like k8s_restart or k8s_scale. The phrasing 'so the controller recreates it' implies a use case (forcing recreation), but no alternatives, exclusions, or conditions are mentioned. An agent would have to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drop a Kubernetes session.
| Name | Required | Description | Default |
|---|---|---|---|
| session_name | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It fails to state side effects (e.g., whether the session is terminated, resources cleaned up), idempotency, or whether it is reversible. The single sentence is insufficient for a state-changing 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 a single, front-loaded sentence with no wasted words, but it is under-specified. While conciseness is achieved, the lack of substance means it does not earn its place in providing useful guidance.
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 but has side effects (disconnecting a session) and an output schema. The description does not explain return values, failure modes, or what happens after disconnection. Without annotations or schema descriptions, the agent lacks essential context for correct 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?
The schema has one parameter (session_name) with a default, but schema description coverage is 0% and the description does not mention it at all. The description adds no meaning to the parameter, leaving the agent to infer its purpose from the name alone.
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 'Drop a Kubernetes session' uses a specific verb ('Drop') and names the resource ('a Kubernetes session'), clearly indicating it is the inverse of k8s_connect. While 'session' is somewhat vague, the sibling context makes the purpose 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 no guidance on when to use this tool versus alternatives like k8s_connect or k8s_status. It does not mention prerequisites, session lifecycle, or any conditions that would trigger its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the latest 30 namespaced events.
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | ||
| session_name | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It does disclose the result limit ('latest 30') and the event scope ('namespaced'). However, it does not mention prerequisites like an active session, how the namespace default behaves, or other operational details. No contradiction with annotations exists because none exist.
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, tightly worded sentence that front-loads the key facts: action, resource, count, and scope. There is no redundant or filler content.
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?
Although the tool is simple and has an output schema, the description omits meaningful guidance about the two optional parameters and does not explain the session context. With no annotations and no parameter documentation, the agent cannot fully determine default behavior or edge cases.
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 0%, and the description must compensate by explaining the parameters. It only hints at 'namespace' via the word 'namespaced' and says nothing about session_name or how defaults are used. This is insufficient for an agent to confidently choose parameter values.
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 ('Show'), a clear resource ('events'), and concrete scope details ('latest 30', 'namespaced'). This distinguishes the tool from sibling tools like k8s_list_pods or k8s_pod_logs, whose purposes clearly differ.
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 intended use is implied by the description: call this to view recent namespaced events. However, it provides no explicit guidance on when to prefer this tool over alternatives or any conditions that should trigger its use, leaving the usage context only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List deployments and ready replica counts.
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | ||
| session_name | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly indicates a read-only list operation and mentions the ready replica count, but it does not explain namespace scoping, what happens when namespace is empty, how session_name is used, or any failure 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?
The description is a single focused sentence with no filler. 'List deployments and ready replica counts' is front-loaded and every phrase adds useful information.
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 has two parameters, zero schema descriptions, and no annotations, yet the description does not explain how either parameter affects behavior. The output schema exists, so return values are covered, but invocation context around sessions and namespaces is missing for a Kubernetes tool that must be connected and scoped 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 0%, so the description must compensate for the undocumented parameters, but it does not mention namespace or session_name at all. The parameter names are somewhat self-explanatory, yet the default values ('', 'default') and their operational meaning are left unexplained.
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') and resource ('deployments'), plus a concrete detail ('ready replica counts'), so an agent knows exactly what the tool returns. It does not explicitly contrast with sibling list tools, but the resource type is distinct enough that ambiguity is unlikely.
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 the tool should be used when the agent needs deployment information and replica readiness. It does not provide when-not-to-use guidance or name alternatives, such as k8s_list_pods for pod-level detail, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List namespace names.
| Name | Required | Description | Default |
|---|---|---|---|
| session_name | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 says 'List namespace names' and does not mention whether a connection is required, whether it returns an error if not connected, whether it is read-only, or any pagination/format details. For a tool with zero annotation coverage, this is a significant gap.
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 short sentence, which is appropriately concise for a simple list operation. It is front-loaded with the verb and resource. However, it is so terse that it omits useful context, so it earns a 4 rather than a 5.
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 has an output schema and only one optional parameter, the description is mostly adequate for a trivial list call. However, with no annotations and no mention of session/connection requirements, an agent may not know whether it needs to call k8s_connect first or how session_name affects the result. The output schema covers return values, but the missing behavioral context lowers the score.
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 0%, so the description must compensate for the undocumented 'session_name' parameter. The description does not explain what session_name means or how it affects the listing. However, the parameter has a default and is not required, so the baseline is slightly higher; still, the description adds no semantic value beyond the schema.
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 'List namespace names' clearly states the verb (list) and resource (namespaces), and specifies that it returns names rather than full details. It is distinguishable from sibling tools like k8s_list_pods or k8s_list_deployments, though it does not explicitly name a sibling alternative.
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: call this when you need namespace names. It does not explicitly state when to use it versus alternatives, nor does it mention prerequisites like needing an active session (k8s_connect). The context is clear enough for a simple list operation, but there is no explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List nodes and Ready condition.
| Name | Required | Description | Default |
|---|---|---|---|
| session_name | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the safety and behavioral burden. 'List' communicates read-only intent and the Ready-condition detail states the returned scope, but there is no disclosure of session/authentication requirements or behavior on failure.
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 entire description is one short sentence, with the action and output detail front-loaded. There is no filler or repeated schema content.
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 simple read-only listing with one optional defaulted parameter and an output schema, the description is nearly sufficient. It lacks explicit context about the session parameter and connection prerequisites, so it is adequate but not complete.
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 provides no description for session_name (0% coverage), and the tool description never mentions it. The description does not clarify whether session_name selects a cluster/connection or how it relates to the k8s_connect sibling.
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 the resource 'nodes,' and adds the output detail 'Ready condition,' so an agent can tell this apart from sibling list tools like k8s_list_pods or k8s_list_namespaces. The name and description align exactly.
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?
There is no guidance on when to use this tool over alternatives, nor any mention of prerequisites such as an active k8s_connect session. The only hint is the resource name itself, which makes the choice obvious but leaves context unstated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pods with phase, ready count, and node.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | ||
| namespace | No | ||
| session_name | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states what the tool returns but does not indicate that it is a read-only operation, nor does it mention any side effects, permissions, or limits. The description offers minimal behavioral insight beyond the obvious 'list' action.
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 sentence with no filler or redundant content. It front-loads the verb and resource and states the output fields concisely. There is no wasted text, so it earns a high score for efficiency.
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?
While the tool is relatively simple and an output schema exists, the description omits essential context: it does not explain the parameters, does not mention filtering capabilities, and does not provide any usage context relative to sibling tools. An agent would have to infer parameter meaning from titles and defaults, which is insufficient for correct 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 0% and the description does not explain any of the three parameters (label, namespace, session_name). The description only mentions output fields, leaving parameter meaning entirely to the schema titles and defaults. This is a significant gap for a tool with optional filtering parameters.
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 verb 'List' and the resource 'pods', and specifies the returned fields (phase, ready count, node). This distinguishes it from sibling tools like k8s_list_deployments or k8s_list_namespaces, making its purpose 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?
No explicit guidance on when to use this tool versus alternatives. The name and description imply it is for listing pods, but there is no mention of when not to use it or which sibling to choose instead. Since many list tools exist, explicit differentiation would be helpful but is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Secret names only. Values are not returned.
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | ||
| session_name | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description must carry the full behavioral disclosure burden. It does disclose one important behavior: values are not returned, which signals a non-sensitive read operation. However, it does not mention connectivity, permission requirements, empty-result behavior, or pagination, leaving notable gaps.
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 short, front-loaded sentences with no filler. The core behavior is stated immediately, and every word earns its place, though it is arguably too sparse to carry the context needed for correct invocation.
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 an output schema present, the return shape does not need to be explained, but the description still omits meaning for namespace and session_name. An agent cannot be certain whether an empty namespace means current namespace, all namespaces, or default namespace, and session_name's role is entirely unexplained.
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 0%, and the description does not mention namespace or session_name at all. The agent receives no explanation of what an empty namespace means, whether namespace is required for scoping, or what session_name refers to.
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 and resource: 'List Secret names only.' It also adds the valuable distinction that values are not returned, making the tool's scope unambiguous even among the sibling k8s 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?
There is no when-to-use guidance, no mention of alternatives, and no prerequisites such as requiring an active k8s connection. The phrase 'names only' weakly implies a lightweight use case, but the agent is not told when this tool should be preferred over other listing or secret-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List services, type, and cluster IP.
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | ||
| session_name | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'List' reasonably implies a read-only operation, and mentioning the returned fields adds some behavioral context, but the description does not disclose edge cases, namespace-scoping behavior, or possible error conditions.
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 with no filler or repetition. Every word adds information about the tool's output, making it highly concise and scannable.
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 operation is simple and an output schema exists, which covers return-value shape. However, the lacking parameter explanations and absence of any usage guidance make the description incomplete for an agent that needs to know what 'session_name' means or how namespace selection behaves.
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 0%, so the description must compensate for undocumented parameters. It does not mention 'namespace' or 'session_name' at all, leaving their meaning, allowed values, and interaction with the tool largely to inference from their names and defaults.
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') and a clear resource ('services'), and names two returned fields ('type', 'cluster IP'). It is sufficiently clear to distinguish from sibling tools like k8s_list_pods or k8s_list_nodes, though it does not explicitly contrast itself with those alternatives.
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?
No guidance is given about when to use this tool versus the other k8s list tools, nor are any prerequisites or alternatives mentioned. The usage context must be inferred entirely from the tool name and generic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the tail of a pod log.
| Name | Required | Description | Default |
|---|---|---|---|
| pod | Yes | ||
| tail | No | ||
| container | No | ||
| namespace | No | ||
| session_name | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral burden, but only states that it reads the tail. It does not disclose whether logs are streamed or truncated, how container selection works, whether a connection is required, or what happens on failure.
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 short sentence that is front-loaded with the key verb, resource, and scope. There is no redundant or filler text, and the wording is immediately parseable.
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 simple read tool with only one required parameter plus schema defaults and an output schema, the description is minimally viable. However, it omits practical invocation context such as selecting a container inside a multi-container pod and whether a prior connection/session is assumed.
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 0%, so the description must compensate. It clarifies the 'pod' and 'tail' concepts only implicitly and says nothing about the semantics or interplay of container, namespace, and session_name.
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 names a concrete action ('Read'), a specific resource ('pod log'), and a defined scope ('tail'). This cleanly separates it from sibling listing tools such as k8s_list_pods and k8s_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 gives no guidance on when to select this tool over alternatives, such as k8s_events for cluster diagnostics or k8s_connect for establishing a session. There is no when-to-use or when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Roll a Deployment by setting restartedAt.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| namespace | No | ||
| session_name | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that it modifies a Deployment via restartedAt, but does not mention side effects, safety, permissions, or whether it triggers a rolling update. For a mutation operation, this is a significant gap.
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?
A single concise sentence with no fluff. It is appropriately front-loaded with the action. However, it is too terse, but that is a completeness issue, not conciseness. The structure is efficient.
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 lack of annotations and parameter descriptions, and an output schema that is not described, the description is insufficient. An agent cannot tell if it needs a connection, what happens on failure, or what the output means. It is not complete enough for safe 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 0%, so the description must explain parameters. It only refers to 'Deployment' but does not explain the 'name' parameter (presumably deployment name), 'namespace', or 'session_name'. The cryptic 'session_name' is unexplained.
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?
States a specific verb 'Roll' and resource 'Deployment', and the mechanism 'setting restartedAt'. This clearly distinguishes from siblings like k8s_scale or k8s_delete_pod.
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?
No guidance on when to use this tool versus alternatives. It does not mention scenarios, exclusions, or alternatives like scaling or pod deletion. An agent cannot infer when a rolling restart is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scale a Deployment.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| replicas | Yes | ||
| namespace | No | ||
| session_name | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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. It only says 'Scale a Deployment' without mentioning side effects, prerequisites (e.g., deployment must exist), idempotency, or permissions. This is minimal and does not inform the agent about what happens when scaling fails or whether it is reversible.
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, short sentence, which is appropriately concise. However, it is under-specified; it does not front-load any usage context or parameter hints. While it is not verbose, its brevity borders on under-specification, so a score of 3 reflects its efficiency without substance.
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 has four parameters and an output schema, the description is extremely thin. It does not explain what the output represents, any preconditions, or how the scaling operation interacts with the cluster. The description is incomplete for an agent to call the tool correctly without additional schema inspection.
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 0%, meaning the description adds no information about the parameters. It does not mention that 'name' and 'replicas' are required, nor explain the role of 'namespace' or 'session_name'. With four parameters and zero coverage, the description must compensate but does not, making the tool's parameters opaque.
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 states a specific verb ('Scale') and resource ('a Deployment'), making the tool's purpose clear. However, it does not differentiate from sibling tools like k8s_restart or k8s_apply, so it lacks explicit sibling distinction.
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?
No guidance is provided on when to use this tool versus alternatives such as k8s_apply or k8s_restart. The description simply states the action without context or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Kubernetes sessions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 says 'List Kubernetes sessions' and does not state whether the command is read-only, requires an active connection, or behaves a certain way when no sessions exist.
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, short, front-loaded sentence with no wasted words. It is concise, though the brevity contributes to ambiguity around what a 'session' is.
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, has no parameters, and an output schema exists, so detailed return-value documentation is not needed. However, the description does not define what a Kubernetes session is or how it relates to the connect/disconnect siblings, leaving a small but real gap.
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 tool has zero parameters and 100% schema description coverage, so there is nothing for the description to add about arguments. A zero-parameter tool receives a baseline of 4.
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 states a clear verb ('List') and a resource ('Kubernetes sessions'), so an agent can tell the basic operation. It does not explicitly differentiate the tool from siblings, but no other sibling mentions sessions, so the purpose is reasonably clear.
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?
There is no guidance on when to use this tool versus k8s_connect, k8s_disconnect, or the other listing tools. No prerequisites or alternatives are mentioned.
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.
v1.0.0k8s_applyk8s_connectk8s_delete_podk8s_disconnectk8s_eventsk8s_list_deploymentsk8s_list_namespacesk8s_list_nodesk8s_list_podsk8s_list_secret_namesk8s_list_servicesk8s_pod_logsk8s_restartk8s_scalek8s_statusScored across 15 tools
Each tool targets a distinct resource and action: connect/disconnect manage sessions, list_* covers different Kubernetes resources, and pod_logs/scale/restart/delete_pod/apply are specific operations. There is no meaningful overlap—even multiple pod-related tools are clearly differentiated by their verbs.
All tools share the k8s_ prefix and generally follow a verb_noun pattern (list_namespaces, scale, delete_pod). Minor deviations exist: k8s_events and k8s_pod_logs omit the list/get verb, but the pattern is still predictable and readable.
At 15 tools, the server sits at the upper bound of the typical well-scoped range. The breadth is justified by covering connection management plus a variety of Kubernetes resources and operations, though it feels slightly heavy for a single-purpose MCP server.
The server covers listing many resources, logs, events, scaling, restarting, and applying YAML, but lacks get operations for individual resources, delete for most resources (only pods), and any write operations for services, secrets, or namespaces. It is read-heavy with limited lifecycle coverage beyond Deployments.
Secrets for developers and agents—secure context and workflows without exposing secret values.
Fail-closed policy guardrails for AI agents running kubectl, terraform, helm, and argocd.
Manage Kubernetes clusters, deployments, databases, secrets and observability on Mengi Cloud.
Deep security scans of repos you own from your editor: dependency CVEs, SAST, git-history secrets.
