Which integrations are available for this server?

Provides read-only access to Kubernetes cluster resources, allowing listing of pods, deployments, services, namespaces, nodes, and fetching logs from pods and other resources.

How do I use Kubernetes Read Only MCP Server?

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

Kubernetes Read Only MCP Server

by vijaykodam

Overview Schema Related Servers Score Discussions

Python

Remote

Kubernetes Read Only MCP Server

A Model Context Protocol (MCP) server for safely interacting with Kubernetes clusters using read-only operations.

This MCP server was created to provide a secure way to interact with Kubernetes clusters without allowing any create, update, or delete operations. It only exposes read-only APIs to ensure your clusters remain safe while still enabling AI assistants to help you monitor and troubleshoot your Kubernetes resources.

Built with FastMCP 3.x (the standalone fastmcp framework) and the official Kubernetes Python client library. Secret values are never exposed: for any Secret, only its metadata and type are returned, never data or stringData.

Blog post and Demo

Watch the demo and read the write-up at https://vijay.eu/posts/building-my-first-mcp-server/

Related MCP server: homelab-mcp

Features

This MCP server provides the following read-only tools. Every tool is annotated read-only (readOnlyHint=True, destructiveHint=False) and returns native structured data.

Curated tools

list_pods: List all pods in a namespace or across all namespaces
list_deployments: List all deployments in a specified namespace
list_services: List all services in a namespace or across all namespaces
list_namespaces: List all namespaces in the cluster
get_events: Get Kubernetes events from the cluster
get_pod_logs: Get logs from a specific pod
get_logs: Get logs from pods, deployments, jobs, or resources matching a label selector
list_nodes: List all nodes in the cluster and their status

Generic tools (any kind, including CRDs)

These use the Kubernetes dynamic client, so they work for built-in kinds and Custom Resources alike. They are GET/LIST only and never mutate the cluster.

list_resource: List resources of any kind (e.g. Ingress, ConfigMap, a CRD), optionally scoped by api_version, namespace, label_selector, and field_selector.
get_resource: Get a single resource of any kind by name (with optional api_version and namespace).
list_api_resources: Discover which resource kinds the cluster exposes and can be listed (returns group_version, kind, namespaced, and verbs), so you know what to pass to the tools above.

Secret safety: even list_resource/get_resource with kind="Secret" return only metadata and type — the data and stringData fields are always stripped before output.

Prerequisites

Python 3.10 or higher.
uv is installed (it provides uvx). If not, install it with pip install uv (or pipx install uv).
Kubernetes cluster up and running.
Kubeconfig configured with a default context.
For demo purposes, you can use kind and Docker to set up a local Kubernetes cluster quickly on your machine. Refer to this quickstart: https://kind.sigs.k8s.io/docs/user/quick-start/

General MCP Host Configuration

Different MCP Hosts (AI assistants or CLIs that support MCP) manage their MCP server configurations in different ways. Generally, you tell your MCP Host how to start the kubernetes-readonly-mcp server. This involves:

The command to run the server. For kubernetes-readonly-mcp this is uvx kubernetes-readonly-mcp@latest, which uses uvx to download and run the package from PyPI.
Any necessary arguments.
A working directory, if the host requires one.

uvx handles downloading and running kubernetes-readonly-mcp on first invocation; no separate install step is needed. The server communicates over STDIO.

Host-specific, copy-paste configuration follows below. You can find more information about the Model Context Protocol at:

Model Context Protocol Documentation
Example Host Documentation:
1. Claude Code: MCP
2. Codex CLI: MCP
3. Kiro CLI: MCP Configuration
4. Antigravity: Editor MCP and CLI MCP
5. Claude Desktop: Connect to local MCP servers

Host Setup

1. Claude Code

