Skip to main content
Glama

scale_statefulset

Destructive

Scale a Kubernetes StatefulSet to a specified replica count, with dry-run preview and undo support. Adjust replica capacity safely via governed operations.

Instructions

[WRITE][risk=medium] Scale a statefulset to replicas. Inverse: restore previous count.

Pass dry_run=True to preview without scaling (no undo is recorded for a preview).

Args: name: StatefulSet name. replicas: Desired replica count. namespace: Namespace; omit for the target's default namespace. dry_run: If True, preview without scaling. target: k8s target name from config.

Input Schema

NameRequiredDescriptionDefault
nameYes
targetNo
dry_runNo
replicasYes
namespaceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.8.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already mark it destructive, non-idempotent, non-read-only; the description adds real value beyond them by disclosing the inverse operation ('restore previous count'), the risk level, and that a preview records no undo entry. It stops short of stating permission requirements or the effect on running pods, but the safety-relevant context is solid.

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-loads the action and risk tag, then the dry_run caveat, then a clean Args list. Minor redundancy: 'Pass dry_run=True to preview without scaling' is restated in the per-arg line for dry_run.

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?

No output schema exists, so return values need not be explained, and annotations cover the destructive profile. The description adds undo and dry_run semantics plus all parameter meanings, leaving only minor gaps such as auth requirements and workload impact.

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 0%, so the description must carry the parameter burden, and it documents all five params: name, replicas, namespace ('omit for the target's default namespace'), dry_run, and target ('k8s target name from config'). The namespace default and target meaning go beyond the bare schema, though 'target' is still somewhat circular.

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 ('Scale') and resource ('statefulset') with the scaling target ('to ``replicas``'), plus a '[WRITE][risk=medium]' tag. The named resource inherently separates it from the sibling scale_deployment, so an agent can route correctly without opening either 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?

Explicitly describes the preview path ('Pass dry_run=True to preview without scaling') and notes the inverse/undo relationship. It does not name a sibling alternative or state when-not-to-use conditions, so it is clear context without exclusions.

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