Skip to main content
Glama
mmpyro

vcluster-mcp

by mmpyro
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

vcluster_kubeconfig

Export a virtual cluster's kubeconfig to a private temp file without altering your current context. Use the returned file path with other tools, then delete it.

Instructions

Export a vcluster kubeconfig without switching the caller's context.

Returns the path to a private (0600) temp file, not the contents, because it holds client credentials. Pass the path to other tools; delete it after use.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
serverNoAPI server address to record, when the vcluster is reached via ingress or a load balancer rather than a port forward.
insecureNo
namespaceNo
kubeconfig_pathNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.0.0
    • addedInput schema / properties / server / description
      Added value: +"API server address to record, when the vcluster is reached via ingress or a load balancer rather than a port forward."
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "anyOf": [
-        {
-          "additionalProperties": {
-            "type": "string"
-          },
-          "type": "object"
-        },
-        {
-          "type": "string"
-        }
-      ],
-      "title": "Result"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "vcluster_kubeconfigOutput",
-  "type": "object"
-}New value: +null
  2. Addedv0.1.1

TDQS

A3.8/5.0
Behavior4/5

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

Since no annotations are provided, the description carries the transparency burden. It discloses the nontrivial return convention (path to a 0600 temp file rather than contents), the reason (client credentials), the fact that the caller's context is unchanged, and the need to delete the file afterward. These are the key behavioral details an agent needs.

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 compact and front-loaded: the core purpose appears in the first sentence, followed by the return convention, security rationale, and cleanup instruction. Every sentence earns its place with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains what the tool returns, why it returns a file path, and how to handle the result, which is critical given there is no output schema. However, with five parameters and no annotations, it leaves parameter meanings and default behavior under-specified, so an agent may not know how to set `namespace`, `kubeconfig_path`, or `insecure` correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 20%, with just `server` having a description. The description adds no parameter-level detail, leaving `name`, `insecure`, `namespace`, and `kubeconfig_path` to be inferred from their names. This does not compensate for the low schema coverage.

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 states the exact operation ('Export a vcluster kubeconfig') and adds a distinguishing qualifier ('without switching the caller's context'), which clearly separates it from sibling commands like vcluster_create or vcluster_delete. There is no ambiguity about the resource or the action.

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?

The description implies when to use the tool: when another tool needs a vcluster kubeconfig and the current context must be preserved. However, it does not explicitly name alternatives or state when not to use it, so the agent must infer the decision boundary from the context-preservation wording.

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

Deploy Server

Other Tools