ncloud_kms_enable_auto_rotation

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

Annotations provide idempotentHint=true and destructiveHint=false, which already indicate the safety profile. The description adds no additional behavioral context beyond the basic action—no mention of side effects (e.g., scheduling, key version changes), prerequisites, or what happens to existing rotation settings. With annotations present, the description fails to add value about the behavior of enabling auto rotation.

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 a single, clear sentence with no superfluous words. It is front-loaded with the verb and resource. However, it is quite sparse and could include relevant context without becoming verbose, so it does not earn a 5.

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 tool is simple (one parameter, no output schema), but the description does not cover prerequisites (e.g., key must exist, rotation period must be configured), the effect of enabling auto rotation, or return behavior. Given the low complexity, the description is minimally adequate but leaves important operational context unspecified.

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?

The input schema covers 100% of the parameter (keyTag) with a clear description ('Key tag - unique identifier derived from key name'). The tool description does not mention keyTag at all, so it adds no meaning beyond the schema. Baseline of 3 is appropriate given high schema coverage.

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 uses a specific verb-resource combination ('Enable automatic key rotation for a KMS key') and clearly identifies the target resource. It distinguishes this tool from sibling tools like ncloud_kms_disable_auto_rotation and ncloud_kms_rotate_key by specifying the action (enable auto rotation) rather than manual rotation or disabling.

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?

The description implies the tool is for enabling automatic key rotation, but it does not explicitly state when to use it versus alternatives (e.g., manual rotation with ncloud_kms_rotate_key or disabling with ncloud_kms_disable_auto_rotation). No prerequisites, conditions, or exclusions are provided. Usage is inferred from the tool name and sibling context rather than explicit guidance.

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