What can you do with this server?

This server provides read-only inspection of a Kubernetes cluster via the Model Context Protocol (MCP), allowing an LLM to safely query cluster state without any ability to mutate resources. * list_namespaces: Retrieve all namespaces in the cluster. * list_pods: List pods in a specific namespace (defaults to default) or across all namespaces by passing 'all'. * describe_pod: Get detailed status, events, and configuration for a specific pod by name and namespace. * get_pod_logs: Fetch the last N lines of logs (default: 100) from a specific pod. * list_deployments: View deployments in a namespace along with their ready and up-to-date statuses.

Which integrations are available for this server?

Provides read-only access to inspect Kubernetes clusters, including listing pods, reading logs, describing resources, and checking deployments, while preventing any mutations.

How do I use k8s-readonly-mcp?

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., "@k8s-readonly-mcp list all pods in the kube-system namespace" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

k8s-readonly-mcp

by ziyuyu23

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

k8s-readonly-mcp

A read-only Model Context Protocol (MCP) server that lets an LLM inspect a Kubernetes cluster — list pods, read logs, describe resources — but never mutate it.

Why I built it

I spend a lot of time embedded in customer Kubernetes environments. The most common thing I want from an LLM is "help me understand what's happening in this cluster" — without ever giving it the ability to change anything. So I built the safety in structurally rather than trusting the model to behave.

Every tool call routes through a single function that checks the kubectl verb against an allow-list of read-only verbs (get, describe, logs, top, …). There is no code path that can apply, delete, scale, or exec. If the model asks for a mutation, the server refuses. This is the same least-privilege, human-in-the-loop instinct that any production agent needs.

Related MCP server: kubernetes-mcp

What it does

Tool	Description
`list_namespaces`	List all namespaces
`list_pods`	List pods in a namespace (or all namespaces)
`describe_pod`	Full status, events, and config for one pod
`get_pod_logs`	Last N lines of a pod's logs
`list_deployments`	Deployments and their ready/up-to-date status

Quick start

Prerequisite: kubectl must be installed and on your PATH.

# 1. Install (using uv — https://docs.astral.sh/uv/)
uv sync

# 2. Make sure kubectl points at a cluster.
#    A local cluster is perfect for trying this safely:
#    kind create cluster   (or: minikube start)
kubectl get nodes

# 3. Run the server
uv run k8s-readonly-mcp

Connect it to Claude Desktop

Add this to your Claude Desktop MCP config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{
  "mcpServers": {
    "k8s-readonly": {
      "command": "uv",
      "args": ["--directory", "/absolute/path/to/k8s-readonly-mcp", "run", "k8s-readonly-mcp"]
    }
  }
}

Then ask Claude things like "What pods are failing in the default namespace, and why?" — it will call list_pods and describe_pod, reason over the output, and explain — but it physically cannot change your cluster.

Design decisions

Allow-list, not block-list. I enumerate what's permitted rather than trying to block bad verbs. A block-list is one forgotten verb away from a mutation; an allow-list fails closed.
One chokepoint. All kubectl execution goes through _run_kubectl. The security boundary is one function you can audit in 30 seconds.
Timeouts and clear errors. Calls time out and surface kubectl's stderr instead of hanging or failing silently — the model gets actionable feedback.

What I'd do next

Add resource-level scoping (restrict to specific namespaces per connection).
Stream large log outputs instead of buffering.
Add a small eval that checks the server refuses every mutating verb.

License

MIT — see LICENSE.

Available Tools

5 tools

describe_podA

Show detailed status, events, and configuration for a single pod.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`namespace`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

The description describes read-only behavior ('Show detailed status...'), which aligns with the typical use. However, it lacks details on permissions, error handling, or side effects. Given no annotations, the description carries full burden but offers limited transparency beyond the obvious.

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 target, no wasted words. Efficiently communicates the tool's core function.

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 is simple and an output schema exists, reducing the need for return value details. However, missing context like availability of pod details or error scenarios keeps it from being fully comprehensive. Still adequate for a straightforward describe operation.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It implies the pod name is needed ('single pod') but does not explain the namespace parameter, default value, or provide examples. This leaves the agent with minimal guidance beyond the schema field names and types.

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 'Show' with specific details: 'detailed status, events, and configuration' for a single pod. It distinguishes from sibling tools like list_pods or get_pod_logs by focusing on a single pod's comprehensive details.

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?

No explicit guidelines on when to use or alternatives are provided. The description implies it is for inspecting a single pod, but does not mention when to prefer list_pods for all pods or get_pod_logs for logs require this tool.

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

get_pod_logsB

Fetch the last N lines of logs for a pod (default 100 lines).

ParametersJSON Schema

Name	Required	Default
`name`	Yes
`tail`	No
`namespace`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It only mentions fetching 'last N lines' and the default, but omits critical traits such as: whether logs are streamed or retrieved once, handling of pod not found, impact on the system, or any rate limits. This is insufficient for a tool with no annotation safety net.

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, efficient sentence with no filler. It is front-loaded with the key action and parameter guidance, earning 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?

Given the tool has 3 parameters and an output schema, the description is minimal. It does not explain that namespace defaults to 'default' or provide usage context (e.g., debugging). While the output schema reduces the need to describe returns, the description could be more complete for a straightforward log-fetching 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 0%, so the description must add meaning. It explains 'tail' (last N lines) and implicitly ties 'name' to a pod, but does not mention the 'namespace' parameter at all. While it partially compensates for the missing schema descriptions, it leaves one of three parameters undocumented.

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 fetches the last N lines of logs for a pod, with a default of 100 lines. This specific verb-resource combination distinguishes it from sibling tools like describe_pod (pod details) and list_pods (pod listing).

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 like describe_pod or list_pods. It lacks context about troubleshooting vs. general log monitoring, and does not mention prerequisites or exclusions.

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

list_deploymentsB

List deployments in a namespace and their ready/up-to-date status.

ParametersJSON Schema

Name	Required	Description	Default
`namespace`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

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. It only mentions listing and status but does not disclose any behavioral traits such as pagination, permissions, or behavior when namespace is empty or invalid.

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 11 words, no superfluous information. It is front-loaded and efficient.

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?

Given the tool has an output schema, the description does not need to explain return values. However, it lacks detail on scope (e.g., all deployments or filtered), and the minimal parameter information. It is adequate but not comprehensive.

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 0% schema coverage and one parameter (namespace), the description implies its purpose by stating 'in a namespace', but it does not clarify the default value or that it is optional. The description adds some meaning beyond the schema but not enough to be highly informative.

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 the specific resource (deployments) and action (list), and adds that it includes status information. It clearly distinguishes from sibling tools that operate on pods or namespaces. However, it does not explicitly mention Kubernetes, which is implied by context.

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 list_pods or describe_pod. There is no mention of prerequisites, context, or exclusions.

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

list_namespacesA

List all namespaces in the cluster.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations, description carries full burden but only states 'List all namespaces', lacking details on permissions, rate limits, or behavior beyond the simple read operation.

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

Conciseness5/5

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

Single sentence, no wasted words, front-loaded with key 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?

For a simple list tool with no parameters and an output schema, the description is complete enough, though it could mention output format or behavior.

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?

No parameters exist, so schema coverage is 100%. Description adds no parameter info, but baseline is 4 for 0-param tools.

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 verb ('List'), resource ('namespaces'), and scope ('all in the cluster'). It distinguishes from sibling tools like describe_pod, list_pods, etc.

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. No context about prerequisites or when not to use it.

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

list_podsA

List pods in a namespace (defaults to 'default'). Use 'all' for every namespace.

ParametersJSON Schema

Name	Required	Description	Default
`namespace`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description bears full burden. It conveys that the tool is a read-like operation listing pods, and discloses the special 'all' behavior. This is sufficient for a simple list tool, though it could mention authentication or rate limits.

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 concise with two sentences, front-loaded with the main action. Every sentence contributes; no wasted words.

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 (1 parameter, simple output) and presence of an output schema, the description is complete enough. It covers core functionality, default behavior, and special values.

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?

Schema coverage is 0%, but the description adds value beyond the schema by explaining the default value ('default') and the special 'all' usage. This compensates for the lack of schema-level parameter documentation.

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 lists pods in a namespace, with a default namespace and a special 'all' value. This distinguishes it from siblings like list_namespaces and list_deployments, though it doesn't explicitly differentiate them.

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 provides implicit usage guidance by specifying the default namespace and the 'all' option, but it lacks explicit when-to-use or when-not-to-use instructions compared to sibling tools.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Jun 25, 2026
- First observeddescribe_pod
- First observedget_pod_logs
- First observedlist_deployments
- First observedlist_namespaces
- First observedlist_pods

Install Server

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

TDQS

A3.7/5.0

Scored 2026-06-25 23:00 across 5 tools

Disambiguation5/5

Each tool targets a distinct Kubernetes resource or operation: describe_pod for pod details, get_pod_logs for logs, list_deployments for deployments, list_namespaces for namespaces, list_pods for pods. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., list_pods, describe_pod, get_pod_logs) using snake_case throughout, making them predictable and easy to understand.

Tool Count5/5

With 5 tools, the server is well-scoped for a read-only Kubernetes interface. It provides essential operations without unnecessary bloat, fitting the typical 3-15 tool range.

Completeness3/5

While core pod and deployment listing is covered, the server lacks operations for other common Kubernetes resources like services, nodes, events, or configmaps, which are expected in a read-only toolset.

Maintenance

ActivitySlowing

ResponsivenessNo issues

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

turva-mcp A
dev.turva
Read-only MCP server for turva.dev, an agent-readiness audit and advisory service.
Autonomous Agents Developer Tools Security
52
Google GKE A
com.googleapis.container
The Google GKE MCP server is a managed Model Context Protocol server that provides AI applications with tools to manage Google Kubernetes Engine (GKE) clusters and Kubernetes resources. It exposes a structured, discoverable interface that allows AI agents to interact with GKE and Kubernetes APIs, enabling them to inspect cluster configurations, retrieve Kubernetes resource YAMLs, monitor operations like cluster upgrades, diagnose issues, and optimize costs—all without needing to parse text output or use complex kubectl commands.
Cloud Platforms Virtualization Observability
232
Cortex C
io.cortex.mcp
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Developer Tools Monitoring Observability
312
HubSpotOAuth
com.hubspot.app
The HubSpot MCP Server acts as a bridge that enables AI assistants and Large Language Models to securely interact with HubSpot CRM data through natural conversation, without requiring users to understand complex API structures. It provides read-only access to standard CRM objects (contacts, companies, deals, tickets, products, invoices, and more) and their associations, secured via OAuth 2.0, allowing AI agents to perform tasks like summarizing deals, fetching company updates, and looking up record changes.
Customer Data Platforms Databases Marketing
3

Related MCP Servers

Kubernetes Monitor
Observability Shell Access
vlttnv
A
license
Not graded
quality
D
maintenance
A read-only MCP server for Kubernetes that allows querying cluster information and diagnosing issues through natural language interfaces like Claude.
Updated a year ago (2025-03-15 14:25 UTC)
8
MIT
kubernetes-mcp
Virtualization Observability
kkb0318
A
license
Not graded
quality
C
maintenance
A Model Context Protocol (MCP) server that provides safe, read-only access to Kubernetes resources for debugging and inspection. Built with security in mind, it offers comprehensive cluster visibility without modification capabilities.
Updated a year ago (2025-06-27 13:31 UTC)
43
MIT
Kubernetes Tools MCP Server
Code Execution Developer Tools Observability
BenedatLLC
A
license
A
quality
C
maintenance
Provides a set of read-only Kubernetes functions via an MCP server, enabling interaction with Kubernetes clusters through agents or coding assistants like GitHub Copilot.
Updated 4 days ago (2026-09-06 23:04 UTC)
9
3
Apache 2.0
k8s-mcp-assistant
Monitoring Developer Tools Observability
nicolasmosquerar
F
license
B
quality
D
maintenance
A read-only Kubernetes MCP server that enables developers to inspect app status, view pod events, and fetch container logs from dev clusters without requiring full kubectl access.
Updated 6 months ago (2026-03-21 17:48 UTC)
2
4
-