vmware-vks

create_tkc_cluster

Creates a TanzuKubernetesCluster in a vSphere Namespace, first returning a preview and blast radius; provisions only after explicit confirmation.

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 and inspect its conditions/readiness. 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. Requires a discovered v1beta1 or v1beta2 API. Preview and apply run Supervisor admission with dryRun=All and strict field validation; rejection stops creation. v1beta2 requires an explicit installed cluster_class; use cluster_class_namespace for shared classes. No automatic rebase or variable conversion. vSphere/VCF 9.1 end-to-end deployment is not lab validated.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "namespace": "<namespace>",
      "k8s_version": "<k8s_version>",
      "vm_class": "<vm_class>"
    },
    "name": "create_tkc_cluster"
  }
}

Input 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.
`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).
`cluster_class`	No	Installed ClusterClass; required for v1beta2.
`storage_class`	No	Storage class.	vsphere-storage
`control_plane_count`	No	1 or 3.
`cluster_class_namespace`	No	Class namespace, e.g. vmware-system-vks-public.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv3.7.0Nov 10, 2026

addedInput schema / properties / cluster_class

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Installed ClusterClass; required for v1beta2.",
+  "title": "Cluster Class"
+}

addedInput schema / properties / cluster_class_namespace

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Class namespace, e.g. vmware-system-vks-public.",
+  "title": "Cluster Class Namespace"
+}

Changed1 schema field changedv3.4.2Oct 31, 2026

removedInput schema / properties / dry_run

Removed value: -{
-  "anyOf": [
-    {
-      "type": "boolean"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Deprecated alias for confirm; removed in the next minor release. dry_run=False acts, dry_run=True previews.",
-  "title": "Dry Run"
-}

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.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, openWorldHint=true and idempotentHint=false, so mutation and side effects are known; the description still adds real value by explaining what the preview returns, what confirm=True returns, that provisioning is asynchronous and must be polled, and that admission runs with dryRun=All. It also discloses real constraints (name collision refusal, v1beta2 cluster_class requirement, no automatic rebase, unvalidated 9.1 path). The score is 3 because it is dense but not distilled: a behavioral-trait list this long is better organized as explicit preview/apply/refusal sections than as a wall of prose.

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

Conciseness3/5

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

Front-loaded correctly with the core action and the preview caveat, but the body is a run-on stream where return-shape, polling, refusal, prerequisite, admission, v1beta2 and environment-caveat content all blend together. Several clauses are splittable (the return-shape sentence alone packs four fields plus background-provisioning instructions). It is information-dense rather than wasteful, but structure and scannability are compromised.

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?

For an 11-parameter, non-idempotent, asynchronous write tool with no output schema, the description covers what an agent needs: prerequisites, preview/apply duality, returned fields, poll target, failure conditions, API-version differences and known limitations. Nothing material about calling it correctly 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 earns an extra point by adding meaning the schema cannot express: k8s_version must be obtained from get_tkc_available_versions, cluster_class is mandatory under v1beta2, and cluster_class_namespace is for shared classes. It also clarifies confirm's two-mode semantics in context (preview returns blast_radius YAML and name-taken status), which ties that boolean to observable outcomes.

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?

Opens with a bracketed write marker and a specific verb+resource+scope: create a TanzuKubernetesCluster in a vSphere Namespace. The verb 'Create' plus the distinctive resource name cleanly separates it from get_tkc_cluster, delete_tkc_cluster, scale_tkc_cluster and upgrade_tkc_cluster without needing their schemas.

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?

Explicitly prescribes a two-phase flow (preview first, then confirm), warns against self-confirming based on an earlier user request, and names the prerequisites get_tkc_available_versions and list_vm_classes. It also states the refusal conditions (name taken, namespace unreadable), so an agent knows both when to call and when the call will fail.

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