create_tkc_cluster

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

The description discloses the critical dry_run default behavior (returns YAML plan) and that setting dry_run=False applies the changes. It also marks the tool with '[WRITE]'. The annotations are minimal (readOnlyHint=false, destructiveHint=false), so the description adds significant behavioral context. No contradictions.

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 well-structured with a bold summary, important notes, workflow, and a bulleted list of arguments. It is concise and front-loads the write operation and dry_run behavior. A slight reduction could be possible by removing the last line about arguments, but overall it is 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?

Given the tool's complexity (9 parameters, no output schema), the description covers workflow, parameter explanations, and dry_run behavior. It lacks a clear statement about the return value for when dry_run=False, but the purpose is still clear. The description is largely complete for an agent to invoke the tool correctly.

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?

With 0% schema description coverage, the description fully compensates by explaining all 8 parameters (including the optional target). It provides examples for k8s_version and vm_class, explains the default values for control_plane_count, worker_count, storage_class, and dry_run, and clarifies the effect of dry_run. This adds meaning beyond the schema's type and title.

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 it creates a TanzuKubernetesCluster and distinguishes from sibling tools like scale_tkc_cluster and upgrade_tkc_cluster. The verb 'Create' and resource 'TanzuKubernetesCluster' are specific and unambiguous.

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 explicit workflow guidance: call get_tkc_available_versions first for k8s_version and list_vm_classes for vm_class. It also explains the dry_run parameter behavior, which helps the agent decide when to use dry_run. However, it does not explicitly state when not to use this tool or list alternatives beyond the workflow hint.

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