ncloud_drm_update_policy

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

The annotations (idempotentHint=true, destructiveHint=false) already establish that repeated updates are safe and non-destructive. The description adds valuable behavioral context not inferable from annotations: that sites actively using the policy must be disabled first, implying a risk of disruption or failure if this step is skipped. This is a meaningful disclosure beyond structured metadata, though it does not elaborate on failure modes or side effects.

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 two sentences with no filler. The first sentence states the core action, and the second delivers the most critical usage warning. It is perfectly front-loaded and every word earns its place.

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?

For a tool with six required parameters, a complex nested policy configuration, and no output schema, the description is minimal. It covers the purpose and the single most important prerequisite, but does not mention what the operation returns, how to verify success, or whether the update replaces or merges existing policy settings. The rich schema mitigates but does not eliminate this gap, so this is a bare-minimum score rather than a serious deficiency.

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 already provides 100% description coverage for all six parameters, including nested drmPolicyConfig fields with detailed enums and constraints. The tool description adds no parameter-specific information, so the schema carries the full burden. Per the calibration baseline, when schema coverage is high, a score of 3 is appropriate.

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+resource construction, 'Update a DRM policy,' which unambiguously identifies the tool's function. It clearly distinguishes itself from sibling tools like ncloud_drm_create_policy, ncloud_drm_delete_policy, and ncloud_drm_get_policy. The purpose is immediately understandable without needing to inspect the schema.

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 provides an explicit operational prerequisite: 'Disable any site using this policy before updating.' This tells the agent the necessary precondition and implies when caution is needed. However, it does not mention alternative tools (e.g., creating a new policy instead of updating an existing one) or explicitly state when not to use this tool, so it falls short of the highest bar.

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