mcp-kubernetes

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Each tool is tied to a distinct resource or action, and the list-versus-get distinction is clear overall. The only mild overlap is that get_pod and get_resource can both retrieve a pod, but the descriptions make the scope of each unambiguous.
Naming Consistency5/5
Tool names consistently follow a get_/list_ pattern with descriptive resource nouns. The minor exception of get_pod_logs reads naturally and does not break the overall naming convention.
Tool Count5/5
Ten tools is a well-scoped count for a Kubernetes-focused server. It covers common list and retrieval operations without overwhelming the user with excessive redundancy.
Completeness4/5
The toolset is fairly complete for a read-only inspection client, covering key resources, logs, and events. It lacks mutation/update/delete capabilities, which limits it to observation, but the generic get_resource fills some coverage gaps.
Average 3.8/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 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
This repository is licensed under MIT License.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It adds only 'recent' to what the schema already conveys, and omits whether this is a read-only call, what fields the events contain, how many are returned, and how 'recent' is bounded. For a tool with zero annotation coverage, this is insufficient.
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 one tightly written sentence that includes the action, the resource scope, and the main use case, legitimate without verbosity. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema explains the required namespace and optional context, and the description tells the agent that this is for recent events and diagnostic issues. But there is no output schema and no mention of the shape of returned event objects, pagination, Limit, or sort order, leaving gaps for an agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters (namespace, kube-config context) and covers the default behavior of context. The description adds no new parameter semantics, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('events in a namespace'), and adds a purpose ('useful for diagnosing failures'). It is clearly distinct from the sibling tools like list_pods or list_services. It doesn't explicitly name or contrast a sibling, but the resource name is unambiguous enough.
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?
'Useful for diagnosing failures' gives an implied use case, but there is no explicit guidance on when to prefer this over related tools like get_pod_logs or get_resource, nor any exclusions. The context is plausible, but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. 'Fetch' implies a read operation, but the description does not say what the returned representation includes, whether it requires special permissions, or what happens on errors. This leaves important behavior unspoken.
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 13-word sentence that starts with the action and the specific result. Every word contributes to meaning, there is no redundancy, and the structure is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is enough for a trivial getter in that the schema already covers required and optional parameters, but with no output schema and minimal wording, it does not explain the return shape or edge case. The description is adequate but not self-contained for a complex agent needing to handle failures or requiring specifics of 'full representation'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters at 100% coverage (name, namespace, context with default). The description adds no additional meaning beyond the schema, so it simply meets the baseline without strengthening param understanding.
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 ('Fetch') and resource ('full representation of a single pod'), clearly distinguishing it from siblings like list_pods (collection) and get_pod_logs (logs only). The phrase 'single pod' makes the target unambiguous.
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 word 'single' implies this tool is for fetching one pod's details rather than listing all pods, but the description does not explicitly state when to choose this over list_pods or get_resource. No alternatives are named and no exclusions are communicated.
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 given, the description carries the behavioral burden, but it only says 'Fetch recent logs,' which implies read-only access and a limited scope. It does not disclose output format, default tail behavior, or what happens when a container is terminated, though some of this is encoded in parameter descriptions.
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 direct, using a single sentence that gets straight to the point with no filler. It is easy to read and front-loaded with the relevant action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple and the schema covers parameters fully, but this description is not complete field for successful calling. Since it has no output schema and no annotation signals, an agent would benefit from including details about outcome format or the default logging tail, which are not mentioned in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all six parameters with helpful descriptions and defaults, so the tool description is not required to repeat them. The description remains neutral and not harmful, but it adds no extra parameters semantics 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 identifies the action 'Fetch' and the resource 'pod container logs', making the tool's purpose immediately understandable. It is distinct from sibling tools like get_pod and list_pods because it targets log data specifically.
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 about when to use this tool versus alternatives. It does not mention when it is appropriate, when it is not, or offer any sibling comparisons.
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 provided, the description carries the full safety burden. 'Read' clearly signals a non-mutating operation, which is helpful, but the description doesn't disclose likely errors, required cluster permissions, behavior for missing resources, or how the response is shaped. It is adequate but not transparent about failure or edge-case 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 one compact sentence that states the operation, resource class, and identifying keys, with an immediate illustrative example. Every word earns its place and nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a generic Kubernetes object reader with no output schema and no annotations. The description and schema cover the five parameters well, but the description does not detail response format, namespace omission for cluster-scoped resources, or any operational caveats. It is sufficient for a basic call but not fully complete for an unfamiliar agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters. The description adds small value with examples like 'apiVersion=apps/v1, kind=Deployment', but it does not materially expand on the schema definitions.
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 ('Read') and resource class ('arbitrary Kubernetes object') with the required identifying tuple (apiVersion/kind/name). It clearly differentiates itself from the sibling get_pod/list_* tools by emphasizing arbitrary resource access rather than a specific type.
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 word 'arbitrary' implies this tool is for resources without a dedicated sibling tool, but the description never explicitly says when to prefer get_resource over get_pod or list_deployments. Usage context is implied rather than stated, and no exclusions or fallback guidance are provided.
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 explicitly discloses that namespaces outside the allowlist are filtered out—a non-obvious behavioral restriction for a list operation. It does not describe return formatting or pagination, but for a basic read-only list tool this is a meaningful behavioral disclosure.
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?
Two short sentences carry all the information: a clear action in the first sentence and a key behavioral constraint in the second. There is no filler, and the most important information is front-loaded.
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?
Given the tool's simplicity—a single optional parameter, no output schema, and no annotations—the description covers the essential purpose and a meaningful filtering restriction. It does not provide broader context about cluster access or when to branch to other tools, but it is sufficient for invoking this list operation correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the single 'context' parameter is already documented in the input schema as the kube-config context to target and its default. The tool description adds no parameter-specific details, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the verb ('List') and the resource ('namespaces') with explicit cluster scope, and adds the allowlist-filtering behavior. This clearly distinguishes it from sibling tools like list_contexts, list_pods, and get_resource by resource type.
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 prescribe when to use this tool versus alternatives, nor does it mention list_contexts, get_namespace, or other resources. The only signal is the allowlist filter, which implies current-access-limited usage but gives no explicit when-to-use/when-not-to-use guidance.
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?
There are no annotations, so the description carries the transparency burden. The description reveals that output includes type and cluster IP and that listing is namespace-scoped, but it does not explicitly state that the operation is read-only, how the context parameter affects target selection, or what happens for services without a cluster IP. 'List' implies non-mutating, but the behavioral details are sparse.
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 short sentence with no filler. It front-loads the main operation and immediately states the output fields, which is highly efficient for an agent parsing the definition.
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 read-only listing tool with only two parameters and full schema descriptions, the definition is almost complete. It includes output hints ('type and cluster IP') and states namespace scoping. It does not mention default context behavior, but that is minor and already captured in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already well documented. The description mentions 'namespace' as the scoping target but adds no new parameter-level meaning beyond the schema and does not explain the optional 'context' parameter.
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 states a specific verb ('List'), the resource ('services'), and the scoping dimension ('namespace'), and it names the output fields ('type and cluster IP'). This makes it clearly distinct from sibling tools like list_pods or list_namespaces without needing to open their schemas.
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?
Usage context is implied by the resource name: to list services, select this tool. However, the description gives no explicit when-to-use guidance and does not mention alternatives or exclusions, so an agent must infer that it should use this instead of list_pods or list_events.
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 of characterizing the operation. It clearly describes a read-only listing operation and adds a concrete behavioral trait: deployments are shown along with their replica status. It does not go into output shape or caveats, but for a simple list tool the behavior is adequately transparent.
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?
One sentence, front-loaded with the verb and target resource, and every part ('list', 'deployments', 'namespace', 'replica status') adds relevant meaning. There is no filler or redundancy.
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 straightforward list operation, the description covers the what, where, and an aspect of the return content (replica status). Given there is no output schema, additional detail on returned fields could help, but the description is sufficient for an agent to reasonably invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both 'namespace' and 'context'. The description only echoes the namespace concept in prose and adds no new information about parameter behavior or format beyond what the schema states.
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 and resource ('List deployments') plus the scope 'in a namespace' and a meaningful detail ('with replica status'). This clearly identifies what the tool does and is distinguishable from siblings like list_pods, list_services, or list_events.
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 purpose implies when to use it — when you want deployment information in a given namespace — but there is no explicit guidance about when not to use it or why it should be chosen over sibling tools like get_resource. Usage is inferred rather than stated.
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 burden of behavior. 'List' clearly indicates a read-only operation with no side effects, which is sufficient for this simple tool. However, it does not disclose behavior such as what happens if no kube-config is loaded or if the output is just names.
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, compact sentence that adds value beyond the tool name by specifying 'contexts (clusters)' and 'loaded kube-config'. No fluff or unnecessary details.
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?
Given the zero-parameter schema, no output schema, and clear listing semantics, the description is complete. An agent can correctly determine when and how to invoke this tool without additional information.
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 input schema has zero parameters, so there is nothing to clarify. The description correctly refers to the existing kube-config as the only implicit input, which matches the 0-parameter 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?
States a specific verb ('List'), a clear resource ('contexts (clusters)'), and a source ('loaded kube-config'). It is clearly distinguishable from sibling resource-listing tools like list_namespaces or list_pods.
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 when it should be used: whenever the agent needs to know which kube-config contexts are available. It does not explicitly name alternatives or when-not-to-use cases, but the scope is clear enough for a zero-parameter listing tool.
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 behavioral burden. 'List' makes the non-mutating read behavior clear, and the description discloses the main output fields (status, readiness, restarts, node). It does not cover error behavior or pagination, but these are minor for a simple read-only list operation.
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?
One sentence with no filler; the action, resource, scope, and summary fields are all front-loaded. Every word contributes to the agent's ability to select and invoke the tool correctly.
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 two-parameter tool with full schema coverage and no output schema, the description is mostly complete: it gives the operation, the namespace scope, and the key returned fields. It only lacks a pointer such as 'use get_pod for full pod details', which would strengthen but not block correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds only light context by tying the operation to 'a namespace', without adding 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?
Defines a specific verb ('List'), a specific resource ('pods'), a namespace scope, and the fields returned. This clearly separates it from siblings like list_deployments, list_services, and get_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 namespace-scope context clearly states when the tool is relevant, and 'List' implies a plural/summary operation rather than a one-pod lookup. It does not explicitly name an alternative like get_pod for detailed pod information, so there is no explicit exclusion.
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, the description carries the behavioral burden. It clearly conveys a read-only listing operation and even discloses that readiness and kubelet version will be part of the result. It could have added details like default-context use or read-only emphasis, but the behavior is sufficiently transparent for a list operation.
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 one short, front-loaded sentence that contains no filler and directly states the operation and result contents. Every word contributes to the agent's understanding.
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?
For a simple read-only list tool with one optional parameter and no output schema, the description is complete. It covers what is returned and what resource is being listed, and the schema fully explains the only parameter. Nothing an agent needs to invoke this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter, context, is already fully described in the input schema with 100% coverage. The description adds no additional meaning to this parameter, so it meets the schema-heavy baseline but does not go beyond it.
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 names a specific verb and resource: list cluster nodes. It also specifies the key output fields (readiness and kubelet version), making the tool's purpose immediately distinguishable 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 gives clear context: this is the tool for listing cluster nodes rather than contexts, namespaces, pods, or deployments. However, it does not explicitly describe when not to use it or suggest an alternative, so it earns a 4 rather than a 5.
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:

[![mcp-kubernetes MCP server](https://glama.ai/mcp/servers/dockndevai/mcp-kubernetes/badges/card.svg)](https://glama.ai/mcp/servers/dockndevai/mcp-kubernetes)

Score Badge

Copy to your README.md:

[![mcp-kubernetes MCP server](https://glama.ai/mcp/servers/dockndevai/mcp-kubernetes/badges/score.svg)](https://glama.ai/mcp/servers/dockndevai/mcp-kubernetes)

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/dockndevai/mcp-kubernetes'

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