k8s-mcp-server

by AmazingYe-oss

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource or action: health check, namespaces, pods, logs, pod details, nodes, events, and a comprehensive diagnostic. The diagnose_pod tool is clearly positioned as a higher-level troubleshooting action, so there is no ambiguity.
Naming Consistency5/5
Tool names consistently follow the verb_noun pattern (list_*, get_*, describe_*, diagnose_*), with only 'ping' as a standard health-check verb. All names use lowercase with underscores, providing a predictable naming scheme.
Tool Count5/5
Eight tools is well within the ideal range for a focused Kubernetes inspection server. Each tool covers a distinct aspect of cluster and pod monitoring, and there is no redundancy or unnecessary bloat.
Completeness4/5
The tool set provides solid coverage for cluster health, namespace listing, pod logs, pod details, node information, events, and a diagnostic workflow. However, it lacks tools for other common Kubernetes resources like deployments, services, and configmaps, which would be expected from a general-purpose k8s server.
Average 4.2/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It explains that it fetches logs and documents cluster options (local vs cloud) and tail_lines, but does not mention read-only nature, error behavior, or permissions. For a simple read operation this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose followed by a formatted argument list. Every sentence provides useful detail, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no required fields, and an output schema, the description covers all necessary operational details. It does not discuss edge cases like multi-container pods or follow mode, but these are not clearly needed given the tool's simplicity and the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining every parameter: cluster (with specific values and defaults), namespace (default), pod_name, and tail_lines (meaning). This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取指定 pod 的日志' (get logs of specified pod). It uses a specific verb and resource, and is distinct from sibling tools like list_pods, describe_pod, and diagnose_pod.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as describe_pod or diagnose_pod. It only explains parameters, not use cases or exclusions, so agents have no explicit context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It adds useful behavior details like sorting order, max results, and cluster selection, but does not explicitly state that this is a read-only operation or disclose any potential side effects, permissions, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the main purpose in the first sentence and parameter details following. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers scope, ordering, result limit, and parameter semantics, which is adequate for a simple list tool. With an output schema present, return values are not needed in the description. Slight gap: no mention of potential error scenarios or use case context, but these are minor for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides type and default for 'cluster', with 0% description coverage. The tool description fully explains the parameter, including the allowed values ('local'/'cloud'), their meanings (local k3s vs Alibaba Cloud k3s), and the default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recent events across all namespaces, sorted by time descending, with a max of 20 entries. This is a specific verb+resource+scope and distinguishes it from sibling tools like list_pods or list_namespaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention any exclusion criteria or preferred use cases beyond the basic list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool lists pods and their status, implying a read-only operation, but does not explicitly mention side effects, error behavior, or limitations. The cluster parameter is explained, and the read-only nature is obvious, but deeper behavioral traits (e.g., what happens if namespace is invalid) are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and well-structured: a one-sentence purpose followed by an Args block with each parameter explained. No redundant information or fluff. It is front-loaded with the primary function, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with only two parameters and an output schema present, the description covers the purpose and all parameter semantics. It does not mention error conditions or what happens when resources are missing, but given the tool's simplicity and the output schema's existence, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides thorough semantic meaning for both parameters. For cluster, it explicitly lists allowed values ('local' and 'cloud') and their meanings, plus the default. For namespace, it clarifies the purpose and default. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '列出指定 namespace 下的所有 pod 及其状态' (list all pods in the specified namespace and their status), which is a specific verb-resource-scope combination. It distinguishes from sibling tools like get_pod_logs and describe_pod by focusing on listing all pods rather than inspecting individual ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives like describe_pod or get_pod_logs. It only states what it does and gives parameter defaults, but no contextual advice or exclusions. Without explicit alternative references, the usage guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It describes the content of the output (status, IP, node, etc.) but does not explicitly state that the operation is non-mutating, mention permission requirements, or describe error behavior. The read-only nature is implied by the verb 'describe' but not made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence summary followed by a clearly labeled Args list. Every sentence provides useful information, and the format is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple describe tool with a supported output schema, the description covers the main elements: purpose, parameters, and the nature of the returned data. It does not address error scenarios or emphasize pod_name as required, but given the simplicity and available output schema, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description's Args section adds crucial meaning: it explains that cluster accepts 'local' or 'cloud' (with context), and provides defaults for namespace and cluster. However, it does not highlight that pod_name is logically required despite the schema listing an empty default, which is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving detailed information about a specific pod, listing fields like status, IP, node, container status, restart count, image, and resource configuration. This is a specific verb-resource combination that distinguishes it from sibling tools like list_pods and get_pod_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting a single pod but does not explicitly state when to use this tool versus alternatives such as diagnose_pod or get_pod_logs. There are no explicit exclusions or alternative recommendations, leaving the agent 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns 'all namespaces and their status', implying a read-only behavior, but it does not mention potential side effects, permissions, or behavior on invalid cluster values. This is adequate but minimal for a list operation, hence a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence for the main purpose, followed by a compact parameter explanation. There is no fluff or redundancy; every sentence adds value. This is an ideal concise structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter, the description provides the essential purpose and fully explains the parameter. An output schema exists, so return value details are likely covered there. It does not address error handling or edge cases, but these are not critical for a simple read-only operation, so a 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the schema for the single 'cluster' parameter: it specifies allowed values ('local' and 'cloud'), clarifies their meaning (local k3s vs Alibaba Cloud k3s), and states a default. Since schema description coverage is 0%, this fully compensates, earning a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: listing all namespaces and their status in the cluster. The verb 'list' is specific, the resource is 'namespaces', and it distinguishes from sibling tools like list_pods and list_nodes by targeting a different Kubernetes resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys when to use this tool (when you need to see namespaces and their status) and gives context by naming the target cluster. It does not explicitly mention alternatives or exclusions, but the resource-specific purpose makes usage clear, earning a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the exact response ('pong') and its meaning. It could be more explicit about error behavior, but for a simple ping tool this is largely sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that conveys the purpose and behavior with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 likely has an output schema covering the return value. The description sufficiently explains its role and expected result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. No parameter information is needed beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as a health check that returns 'pong' to indicate normal server operation. It is specific and distinguishes itself from sibling tools that manage Kubernetes resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the phrase 'health check tool'—use it to verify server liveness. However, no explicit when-to-use or alternatives are provided, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that one call returns multiple data types and provides preliminary diagnostic advice, which is helpful. However, it does not mention permissions, side effects, or limitations, though the tool appears read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The purpose is stated in the first sentence, followed by a brief list of outputs, usage guidance, and an Args block. Every sentence earns its place with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, usage context, and parameters, and notes the output includes diagnostic suggestions. An output schema is present, so return fields need not be enumerated. Minor gaps include no discussion of edge cases or interactions with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), but the description's Args section fully explains each parameter: namespace, pod_name, and cluster with allowed values (local/cloud) and a default. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '诊断指定 Pod 的健康状态' (diagnose the health status of a specified Pod). It lists the aggregated outputs (basic info, container status, warning events, logs, and rule-based suggestions), which distinguishes it from sibling tools like get_pod_logs or describe_pod.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it: when users need to troubleshoot Pod anomalies, crashes, or startup failures, and says to prioritize this tool. However, it does not mention when not to use it or name explicit alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the output fields and parameter options, adding behavioral context beyond the tool name. It does not explicitly state that the operation is read-only, but 'list' implies it, and no side effects are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences. The primary purpose is front-loaded, and the Args section is efficient without superfluous information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an available output schema. The description explains the return contents (status, OS, K8s version) and the cluster options, making it complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description fully compensates by defining the 'cluster' parameter with its allowed values ('local'/'cloud') and default, which is absent from the schema. This is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '列出' (list) with a clear resource '集群中的所有节点' (all nodes in the cluster), and enumerates the returned fields (status, OS, K8s version). This clearly distinguishes it from sibling tools like list_pods or list_namespaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on the cluster parameter, explicitly naming the two valid options (local and cloud) and the default. It does not explicitly mention alternative tools or when not to use, but the context for cluster selection is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![k8s-mcp-server MCP server](https://glama.ai/mcp/servers/AmazingYe-oss/k8s-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/AmazingYe-oss/k8s-mcp-server)

Score Badge

Copy to your README.md:

[![k8s-mcp-server MCP server](https://glama.ai/mcp/servers/AmazingYe-oss/k8s-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/AmazingYe-oss/k8s-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AmazingYe-oss/k8s-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server