Ankra

run_os_patches

Destructive

Start the rolling OS security patch of an Ankra-provisioned cluster: one host at a time, never two. Each node is checked first (nothing pending means nothing is touched), then cordoned and drained through a peer control plane with PodDisruptionBudgets honoured and never forced, upgraded with apt (the held-back systemd, udev, netplan, container-runtime and packet-filter packages included; packages are never removed and Kubernetes packages are never moved), rebooted only when the update asks for it, and returned to service only once it is Ready, its etcd member is healthy (control planes, which go one at a time and only with quorum to spare), its workloads are back and the cluster's agent has checked in. A failed drain or host stops the whole run. Nodes carrying single-replica workloads with volumes, or in a database node pool, are skipped and reported unless include_stateful_nodes is true; a cluster's only control plane is never patched live. When the cluster's OS patch policy is enabled, each host the run patches or finds up to date gets Ankra's update hold (apply_node_os_policy), and a skipped stateful node or only control plane has it removed, so every host is patched by either this lane or unattended-upgrades. The bastion goes last; on clusters where it is the NAT gateway its reboot briefly cuts the nodes' internet egress, and its NAT and SSH guard are re-asserted afterwards. The run starts only inside the cluster's maintenance window unless outside_window is true. Run plan_os_patches first to see what will happen, and follow the run with get_os_patch_status.

Input Schema

Name	Required	Description
`cluster_id`	No	UUID of the cluster. Optional when a cluster is selected.
`cluster_name`	No	Exact name of the cluster. Optional when a cluster is selected.
`outside_window`	No	Start now even though the cluster's maintenance window is closed. Only when the user explicitly wants that.
`include_bastion`	No	Patch the bastion as the last step. Defaults to true.
`include_stateful_nodes`	No	Also drain and patch nodes carrying single-replica workloads with volumes or belonging to a database node pool. Defaults to the cluster policy (off). Only when the user accepts that those workloads go down while their node is patched.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 15, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=false, and the description substantially enriches that: a failed drain or host stops the whole run, PDBs are honoured and never forced, packages are never removed, the only control plane is never patched live, and the bastion reboot cuts internet egress. This is rich disclosure well beyond what the structured fields provide.

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?

Purpose is front-loaded, but the body is a single sprawling run-on sentence covering patch sequencing, holds, and bastion last. Every clause is informative for a destructive operation, yet the density and lack of structural breaks hurt scannability.

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, non-idempotent, multi-step operation with no output schema, the description is complete: it covers sequencing, skip logic, failure behavior, hold bookkeeping, and the exact follow-up tools. Nothing an agent needs in order to decide to call it is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all five parameters including the defaults and caveats for outside_window and include_stateful_nodes. The prose reinforces those semantics (skipped stateful/db nodes, maintenance-window gating) but adds no format or syntax detail the schema lacks, so the baseline of 3 applies.

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 — 'Start the rolling OS security patch of an Ankra-provisioned cluster' — and immediately scopes it ('one host at a time, never two'). It also names the sibling tools in the same lane (plan_os_patches, get_os_patch_status, apply_node_os_policy), so an agent can distinguish it without opening any schema.

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?

Explicit when/when-not guidance: 'Run plan_os_patches first to see what will happen, and follow the run with get_os_patch_status', plus the maintenance-window precondition and the outside_window override. Nodes skipped unless include_stateful_nodes is true is spelled out with the condition that selects it.

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

All Ankra tools Inspect

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

Need Help?