Add the server with the CLI (the -- separates Claude Code's own flags from the command to run; STDIO is the default transport). Without an explicit scope, Claude Code stores this as a local, private server for the current project:

claude mcp add kubernetes-readonly-mcp -- uvx kubernetes-readonly-mcp@latest

To share the server with a project (committed to the repo), add it with project scope:

claude mcp add --scope project kubernetes-readonly-mcp -- uvx kubernetes-readonly-mcp@latest

Or create a .mcp.json at the project root:

{
  "mcpServers": {
    "kubernetes-readonly-mcp": {
      "command": "uvx",
      "args": ["kubernetes-readonly-mcp@latest"]
    }
  }
}

2. Codex CLI

Add the server with the CLI:

codex mcp add kubernetes-readonly-mcp -- uvx kubernetes-readonly-mcp@latest

Codex CLI and the Codex IDE extension share MCP configuration. You can also add the server directly to ~/.codex/config.toml:

[mcp_servers.kubernetes-readonly-mcp]
command = "uvx"
args = ["kubernetes-readonly-mcp@latest"]

Use codex mcp list to verify it is configured.

3. Kiro CLI

Kiro CLI is the rebranded next update of Amazon Q Developer CLI. Add the server with the CLI:

kiro-cli mcp add --name kubernetes-readonly-mcp --scope global --command uvx --args kubernetes-readonly-mcp@latest

Or configure servers in ~/.kiro/settings/mcp.json (user scope) or <project>/.kiro/settings/mcp.json (project scope):

{
  "mcpServers": {
    "kubernetes-readonly-mcp": {
      "command": "uvx",
      "args": ["kubernetes-readonly-mcp@latest"],
      "disabled": false
    }
  }
}

If you previously used Amazon Q, migrate your old ~/.aws/amazonq/mcp.json entries to ~/.kiro/settings/mcp.json.

4. Antigravity (Google)

Antigravity Editor reads MCP servers from ~/.gemini/antigravity/mcp_config.json (on Windows, C:\Users\<USER>\.gemini\antigravity\mcp_config.json). You can open this file from the app: the "..." menu -> MCP Servers -> Manage MCP Servers -> View raw config.

Antigravity CLI v2.0+ also supports MCP. Open the CLI MCP manager with /mcp, or add the same server block to ~/.gemini/antigravity-cli/mcp_config.json for global CLI setup. For a workspace-local CLI setup, use .agents/mcp_config.json in the active project.

{
  "mcpServers": {
    "kubernetes-readonly-mcp": {
      "command": "uvx",
      "args": ["kubernetes-readonly-mcp@latest"]
    }
  }
}

5. Claude Desktop

Edit claude_desktop_config.json (on macOS, ~/Library/Application Support/Claude/claude_desktop_config.json; on Windows, %APPDATA%\Claude\claude_desktop_config.json):

{
  "mcpServers": {
    "kubernetes-readonly-mcp": {
      "command": "uvx",
      "args": ["kubernetes-readonly-mcp@latest"]
    }
  }
}

Restart Claude Desktop after editing so it picks up the new server.

Verifying the setup

kubernetes-readonly-mcp is a STDIO MCP server: running it starts a process that speaks the MCP protocol over standard input/output and waits for an MCP host to connect. It does not take a tool name as a command-line argument.

To confirm uvx can fetch and launch the package, run:

uvx kubernetes-readonly-mcp@latest

The process will start and wait silently for an MCP client (press Ctrl+C to stop). It will not print a namespace list — tools are invoked by an MCP host, not from the shell. Beyond that, verification depends on your MCP host: after configuration, the server and its tools should appear in the host's interface, where you can invoke them.

Example Prompts

"Get list of pods from my kubernetes cluster"
"Are there any failing pods? Debug why they are failing"
"Show me the logs from the nginx deployment"
"List all services in the default namespace"
"List all ingresses across every namespace" (uses the generic list_resource tool with kind="Ingress", api_version="networking.k8s.io/v1")

License

Apache License 2.0

Disclaimer

This is an experimental project and not production-ready. Use it at your own discretion.

Available Tools

11 tools

get_eventsGet EventsB

Read-onlyIdempotent

Get Kubernetes events from the cluster for a specific namespace or all namespaces

ParametersJSON Schema

Name	Required	Description	Default
`namespace`	No	The Kubernetes namespace to get events from. If not provided, events from all namespaces will be returned.
`field_selector`	No	Selector to restrict the list of returned events by field. For example 'involvedObject.name=my-pod'.

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare the tool as read-only and idempotent. The description adds context about namespace scoping and field selection, but these are already detailed in the input schema. No additional behavioral traits beyond annotations are disclosed.

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, well-structured sentence that immediately conveys the tool's purpose and scope. Every word is necessary, and it 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?

The tool has a simple interface with two optional parameters, and the schema fully describes them. The description captures the essential behavior (getting events, namespace filtering). However, it does not mention what events contain or any limitations like pagination, which would be expected but not critical given the annotations.

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?

With 100% schema description coverage, the baseline is 3. The description does not add new meaning beyond the schema's own parameter descriptions, which already explain the namespace and field_selector behavior.

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

Purpose4/5

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

The description clearly states the verb 'Get' and the resource 'Kubernetes events', and specifies the namespace scoping. While it does not explicitly distinguish from sibling tools, the resource type (events) is distinct from logs or pods, making the purpose clear.

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. It merely states its functionality without indicating scenarios or exclusions.

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

get_logsGet LogsB

Read-onlyIdempotent

Get logs from pods, deployments, jobs, or resources matching a label selector

ParametersJSON Schema

Name	Required	Description
`resource_type`	Yes	Type of resource to get logs from ('pod', 'deployment', 'job', etc.)
`namespace`	No	The Kubernetes namespace. If not provided and name is specified, uses the 'default' namespace. If neither name nor namespace is provided, searches across all namespaces.
`name`	No	The name of the specific resource to get logs from.
`label_selector`	No	Label selector to filter resources (e.g. 'app=nginx'). Required if name is not provided.
`container`	No	The container name within the pod. If not specified and the pod has multiple containers, logs from the first container will be returned.
`tail`	No	Number of lines to show from the end of the logs.
`since_seconds`	No	Return logs newer than a relative duration in seconds.
`timestamps`	No	Include timestamps at the beginning of each line. Default is False.

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description does not add behavioral details such as log format, truncation limits, or response structure, but it is consistent and does not contradict annotations.

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

Conciseness5/5

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

Single, focused sentence with no redundant wording. Front-loaded with verb and resource types.

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 an 8-parameter read tool with complete schema coverage and annotations, the description provides essential context. Missing mention of return value format (e.g., text stream) but schema fills most gaps.

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

Parameters3/5

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

Schema coverage is 100% with detailed parameter descriptions. The tool description (one sentence) does not add extra meaning beyond paraphrasing the schema. Baseline score of 3 is appropriate.

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

Purpose4/5

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

The description clearly states the tool retrieves logs from multiple resource types (pods, deployments, jobs) and via label selector. It distinguishes from sibling 'get_pod_logs' by mentioning broader resources, but does not explicitly contrast them.

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 like 'get_pod_logs'. The description lacks context about prerequisites, filtering, or use cases.

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

get_pod_logsGet Pod LogsC

Read-onlyIdempotent

Get logs from a pod in a specified namespace

ParametersJSON Schema

Name	Required	Description
`namespace`	Yes	The Kubernetes namespace where the pod is located.
`pod_name`	Yes	The name of the pod to get logs from.
`container`	No	The container name within the pod. If not specified and the pod has multiple containers, logs from the first container will be returned.
`tail_lines`	No	Number of lines to show from the end of the logs. If not specified, all logs will be returned.
`previous`	No	If true, return logs from a previous instantiation of the container. Default is False.

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds no behavioral details beyond what annotations provide, such as log format or streaming behavior.

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

Conciseness4/5

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

The description is a single sentence, concise and front-loaded. It could include more detail without becoming verbose.

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

Completeness2/5

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

The description is insufficient given the tool's complexity and lack of output schema. It does not mention return format, log tailing behavior, or how multi-container pods are handled beyond what the schema covers.

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 thoroughly describes each parameter. The description does not add additional semantic meaning beyond the schema.

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

Purpose4/5

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

The description clearly states the tool retrieves logs from a pod in a namespace. However, it does not differentiate from the sibling 'get_logs' tool, which may have overlapping functionality.

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 on when to use this tool versus alternatives like 'get_logs' or 'get_events'. The description lacks context for when this tool is appropriate.

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

get_resourceGet ResourceA

Read-onlyIdempotent

Get a single resource of any kind (including CRDs) by name via the dynamic client. GET only; never mutates.

ParametersJSON Schema

Name	Required	Description	Default
`kind`	Yes	Resource kind, e.g. 'Pod', 'ConfigMap', 'MyCustomResource'.
`name`	Yes	The resource name.
`api_version`	No	Group/version, e.g. 'v1' (default) or 'apps/v1'.	v1
`namespace`	No	Namespace for namespaced resources.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover read-only, non-destructive, idempotent behavior. The description adds useful context about using the dynamic client and supporting CRDs, but no additional behavioral traits beyond what annotations provide.

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

Conciseness5/5

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

The description is extremely concise, using two short sentences that directly convey purpose and behavior with no unnecessary 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?

Given the tool's simplicity, the rich annotations, and complete schema, the description adequately covers all necessary information. No output schema is needed.

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% with detailed descriptions for all 4 parameters. The description does not add any parameter-specific meaning beyond what is already in 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 it gets a single resource of any kind, including CRDs, via the dynamic client. It distinguishes from sibling tools like list_resource (plural) and specialized getters like get_events by emphasizing generic use.

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 implies it is the generic getter for any resource, which is clear from context. However, it does not explicitly provide when-not-to-use or list alternatives, leaving some room for interpretation.

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

list_api_resourcesList API ResourcesA

Read-onlyIdempotent

Discover which resource kinds (including CRDs) the cluster exposes and can be listed. Read-only discovery.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds 'Read-only discovery', which aligns with annotations but does not introduce new behavioral traits. No contradiction.

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, well-structured sentence that front-loads the key action and purpose. Every word adds value with no redundancy.

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 simple tool with no parameters and no output schema, the description combined with annotations provides complete context for an agent to understand and invoke the tool correctly.

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 no parameter documentation is needed. The description appropriately adds no parameter information, and with 100% schema coverage, the baseline of 4 is justified.

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 uses the verb 'discover' with the resource 'which resource kinds (including CRDs) the cluster exposes and can be listed', distinguishing it from sibling list tools that filter to specific resources like deployments or 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 usage for discovering available resource kinds, but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. The purpose is clear but lacks direct guidance.

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

list_deploymentsList DeploymentsB

Read-onlyIdempotent

List all deployments in a specified namespace

ParametersJSON Schema

Name	Required	Description	Default
`namespace`	No	The Kubernetes namespace to list deployments from. If not provided, deployments from all namespaces will be listed.

TDQS

B3.2/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds no behavioral traits beyond listing deployments. No mention of pagination, ordering, rate limits, or authorization requirements.

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?

Single sentence, front-loaded with verb and resource. No superfluous words. Efficiently communicates the core purpose.

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 list tool with good annotation coverage and fully described parameters, the description is nearly complete. However, it lacks explicit mention of the default behavior (all namespaces) which is only 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% and the schema clearly describes the namespace parameter (optional, default null, all namespaces if not provided). The description adds minimal extra meaning, only restating 'in a specified namespace'. 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 clearly states the verb 'list' and the resource 'deployments', with scope 'in a specified namespace'. It distinguishes from sibling tools like list_pods (different resource). However, it could explicitly mention that omitting namespace lists all namespaces (though the schema covers this).

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 on when to use this tool vs alternatives. No context on prerequisites or ideal use cases. The description is purely functional, leaving the agent to infer usage from context.

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

list_namespacesList NamespacesA

Read-onlyIdempotent

List all namespaces in the cluster

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare the tool as read-only, non-destructive, and idempotent. The description adds that it lists all namespaces cluster-wide, which is useful but not a significant behavioral disclosure beyond the annotations.

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 sentence with no wasted words. It is front-loaded and directly conveys the tool's purpose.

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 no parameters, no output schema, and low complexity, the description adequately covers what the tool does. It would be difficult to need more information for this simple tool.

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?

There are no parameters, so the description does not need to provide parameter details. Schema coverage is 100% and the description adds no further parameter info, which 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 clearly states the verb 'List' and the resource 'namespaces', and specifies the scope 'in the cluster'. It distinguishes from sibling tools like list_pods and list_nodes by targeting a different resource.

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 the tool should be used when needing to list all namespaces, but does not explicitly state when to use it versus alternatives or provide any exclusions. The sibling tool names provide context but the description lacks direct guidance.

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

list_nodesList NodesA

Read-onlyIdempotent

List all nodes in the cluster

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the scope 'in the cluster', clarifying the operation is on the entire cluster. No additional behavioral traits beyond what annotations provide are needed for such a simple tool.

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?

Single sentence (7 words) with no unnecessary information. Front-loaded with the key purpose.

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 is complete for a simple list tool with comprehensive annotations. It lacks details about the output format, but given the tool's simplicity and standard behavior, this is acceptable.

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?

There are no parameters, so the description doesn't need to add parameter information. Schema coverage is 100%, and baseline for zero params is 4.

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 action (list), resource (nodes), and scope (in the cluster). It distinguishes from sibling tools like list_pods by specifying the 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?

No guidance on when to use this tool vs alternatives. For example, it doesn't mention that get_resource should be used for listing individual nodes, or that this tool returns all nodes without filtering.

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

list_podsList PodsA

Read-onlyIdempotent

List all pods in a namespace or across all namespaces

ParametersJSON Schema

Name	Required	Description	Default
`namespace`	No	The Kubernetes namespace to list pods from. If not provided, pods from all namespaces will be listed.

TDQS

A4/5.0

Behavior4/5

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

Annotations already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety. The description adds value by specifying the namespace filtering behavior, which goes beyond the annotations. However, it does not disclose pagination or return format, but for a simple list operation this is acceptable.

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 with no unnecessary words. It is front-loaded and immediately conveys the essential 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?

Given the low complexity (one optional parameter) and the annotations providing safety context, the description adequately explains the tool's behavior. It lacks details on return format or pagination, but these are not critical for a simple list tool. The presence of sibling tools is not addressed, but overall it is sufficiently complete.

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% and the schema already describes the 'namespace' parameter fully. The description essentially restates the schema's description without adding new semantic meaning, so the baseline score 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?

Description clearly states the verb 'list', resource 'pods', and scope conditions (in a namespace or across all namespaces). It distinguishes from sibling tools like 'get_pod_logs' and 'list_deployments' which target different resources or actions.

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 implicitly indicates when to use the tool (to list pods), but provides no explicit guidance on when not to use it or how it compares to alternatives like 'get_events' or 'list_deployments'. With several sibling tools, more explicit differentiation would be helpful.

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

list_resourceList ResourceA

Read-onlyIdempotent

List resources of any kind (including CRDs) via the dynamic client. GET/LIST only; never mutates.

ParametersJSON Schema

Name	Required	Description	Default
`kind`	Yes	Resource kind, e.g. 'Pod', 'Ingress', 'MyCustomResource'.
`api_version`	No	Group/version, e.g. 'v1' (default) or 'networking.k8s.io/v1', 'apps/v1'.	v1
`namespace`	No	Namespace to scope to. If omitted, lists across all namespaces (or cluster-scoped).
`label_selector`	No	Label selector, e.g. 'app=nginx'.
`field_selector`	No	Field selector, e.g. 'metadata.name=foo'.

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description reinforces these by stating 'never mutates' and adds minor context about the dynamic client, but does not reveal additional behavioral traits beyond what annotations provide.

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

Conciseness5/5

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

The description is a single sentence that efficiently conveys the core purpose and behavior. Every word adds value, and it is front-loaded with the most important 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?

Given the simplicity of the tool (list resources), the description covers the essential purpose and safety. However, it lacks details about output format or pagination, which could be helpful. Still, it is largely complete for its complexity level.

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 adequately. The tool description does not add new parameter semantics beyond what is in the schema, meeting the baseline of 3.

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 action ('List'), the resource scope ('any kind including CRDs'), and the method ('via the dynamic client'). It distinguishes from sibling tools like list_pods by emphasizing broad resource support.

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 notes that the tool only performs GET/LIST and never mutates, providing clear context for when to use it. However, it does not explicitly guide against using this tool when a more specific listing tool (e.g., list_pods) would be appropriate.

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

list_servicesList ServicesA

Read-onlyIdempotent

List all services in a namespace or across all namespaces

ParametersJSON Schema

Name	Required	Description	Default
`namespace`	No	The Kubernetes namespace to list services from. If not provided, services from all namespaces will be listed.

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description doesn't need to repeat that. However, it adds no further behavioral disclosure (e.g., pagination, authorization, or return format), so it does not exceed what annotations provide.

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

Conciseness5/5

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

The description is a single, well-structured sentence that immediately conveys the tool's purpose and scope. No unnecessary words 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 simple list tool with one optional parameter and annotations covering behavior, the description is fairly complete. It lacks mention of the return format (e.g., names vs. full details), but given the tool's simplicity and no output schema, this is a minor gap.

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% for the single parameter 'namespace', and the schema's description already explains its function. The tool description adds no additional detail beyond summarizing the parameter's role.

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 'List all services in a namespace or across all namespaces', specifying the verb 'list', the resource 'services', and distinguishing the two scopes. This effectively differentiates it from sibling tools like list_pods or list_nodes.

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 listing services but provides no explicit guidance on when to use this tool versus alternatives like list_pods or list_deployments. No exclusions or context for when not to use it is given.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation4/5

Most tools have distinct purposes, but get_logs and get_pod_logs have overlapping functionality; however, their descriptions clarify that get_logs is for broader resource types while get_pod_logs targets a specific pod, reducing ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscores (e.g., get_events, list_pods), making the set predictable and easy to navigate.

Tool Count5/5

With 11 tools, the server is well-scoped for a read-only Kubernetes interface, covering essential resources and operations without unnecessary bloat or omissions.

Completeness5/5

The set includes generic get_resource and list_resource for CRDs, plus specific tools for common resources, logs, events, and API discovery, providing comprehensive read-only coverage without obvious gaps.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp A
com.googleapis.container
Provides read access to your GKE and Kubernetes resources.
Cloud Platforms Virtualization Monitoring
232
SearchConsole.ai
ai.searchconsole
Read-only Search Console analytics, URL inspection, indexing diagnostics, and sitemaps.
Search Monitoring
2
QueryBear
io.github.spencerpauly
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Databases RAG Systems
2
Evidra
io.github.vitas
Fail-closed policy guardrails for AI agents running kubectl, terraform, helm, and argocd.
Autonomous Agents Security Cloud Platforms
2

Related MCP Servers

mcp-kubernetes-ro
Monitoring Cloud Platforms Developer Tools
patrickdappollonio
A
license
Not graded
quality
B
maintenance
Provides read-only access to Kubernetes clusters for AI assistants.
Updated 3 months ago (2026-06-17 18:01 UTC)
23
MIT
homelab-mcp
Virtualization Developer Tools
Michael-WhiteCapData
A
license
B
quality
B
maintenance
Enables AI agents to inspect and operate a Kubernetes cluster safely, with read-only mode and namespace allowlist for mutations.
Updated 2 months ago (2026-06-23 02:07 UTC)
10
2
MIT
k8s-readonly-mcp
Cloud Platforms Monitoring
ziyuyu23
A
license
A
quality
C
maintenance
A read-only MCP server for inspecting Kubernetes clusters, allowing LLMs to list resources, describe pods, and read logs without mutation.
Updated a month ago (2026-07-21 17:44 UTC)
5
MIT
Claude Ops Investigator
Monitoring Observability
Randhir123
F
license
Not graded
quality
B
maintenance
Enables read-only Kubernetes incident investigation through MCP tools for listing pods, describing resources, fetching logs, and searching runbooks.
Updated 2 months ago (2026-07-16 13:28 UTC)
1

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

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