vmware-vks

create_tkc_cluster

Provision a Tanzu Kubernetes Cluster in a vSphere Namespace. Preview the blast radius and YAML first, then confirm to create.

Instructions

[WRITE] Create a TanzuKubernetesCluster in a vSphere Namespace.

Without confirm=True this only previews: it returns blast_radius (node counts, VM class, the YAML manifest, and whether the name is taken) and creates nothing. Show it to the user and get their decision. Do not set confirm=True on your own because the user asked earlier — they have not seen the preview yet. confirm=True returns {action: "created", name, namespace, status: "creating", yaml, blast_radius} and provisions in the background — poll get_tkc_cluster until phase is running. Refused when the name is taken or the namespace's clusters could not be read. Call get_tkc_available_versions for k8s_version and list_vm_classes first.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	Cluster name.
`target`	No	vCenter in config.yaml; omit for the default.
`confirm`	No	False (default) returns the blast radius and changes nothing. True applies it.
`dry_run`	No	Deprecated alias for confirm; removed in the next minor release. dry_run=False acts, dry_run=True previews.
`vm_class`	Yes	Node sizing, e.g. 'best-effort-large'.
`namespace`	Yes	Must already exist (see list_namespaces).
`k8s_version`	Yes	e.g. 'v1.28.4+vmware.1'.
`worker_count`	No	Worker nodes (>= 1).
`storage_class`	No	Storage class.	vsphere-storage
`control_plane_count`	No	1 or 3.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv1.11.0Sep 20, 2026

addedInput schema / properties / confirm

Added value: +{
+  "default": false,
+  "description": "False (default) returns the blast radius and changes nothing. True applies it.",
+  "title": "Confirm",
+  "type": "boolean"
+}

addedInput schema / properties / dry_run / anyOf

Added value: +[
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / dry_run / default
```
Previous value: -trueNew value: +null
```

changedInput schema / properties / dry_run / description

Previous value: -"YAML plan only (default: True)."New value: +"Deprecated alias for confirm; removed in the next minor release. dry_run=False acts, dry_run=True previews."

removedInput schema / properties / dry_run / type
```
Removed value: -"boolean"
```

Changed10 schema fields changedv1.8.14Aug 30, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- addedInput schema / properties / control_plane_count / description
```
Added value: +"1 or 3."
```
- addedInput schema / properties / dry_run / description
```
Added value: +"YAML plan only (default: True)."
```
- addedInput schema / properties / k8s_version / description
```
Added value: +"e.g. 'v1.28.4+vmware.1'."
```
- addedInput schema / properties / name / description
```
Added value: +"Cluster name."
```
- addedInput schema / properties / namespace / description
```
Added value: +"Must already exist (see list_namespaces)."
```
- addedInput schema / properties / storage_class / description
```
Added value: +"Storage class."
```
- addedInput schema / properties / target / description
```
Added value: +"vCenter in config.yaml; omit for the default."
```
- addedInput schema / properties / vm_class / description
```
Added value: +"Node sizing, e.g. 'best-effort-large'."
```
- addedInput schema / properties / worker_count / description
```
Added value: +"Worker nodes (>= 1)."
```
Addedv1.5.26May 20, 2026
Removedv1.5.23May 20, 2026
First observedv1.3.2Mar 27, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Even with annotations present, the description adds critical behavioral context: without confirm=True the tool only previews and changes nothing; confirm=True provisions in the background and returns {action: 'created', status: 'creating'}, requiring polling of get_tkc_cluster until running. It also discloses refusal behavior when the name is taken or namespace clusters cannot be read. This goes well beyond the annotation signals.

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 dense but every sentence earns its place: it covers purpose, preview semantics, user-approval requirement, confirmation behavior, polling, refusal conditions, and prerequisites. The critical safety warning is front-loaded early. The length is justified by the complexity and the severe consequence of an unconfirmed create.

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 complexity, the description is comprehensive: it explains return values for both modes, background provisioning, polling expectations, refusal cases, and required setup calls. The input schema covers parameter defaults and types, while the description covers the behavioral contract. Nothing essential for safe invocation is missing.

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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by linking k8s_version and vm_class to prerequisite calls (get_tkc_available_versions and list_vm_classes), and by clarifying the behavioral significance of confirm. It does not restate the schema, but it enriches the most safety-critical parameter without covering every field.

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 opens with a clear [WRITE] marker and explicitly states the action: 'Create a TanzuKubernetesCluster in a vSphere Namespace.' This distinguishes it from sibling tools that scale, upgrade, delete, or list clusters. The purpose is immediately unambiguous and the tool's resource is precisely named.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives strong operational guidance: it explains the preview-then-confirm flow, warns 'Do not set confirm=True on your own because the user asked earlier', and instructs the agent to show the preview to the user first. It also states prerequisites ('Call get_tkc_available_versions for k8s_version and list_vm_classes first') and refusal conditions. This is explicit when-and-how-to-use guidance.

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

create_tkc_cluster

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools