Provides tools for exploring Kubernetes enhancement proposals (KEPs), contributor guidelines, and official documentation, enabling AI assistants to search and read design documents and community resources.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@k8s-dev-mcp List KEPs for SIG scheduling"
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.
An MCP server that gives AI assistants access to Kubernetes enhancement proposals (KEPs), contributor guidelines, and official documentation.
Provides 7 tools over the Model Context Protocol:
Tool | Description |
| List and filter KEPs by SIG, status, or search query |
| Read a full KEP design document by number |
| Read KEP metadata (status, milestones, feature gates) |
| List available convention/guideline documents |
| Read a document, optionally a specific section |
| List section headings in a document |
| Full-text search across all repos |
Documents are sourced from three Kubernetes repos using sparse git checkouts:
kubernetes/enhancements — KEPs
kubernetes/community — contributor guidelines (API conventions, controller patterns, etc.)
kubernetes/website — official docs (API concepts, CRDs, server-side apply, etc.)
Related MCP server: code-intel MCP Server
Node.js 18+
Git
ripgrep (rg) — optional, falls back to grep for full-text search
claude mcp add k8s-dev-mcp npx github:Jefftree/k8s-dev-mcpgemini mcp add k8s-dev-mcp npx github:Jefftree/k8s-dev-mcpAdd to your MCP client config:
{
"mcpServers": {
"k8s-dev-mcp": {
"command": "npx",
"args": ["github:Jefftree/k8s-dev-mcp"]
}
}
}Repos and documents are defined in the bundled config.yaml. Override it by setting:
export K8S_CONTEXT_CONFIG=/path/to/custom/config.yamlVariable | Description |
| Path to a custom config.yaml |
| Cache directory for cloned repos (default: |
npm install
npm run build
npm startApache 2.0
List available Kubernetes convention and guideline documents.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must bear the full burden of transparency. 'List' implies a read-only, non-destructive operation, which is clear. However, no additional behavioral traits (e.g., authentication requirements, rate limits, pagination) are disclosed. The description is adequate for a simple list but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It conveys the essential information concisely, with no redundancy. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and is a simple list, the description is minimally complete. However, it does not explain what each list item contains (e.g., just names, or also descriptions?). For a new user, this might be ambiguous. Additional context on return format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema description coverage is 100%. The description does not need to add parameter semantics since none exist. The baseline for zero parameters is 4, and the description meets that standard.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List available Kubernetes convention and guideline documents' uses a specific verb ('List') and resource ('available Kubernetes convention and guideline documents'). It clearly distinguishes this tool from siblings like 'list-doc-sections' (sections within a doc) and 'list-keps' (KEPs), leaving no ambiguity about what it returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool to see available documents. However, there is no explicit guidance on when to use this tool versus alternatives, nor any 'when not to use' or prerequisites. The simplicity of a parameterless list reduces the need for such guidance, but a more explicit mention of alternatives like 'For documents with sections, use list-doc-sections' would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List section headings in a document.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Doc name, e.g. "api-conventions" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits (e.g., read-only, performance, limitations). A read operation is implied but not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant words. Information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool with one parameter and no output schema, but could include output structure or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (single parameter 'name' well-described). The tool description adds no additional meaning beyond the schema, meeting baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List section headings in a document.' clearly states the verb (list), resource (section headings), and scope (in a document), distinguishing it from sibling tools like list-docs and read-doc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs alternatives (e.g., when to prefer list-doc-sections over read-doc or list-docs). The description lacks exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Kubernetes Enhancement Proposals. Filter by SIG name, status, or search query.
| Name | Required | Description | Default |
|---|---|---|---|
| sig | No | Filter by SIG name, e.g. "scheduling", "api-machinery" | |
| query | No | Search KEP titles, feature gate names, or KEP numbers | |
| status | No | Filter by status: "provisional", "implementable", "implemented" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, pagination, or rate limits, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that efficiently communicates the tool's purpose and parameters with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with optional filters and no output schema, the description adequately covers the core functionality, though it could mention that it returns a list of KEPs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all three parameters with descriptions; the description merely restates the filter options, adding minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List Kubernetes Enhancement Proposals' and mentions filtering capabilities, distinguishing it from sibling tools like list-docs and read-kep.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like read-kep or search-k8s-docs; the agent must infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a Kubernetes convention/guideline document, optionally a specific section.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Doc name from list-docs, e.g. "api-conventions" | |
| section | No | Optional section heading, e.g. "Validation" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It only states the action 'Read' and optional section, without detailing return format, potential errors, or any side effects. The description adds minimal behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose without any fluff. Every word serves a purpose, making it optimally concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description omits what the tool returns (e.g., text format). However, for a read operation, the purpose is clear, and the parameter examples fill gaps. It is minimally adequate but could clarify return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, and the description adds valuable context with concrete examples ('Doc name from list-docs, e.g. "api-conventions"' and 'Optional section heading, e.g. "Validation"'), enhancing understanding beyond the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'Kubernetes convention/guideline document', and specifies optional section reading. It effectively distinguishes from sibling tools like 'read-kep' (which reads a different document type) and 'list-docs' (which lists rather than reads).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives. It does not mention prerequisites, when to avoid using it, or direct comparisons to sibling tools like 'list-docs' or 'read-kep'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the full KEP design document (README.md) by its number.
| Name | Required | Description | Default |
|---|---|---|---|
| kepNumber | Yes | The KEP number, e.g. 4008 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full responsibility. It only states it reads a document but does not disclose any behavioral traits such as read-only nature, network fetch, or pagination. The term 'full' implies complete content but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no wasted words. Efficiently conveys the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read operation, the description is mostly complete. It explains what is read and how to specify it. Minor omissions (output format, constraints) but acceptable for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with parameter 'kepNumber' already described as 'The KEP number, e.g. 4008'. The description adds 'by its number' which reinforces but does not add substantial new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (Read), the resource (full KEP design document, specifically README.md), and the method of identification (by number). It distinguishes from siblings like list-keps and read-kep-metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like read-kep-metadata or read-doc. The description does not provide context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read kep.yaml metadata: status, milestones, feature gates, authors.
| Name | Required | Description | Default |
|---|---|---|---|
| kepNumber | Yes | The KEP number, e.g. 4008 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It states what is read but does not explicitly declare the tool as read-only, nor does it mention any behavioral traits (e.g., no side effects, auth needs). Minimal transparency beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb and resource, no wasted words. Extremely efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with no output schema, the description covers the basic purpose and output fields. It could mention read-only nature or return format, but is mostly complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (parameter 'kepNumber' described as 'The KEP number, e.g. 4008'). The description adds no extra meaning for the parameter, only lists output fields. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'kep.yaml metadata', listing specific fields (status, milestones, feature gates, authors). This distinguishes it from sibling tools like 'read-kep' (full document) and 'list-keps' (listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the purpose (read metadata vs. full content), but there is no explicit guidance on when to use this tool versus alternatives like 'read-kep' or 'search-k8s-docs'. No when-not-to or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across all configured Kubernetes repos (enhancements, community, website).
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Limit to a specific repo, e.g. "enhancements", "community", "website" | |
| query | Yes | Search query (regex supported) | |
| maxResults | No | Maximum results (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states it searches repos; lacks details on read-only nature, rate limits, return format, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key verb and scope, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple search tool, but missing output format, pagination info, and usage context for regex and default maxResults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add extra meaning beyond the schema (e.g., regex support is mentioned in schema, not description).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states full-text search across Kubernetes repos, listing examples (enhancements, community, website). It distinguishes from sibling tools like list-docs and read-kep which are for listing or reading specific documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied that this tool is for searching across repos, but no explicit guidance on when to use vs siblings (e.g., list-docs, list-keps) or when not to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0list-doc-sectionslist-docslist-kepsread-docread-kepread-kep-metadatasearch-k8s-docsEach tool targets a distinct operation: listing vs reading vs searching, and documents vs KEPs vs metadata. There is no overlap or ambiguity.
Tools follow a verb-noun pattern with hyphens (list-, read-, search-). Minor inconsistencies like plural 'docs' vs singular 'doc' and use of 'k8s' abbreviation exist, but overall pattern is clear.
7 tools is well-scoped for the domain of Kubernetes documentation and KEPs, covering listing, reading, searching, and metadata access without bloat.
The tool set covers the full range of expected operations for a read-only documentation server: listing, reading, searching, and retrieving metadata. No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
Versioned documentation registry and semantic search for AI tools and coding assistants.
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.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jefftree/k8s-dev-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
