Skip to main content
Glama
BenedatLLC

Kubernetes Tools MCP Server

by BenedatLLC

get_replicaset_summaries

Retrieve a list of ReplicaSet summaries, grouped by namespace and owning deployment, including revision and container images, to track deployment changes.

Instructions

Retrieves a list of ReplicaSetSummary objects, similar to `kubectl get replicasets`
but including each replica set's deployment revision and container images.

A Deployment's replica sets are its revision history: every update to a Deployment
creates a new replica set carrying that revision's pod template, and older replica
sets are retained (scaled to zero). Listing them for one deployment therefore shows
when it last changed and what its image was at each revision - which is how you
answer "did something change recently?" without access to deployment tooling or
version control.

Results are grouped by namespace and owning deployment, and within each
deployment sorted by revision, oldest first. So when filtered to a single
deployment, the last entry is that deployment's current revision.

Replica sets with no revision (see `revision` below) sort *first*, ahead of
revision 1, rather than being dropped. They have no place in any deployment's
history, so they are listed before it rather than appended to it. In practice
they are only visible in an unfiltered listing: a replica set without a
revision has no owning deployment either, so passing `deployment` filters them
out, and the "last entry is the current revision" guarantee above is unaffected.

Parameters
----------
namespace : Optional[str], default=None
    The specific namespace to list replica sets from. If None, lists from all namespaces.
deployment : Optional[str], default=None
    If given, return only replica sets owned by this deployment. This is the common
    case: one deployment's revision history.

Returns
-------
list of ReplicaSetSummary
    A list of ReplicaSetSummary objects with the following fields:

    name : str
        Name of the replica set.
    namespace : str
        Namespace in which the replica set is defined.
    owner_deployment : Optional[str]
        Name of the Deployment that owns this replica set, or None if it is
        standalone (not managed by a Deployment).
    revision : Optional[int]
        The deployment revision this replica set represents, taken from the
        `deployment.kubernetes.io/revision` annotation. None when that
        annotation is absent, which means no Deployment created this replica
        set - only the Deployment controller writes it. A hand-written replica
        set, or one created by another controller, therefore has no revision
        (and no `owner_deployment`), and appears in neither `kubectl rollout
        history` nor a `deployment`-filtered call here. Also None if the
        annotation is present but not an integer.
    desired_replicas : int
        Replicas desired for this replica set. Old revisions are scaled to 0.
    current_replicas : int
        Replicas currently running.
    ready_replicas : int
        Replicas currently ready.
    images : list[str]
        Container images in this revision's pod template, in container order.
        Comparing this across revisions shows what an upgrade changed.
    age : datetime.timedelta
        Age of the replica set (current time minus creation timestamp). For the
        newest revision this is how long ago the deployment last changed.

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
namespaceNo
deploymentNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.1.0

TDQS

A4.4/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 discloses grouping/sort order, the edge case that revision-less replica sets sort first, what None revision means, and the error types raised (K8sConfigError, K8sApiError). It omits permission/auth requirements and pagination/limit behavior, so it is not fully complete.

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 definition is long and the Returns section largely re-lists fields already present in the output schema, making it partly redundant. The edge-case paragraph on revision-less replica sets, while informative, is verbose relative to its value. Structure is good; size is not tight.

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?

Given an output schema exists, the description need not explain return values, yet it still adds interpretation (comparing images across revisions, age of newest revision as time-since-change). Combined with documented errors, sorting, and edge cases, an agent has everything needed to call and interpret this tool.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate, and it does: both namespace and deployment are documented with types, defaults, and semantics ('If given, return only replica sets owned by this deployment. This is the common case'). It even explains the interaction between deployment filtering and revision-less replica sets.

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 ('Retrieves a list of ReplicaSetSummary objects') and immediately distinguishes itself from siblings with 'similar to kubectl get replicasets but including each replica set's deployment revision and container images.' An agent can tell it apart from get_deployment_summaries or get_pod_summaries 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear when-to-use context ('how you answer "did something change recently?"') and identifies the common invocation case ('filtered to a single deployment ... one deployment's revision history'). It does not name alternative sibling tools or explicit exclusions, so it stops short of a 5.

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