Skip to main content
Glama

Ankra

by ai.ankra
OverviewDiscussionsAdmin

change_control_plane

Destructive

Change the control plane of an Ankra-provisioned self-managed cluster. Provide exactly ONE of: count (1 or 3; additionally 5 on Proxmox VE - etcd quorum needs an odd number) or instance_type (resizes every control plane node). GROWING the count (1 -> 3, 3 -> 5) happens LIVE on a running cluster: the new control planes provision and join etcd without downtime, and the answer carries the operation to follow. REDUCING the count is applied offline: stop the cluster (the stop preserves its state and the start restores it), apply the change, then start_cluster. instance_type changes roll one controller at a time on a running cluster with 3 or more controllers. On a RUNNING cluster with a SINGLE controller (Hetzner), changing instance_type resizes that one server in place and TAKES THE KUBERNETES API DOWN for a few minutes (typically 3 to 8) while it reboots: workloads already running on workers keep running, but kubectl, deployments, controllers and the Ankra agent pause until it is back. That call REQUIRES accept_api_downtime=true and is refused without it; only set it when the user has explicitly accepted the API downtime, and tell them about it first. The alternatives are growing to 3 controllers first (no downtime) or applying the change offline on a stopped cluster. Call list_node_groups first - its control_plane section reports the current count/instance type, whether a change is possible right now, and in which mode.

Input Schema

NameRequiredDescriptionDefault
countNoNew control plane count (1 or 3; also 5 on Proxmox VE). Exactly one aspect per call.
cluster_idNoUUID of the target cluster. Optional when a cluster is selected.
cluster_nameNoExact name of the target cluster. Optional when a cluster is selected.
instance_typeNoNew provider instance type for every control plane node. Exactly one aspect per call.
accept_api_downtimeNoRequired (true) to change instance_type of a RUNNING cluster that has only ONE control plane: the user accepts that the Kubernetes API is down for a few minutes while that server reboots on the new type. Ignored otherwise. Never set it without the user's explicit acceptance of the downtime.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / accept_api_downtime
      Added value: +{
+  "description": "Required (true) to change instance_type of a RUNNING cluster that has only ONE control plane: the user accepts that the Kubernetes API is down for a few minutes while that server reboots on the new type. Ignored otherwise. Never set it without the user's explicit acceptance of the downtime.",
+  "type": "boolean"
+}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructive=true and non-idempotent, but the description adds the operational consequences the agent actually needs: growing happens live with no downtime, reducing is offline, instance_type rolls one controller at a time, and the single-controller resize takes the Kubernetes API down for 3-8 minutes and is refused without accept_api_downtime=true. This is exactly the context annotations cannot convey.

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

Conciseness4/5

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

Front-loaded with the core action and the one-of constraint before the branching behavioral detail; the long Hetzner paragraph is dense but earns its place. Minor redundancy between the description and the fully documented schema keeps it from a 5.

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 a destructive, mode-dependent mutation with no output schema, the description covers prerequisites (list_node_groups), both change paths, downtime risk and consent gating, and notes that the answer carries the follow-up operation. Nothing an agent needs to call it safely 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 real value beyond the schema: it explains why count must be 1/3/5 (etcd quorum needs an odd number), that the two aspects are mutually exclusive per call, and which mode each triggers, though it largely restates the accept_api_downtime gating already in the schema.

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?

States a specific verb and resource ('Change the control plane of an Ankra-provisioned self-managed cluster') and immediately enumerates the two mutually exclusive aspects (count, instance_type). This is clearly distinguished from scaling worker node groups or updating node groups in the sibling list.

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 says to call list_node_groups first for current state and feasibility, gives the 'exactly ONE of' constraint, and names alternatives: grow to 3 controllers (no downtime) or apply offline on a stopped cluster. When-not conditions (running single-controller Hetzner) and the required explicit user acceptance are spelled out.

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

All Ankra toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources