scale_deployment

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the desired end state (specified number of replicas) but does not disclose side effects such as pod termination on scale-down, the need for permissions, idempotency, or interaction with autoscalers.

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

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

The description is compact and front-loads the core purpose in the first sentence. The Args list is concise and uses no filler, though it partially repeats schema information rather than adding substantial new detail.

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

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

The description covers all four parameters and includes defaults for namespace and cluster, and an output schema exists to describe return values. However, it lacks usage context, prerequisite information, and any caveats about scaling behavior, making it adequate but not complete for an agent unfamiliar with Deployment scaling.

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

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 for the schema's lack of parameter explanations. It adds some value by clarifying 'replicas' as desired replica count, 'cluster' as a named cluster target, and stating defaults for namespace and cluster. However, the parameter explanations are mostly surface-level glosses on the property names and lack deeper constraints or format details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Scale a Deployment to the specified number of replicas.' This clearly identifies the operation and separates it from siblings like scale_statefulset or scale_machine_set by naming the Deployment resource explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

No guidance is provided about when to choose this tool over alternatives such as scale_statefulset, scale_machine_set, or rollout_restart_deployment. There are no explicit conditions, exclusions, or recommendations for when this tool is appropriate.

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