Skip to main content
Glama
BenedatLLC

Kubernetes Tools MCP Server

by BenedatLLC

get_node_summaries

Retrieve a summary of Kubernetes cluster nodes, including status, roles, version, IPs, and capacity, similar to kubectl get nodes -o wide.

Instructions

Return a summary of the nodes for this Kubernetes cluster, similar to that returned by kubectl get nodes -o wide.

Parameters
----------
None
    This function does not take any parameters.

Returns
-------
list of NodeSummary
    List of node summary objects. Each NodeSummary has the following fields:

    name : str
        Name of the node.
    status : str
        Status of the node (Ready, NotReady, etc.).
    roles : list[str]
        List of roles for the node (e.g., ['control-plane', 'master']).
    age : datetime.timedelta
        Age of the node (current time minus creation timestamp).
    version : str
        Kubernetes version running on the node.
    internal_ip : Optional[str]
        Internal IP address of the node.
    external_ip : Optional[str]
        External IP address of the node (if available).
    os_image : Optional[str]
        Operating system image running on the node.
    kernel_version : Optional[str]
        Kernel version of the node.
    container_runtime : Optional[str]
        Container runtime version on the node.
    capacity : dict[str, str]
        Total capacity of the node keyed by resource name (e.g. "cpu",
        "memory", "ephemeral-storage", "pods"). Empty if unavailable.
    allocatable : dict[str, str]
        Resources allocatable to pods (capacity minus system-reserved),
        keyed by resource name. Empty if unavailable.
    conditions : dict[str, str]
        Node conditions keyed by type with their status, e.g.
        {"Ready": "True", "MemoryPressure": "False", "DiskPressure": "False"}.
    conditions_since : dict[str, datetime.timedelta]
        For each condition in `conditions`, the time since its status last
        changed (the API's lastTransitionTime), e.g. how long the node has
        been Ready, or how long ago a MemoryPressure episode ended. A
        condition with no transition time is left out.

        It changes only when the status does. A node or kubelet restart in
        which the node comes back Ready without having been marked NotReady
        or Unknown in between does not reset it: on a minikube cluster
        stopped and started together with its control plane, Ready stayed
        "True since the node was created" across a reboot. So a long Ready
        age does not mean the node or its pods have been running that long,
        and a short one can come from a brief NotReady flap rather than a
        reboot. To date a node's last start, use its "Starting" or
        "Rebooted" events (`get_events(involved_kind="Node")`, while they
        last - events usually expire after an hour), or the `started_at` of
        containers that start with the node, such as kube-proxy and the
        kube-system control-plane containers (`get_pod_container_statuses`).
    taints : list[str]
        Taints on the node formatted as "key=value:effect" (value omitted
        when empty).
    labels : dict[str, str]
        All labels on the node. Useful for identifying node pool / instance
        type and spotting version skew across pools.

Raises
------
K8sConfigError
    If unable to initialize the K8S API.
K8sApiError
    If the API call to list nodes fails.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv2.1.0
    • changedOutput schema / $defs / NodeSummary / description
      Previous value: -"A summary of a node's status like returned by `kubectl get nodes -o wide`"New value: +"A summary of a node's status like returned by `kubectl get nodes -o wide`,\naugmented with the capacity/allocatable/conditions/taints/labels detail that\n`kubectl describe node` shows (useful for reconstructing a pods-per-node\ncapacity model)."
    • addedOutput schema / $defs / NodeSummary / properties / allocatable
      Added value: +{
      +  "additionalProperties": {
      +    "type": "string"
      +  },
      +  "title": "Allocatable",
      +  "type": "object"
      +}
    • addedOutput schema / $defs / NodeSummary / properties / capacity
      Added value: +{
      +  "additionalProperties": {
      +    "type": "string"
      +  },
      +  "title": "Capacity",
      +  "type": "object"
      +}
    • addedOutput schema / $defs / NodeSummary / properties / conditions
      Added value: +{
      +  "additionalProperties": {
      +    "type": "string"
      +  },
      +  "title": "Conditions",
      +  "type": "object"
      +}
    • addedOutput schema / $defs / NodeSummary / properties / conditions_since
      Added value: +{
      +  "additionalProperties": {
      +    "format": "duration",
      +    "type": "string"
      +  },
      +  "title": "Conditions Since",
      +  "type": "object"
      +}
    • addedOutput schema / $defs / NodeSummary / properties / labels
      Added value: +{
      +  "additionalProperties": {
      +    "type": "string"
      +  },
      +  "title": "Labels",
      +  "type": "object"
      +}
    • addedOutput schema / $defs / NodeSummary / properties / taints
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "title": "Taints",
      +  "type": "array"
      +}
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it names the errors raised (K8sConfigError, K8sApiError), documents the exact shape and optionality of returned fields, and discloses the non-obvious `conditions_since` semantics (it tracks lastTransitionTime, not node uptime, and survives a clean reboot). It stops short of stating read-only/idempotency explicitly, so not a perfect 5.

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?

Front-loading is good (purpose first, then structured sections), but the Returns block is a long field-by-field enumeration of return values that is redundant with the existing output schema, so it does not fully earn its space. The conditions_since caveat is verbose but conveys real, non-schema information.

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

Completeness4/5

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

For a simple, read-only, zero-parameter list tool with an output schema, the description covers errors, edge-case semantics, and alternative tools, so an agent has enough to call it correctly. The only shortfall is composition: it re-documents return values the output schema already owns.

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?

Zero parameters, and the description explicitly says so ('This function does not take any parameters'), matching an empty schema. Baseline for a no-param tool is 4; nothing is ambiguous.

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 (return a summary) and resource (nodes for this Kubernetes cluster), reinforced by the concrete analogy `kubectl get nodes -o wide`. The resource noun cleanly separates it from the sibling `get_pod_summaries`, `get_service_summaries`, etc., without needing to name them.

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?

There is no explicit statement of when to prefer this tool over siblings or what preconditions apply; usage is only implied by the purpose. It does route the agent elsewhere for one specific sub-question (dating a node's last start via `get_events` and `get_pod_container_statuses`), which is genuinely useful, but that is a narrow slice of guidance rather than a general when/when-not.

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