mcp-server-kubernetes

Overview Schema Source Related Servers Discussions Admin

kubectl_create

Create Kubernetes resources from YAML manifests, files, or subcommand inputs, with options for dry-run validation, namespaces, labels, and output formats.

Instructions

Create Kubernetes resources using various methods (from file or using subcommands)

Input Schema

Name	Required	Description	Default
`name`	No	Name of the resource to create
`port`	No	Port that the container exposes
`image`	No	Image to use for the containers in the deployment
`dryRun`	No	If true, only validate the resource, don't actually execute the operation
`labels`	No	Labels to apply to the resource (e.g. ["key1=value1", "key2=value2"])
`output`	No	Output format. One of: json\|yaml\|name\|go-template\|template\|jsonpath\|jsonpath-as-json. The template formats take their template inline, e.g. 'jsonpath={.metadata.name}'.	yaml
`command`	No	Command to run in the container
`context`	No	Kubeconfig Context to use for the command (optional - defaults to null)
`suspend`	No	Whether to suspend the CronJob
`tcpPort`	No	Port pairs for tcp service (e.g. ["80:8080", "443:8443"])
`filename`	No	Path to a YAML file to create resources from. The path is read on the machine running the MCP server, so it is rejected when the server runs over a remote (SSE/Streamable HTTP) transport; use 'manifest' to pass the file's contents instead.
`fromFile`	No	Path to file for creating configmap/secret (e.g. ["key1=/path/to/file1", "key2=/path/to/file2"]). The path is read on the machine running the MCP server, so it is rejected when the server runs over a remote (SSE/Streamable HTTP) transport; use "fromFileContent" to pass file contents directly instead.
`manifest`	No	YAML manifest to create resources from
`replicas`	No	Number of replicas to create for the deployment
`schedule`	No	Cron schedule expression for the CronJob (e.g. "/5 * * *")
`validate`	No	If true, validate resource schema against server schema
`namespace`	No	Kubernetes namespace	default
`secretType`	No	Type of secret to create (generic, docker-registry, tls)
`annotations`	No	Annotations to apply to the resource (e.g. ["key1=value1", "key2=value2"])
`fromLiteral`	No	Key-value pair for creating configmap (e.g. ["key1=value1", "key2=value2"])
`serviceType`	No	Type of service to create (clusterip, nodeport, loadbalancer, externalname)
`resourceType`	No	Type of resource to create (namespace, configmap, deployment, service, etc.)
`fromFileContent`	No	Inline file contents for creating a configmap/secret, provided by the client instead of a server-side path (e.g. [{"key": "app.conf", "content": "..."}]). Safe on all transports; use this instead of "fromFile" on remote (SSE/Streamable HTTP) servers.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv4.2.1Oct 27, 2026

changedInput schema / properties / output / description

Previous value: -"Output format. One of: json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file"New value: +"Output format. One of: json|yaml|name|go-template|template|jsonpath|jsonpath-as-json. The template formats take their template inline, e.g. 'jsonpath={.metadata.name}'."

removedInput schema / properties / output / enum

Removed value: -[
-  "json",
-  "yaml",
-  "name",
-  "go-template",
-  "go-template-file",
-  "template",
-  "templatefile",
-  "jsonpath",
-  "jsonpath-as-json",
-  "jsonpath-file"
-]

Changed3 schema fields changedv4.0.2Jul 14, 2026

changedInput schema / properties / filename / description

Previous value: -"Path to a YAML file to create resources from"New value: +"Path to a YAML file to create resources from. The path is read on the machine running the MCP server, so it is rejected when the server runs over a remote (SSE/Streamable HTTP) transport; use 'manifest' to pass the file's contents instead."

changedInput schema / properties / fromFile / description

Previous value: -"Path to file for creating configmap (e.g. [\"key1=/path/to/file1\", \"key2=/path/to/file2\"])"New value: +"Path to file for creating configmap/secret (e.g. [\"key1=/path/to/file1\", \"key2=/path/to/file2\"]). The path is read on the machine running the MCP server, so it is rejected when the server runs over a remote (SSE/Streamable HTTP) transport; use \"fromFileContent\" to pass file contents directly instead."

addedInput schema / properties / fromFileContent

Added value: +{
+  "description": "Inline file contents for creating a configmap/secret, provided by the client instead of a server-side path (e.g. [{\"key\": \"app.conf\", \"content\": \"...\"}]). Safe on all transports; use this instead of \"fromFile\" on remote (SSE/Streamable HTTP) servers.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "content": {
+        "description": "The file content to store",
+        "type": "string"
+      },
+      "key": {
+        "description": "Key to store the content under in the configmap/secret",
+        "type": "string"
+      }
+    },
+    "required": [
+      "key",
+      "content"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Addedv1.0.0Jan 2, 2026

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description carries the full behavioral burden for a mutating cluster operation, and it discloses almost none of it: no mention that this writes to the cluster, that it fails if the resource already exists (vs. apply), permission/RBAC needs, or that dryRun and validate affect whether anything is actually persisted. Only the schema's own dryRun description hints at 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.

Conciseness4/5

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

A single compact sentence with no filler, front-loading the verb and resource. It is underspecified rather than bloated, so the size itself is appropriate for what little it attempts.

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?

For a 23-parameter mutating tool with zero annotations and no output schema, the description gives no guidance on how the parameters group (manifest vs. resourceType subcommand fields), which combinations are mutually exclusive, or what happens on conflict with an existing resource. The schema documents individual fields but nothing ties them into usable call patterns.

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% across all 23 parameters, so the schema already explains every field including the transport caveats on filename/fromFile. The description adds no param-level meaning of its own, which is the baseline 3 when the schema does all the work.

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?

"Create Kubernetes resources" is a specific verb+resource pair, and the parenthetical names the two creation modes (manifest/file vs. subcommand-driven fields). It does not differentiate itself from the obvious sibling kubectl_apply, which also creates/updates resources, so it stops short of a 5.

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?

"Using various methods (from file or using subcommands)" implies that the parameter set branches by creation mode, but it never states when to choose this tool over kubectl_apply or when each mode is appropriate. Usage is inferable rather than stated, and no exclusions are given.

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

Deploy Server

kubectl_create

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools