A Kubernetes MCP (Model Context Protocol) server that enables interaction with Kubernetes clusters through MCP tools. It supports stdio, SSE, and Streamable HTTP transport modes.
Static source inference · medium confidence · evidence: structured output
No deprecated protocol patterns detected
Summary
The Kubernetes MCP server provides 16 well-named tools with consistent verb-noun naming (get_, list_, create_, update_, delete_, install_, upgrade_, uninstall_, add_, remove_). Tool descriptions are present and range from 60-120 characters, meeting the minimum threshold. Input schemas are visible and include type definitions and parameter descriptions for all tools. However, there are notable gaps: (1) Output schemas are not documented, callers cannot see what fields to expect from responses, which breaks the tool-chaining principle; (2) Several descriptions lack WHEN/WHY context and dependency hints; (3) Parameters like 'manifest' in create_resource and update_resource lack format constraints (JSON is stated but not enforced in schema); (4) Error handling guidance is absent, tools do not describe recovery paths or retryability; (5) No tool annotations (readOnlyHint, destructiveHint) are present despite clear risk stratification (READ_ONLY, WRITE, DESTRUCTIVE); (6) Kubernetes-specific parameters like 'labelSelector' and 'fieldSelector' lack format documentation; (7) The 'tail_lines' parameter in get_pod_logs is typed as string but should be integer. These gaps prevent optimal LLM reasoning and composition.
Tools (16)
add_helm_repowritesource verified72/100
Add a Helm repository
create_resourcewritesource verified73/100
Create a new resource
delete_resourcedestructivesource verified80/100
Delete a resource
get_api_resourcesread onlysource verified85/100
Get all supported API resource types in the cluster, including built-in resources and CRDs
get_helm_releaseread onlysource verified78/100
Get detailed information about a specific Helm release
get_pod_logsread onlysource verified73/100
Retrieve logs from a specific pod
get_resourceread onlysource verified82/100
Get detailed information about a specific resource
Output schemas are completely undocumented. Callers cannot determine what fields, types, or structure responses will contain. This breaks tool composition and forces LLMs to guess at downstream parameters.
No tool annotations present despite clear risk stratification in metadata (READ_ONLY vs WRITE vs DESTRUCTIVE). Tools should include readOnlyHint, destructiveHint, and idempotentHint to guide LLM planning and safety.
Document output schemas for all 16 tools. For each, specify: response type (object/array), field names, types (string/integer/boolean/array/object), and which fields are required. Example: 'Returns: object with fields {resources: [{kind: string, namespaced: boolean, name: string, singularName: string, shortNames: [string]}], apiVersion: string}'
Add tool annotations: mark all READ_ONLY tools with readOnlyHint=true; mark delete_resource, uninstall_helm_chart, remove_helm_repo with destructiveHint=true; mark idempotent tools (create with idempotency key, update, list) with idempotentHint=true.
Add error recovery guidance to descriptions. Example for create_resource: 'If manifest is invalid, the error will describe which field failed and why. Common errors: namespace must exist, resource kind must be supported, manifest must be valid JSON. Call get_api_resources to discover valid kinds.'
Change 'tail_lines' parameter type from string to integer, add constraints: minimum=1, maximum=10000, default=50.
Expand labelSelector and fieldSelector descriptions: 'Kubernetes label selector format. Syntax: key=value for equality, key!=value for inequality, key in (v1,v2) for set membership. See: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/'
Add input validation and error messages for manifest parameters. Validate JSON structure before sending to Kubernetes API. Return error: 'manifest must be valid JSON. Received: <snippet>. Error: <json parse error>'
Enhance tool descriptions with context and dependencies. Example for update_resource: 'Updates an existing Kubernetes resource by kind, name, and namespace. Requires the full desired manifest, partial updates not supported. Call get_resource first to see the current state, modify it, then pass to update_resource.'
Error handling and recovery guidance absent. Tools do not describe what errors are retryable, what user actions can fix failures, or next steps. Pattern: error_classification recommends categorizing errors as retryable, user-fixable, or fatal.
Parameter 'tail_lines' in get_pod_logs is typed as string but semantically is an integer (count). Should be integer type with min/max bounds (e.g., 1-10000).
Kubernetes selector parameters (labelSelector, fieldSelector in list_resources) lack format documentation. Should specify syntax: 'Kubernetes label selector format: key1=value1,key2=value2. See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/'
Manifest parameters (create_resource, update_resource) state 'Only JSON is supported' in description but do not enforce it in schema. No format or pattern constraint visible. Should validate JSON structure server-side with clear error messages.
Descriptions lack WHEN/WHY context and dependency hints. For example, get_resource description does not explain when to call it vs list_resources, or that it requires knowing the resource kind in advance. Helm tools lack context on when to upgrade vs install.
Pagination not implemented for list_* tools. list_resources, list_events, list_helm_releases, list_helm_repos should return total_count and support limit/offset or cursor-based pagination. Without pagination, large result sets blow the context window.
Implement pagination for list_resources, list_events, list_helm_releases, list_helm_repos. Add parameters: limit (default 20, max 100), offset or cursor. Return: items array + total_count. Limit results to prevent context window exhaustion.
Document which tools are idempotent. Example: 'Installing a Helm chart that already exists is idempotent, calling this multiple times with the same name and version will not duplicate releases.'
Add permission/scope hints to destructive tools. Example: delete_resource description should note 'Requires delete permission for the resource kind and namespace.'
For get_pod_logs, document log format and chunking. Example: 'Returns raw container logs as a string. If logs are large, consider using tail_lines to limit the response. Logs may contain binary data for some containers.'
For install_helm_chart and upgrade_helm_chart, clarify the 'values' parameter format: 'YAML-formatted string of Helm values. Example: "replicaCount: 3\nimage.tag: v1.2.3". See chart's values.yaml for available options.'
Add dry-run or confirmation step to destructive tools (delete_resource, uninstall_helm_chart) to prevent accidental data loss.