Skip to main content
Glama
vmware-skills

vmware-vks

by vmware-skills
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Remote

get_tkc_kubeconfig

Idempotent

Retrieve a kubeconfig for a Tanzu Kubernetes Cluster to access it. Specify name and namespace, optionally write to a file to keep session tokens out of agent context.

Instructions

[WRITE] Get a kubeconfig for one TKC cluster.

Marked [WRITE] because output_path, when given, mkdir -p's and truncates a caller-chosen file. It reads the managed cluster, but this family's marker means "no side effects", and writing a credentials file is one. With no output_path nothing is written and the kubeconfig is returned inline — this docstring previously said it defaulted to ~/.kube/config, which was never true of either the tool or the CLI. Its sibling vmware-aiops.vm_guest_download was corrected the same way in the same round; the two had been given opposite answers to the same question.

Returns {cluster, kubeconfig}, or {cluster, written_to} when output_path is given. Run list_tkc_clusters first for name and namespace; use get_supervisor_kubeconfig instead for Supervisor-level access. Security: it carries a short-lived session token — always prefer output_path so the credential never enters agent context.

Reads vSphere but is NOT annotated readOnlyHint — output_path creates directories and truncates a caller-chosen file, so output_path='~/.kube/config' overwrites the user's own kubeconfig. readOnlyHint is what an MCP client consults to decide whether to ask the user first, and it is about this tool's whole environment, not just vSphere. The [READ] marker above stays accurate for what it answers: nothing in the managed cluster changes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesTKC cluster name.
targetNovCenter in config.yaml; omit for the default.
namespaceYesNamespace holding it.
output_pathNoFile to write, e.g. '~/.kube/my.yaml'. Omit to return the kubeconfig inline.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.8.14
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / name / description
      Added value: +"TKC cluster name."
    • addedInput schema / properties / namespace / description
      Added value: +"Namespace holding it."
    • addedInput schema / properties / output_path / description
      Added value: +"File to write, e.g. '~/.kube/my.yaml'. Omit to return the kubeconfig inline."
    • addedInput schema / properties / target / description
      Added value: +"vCenter in config.yaml; omit for the default."
  2. Addedv1.5.26
  3. Removedv1.5.23
  4. First observedv1.3.2

TDQS

A3.8/5.0
Behavior1/5

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

The description is extremely transparent about side effects, return shapes, and session-token handling, but it contradicts the annotations: it states output_path 'mkdir -p's and truncates' and can 'overwrite the user's own kubeconfig,' while annotations declare destructiveHint=false. Per rubric, this annotation contradiction forces a score of 1.

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

Conciseness2/5

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

The description is far longer than needed and repeats the truncation/overwrite warning in multiple places. It also includes meta-commentary about docstring history, sibling corrections, and marker conventions that an agent does not need to invoke the tool correctly.

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?

Even though there is no output schema, the description fully covers return values, parameter side effects, prerequisites, alternatives, and security considerations. It provides enough context for an agent to call the tool correctly, apart from the annotation contradiction noted above.

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 coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the behavior of output_path: omitting it returns the kubeconfig inline, while providing it writes a file and returns {cluster, written_to}.

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 first sentence states a specific action and resource: 'Get a kubeconfig for one TKC cluster.' It also distinguishes itself from a sibling by naming get_supervisor_kubeconfig for Supervisor-level access, so an agent can tell them apart.

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 explicitly says to run list_tkc_clusters first for name/namespace, to use get_supervisor_kubeconfig instead for Supervisor-level access, and to prefer output_path for security. It also clarifies when nothing is written versus when output_path is supplied.

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

Install Server

Other Tools