ncloud_sens_delete_brandmessage_image

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds significant behavioral context: it explicitly warns 'Destructive', explains the irreversible effect on message sending, and discloses the confirmation requirement (confirm=true). It also specifies the HTTP method and response code (204), which is beyond the annotations. No contradiction with annotations; the description complements them.

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, concise sentence that front-loads the most critical information: the destructive warning, the action, the endpoint, and the confirmation requirement. Every part adds value, and there is no fluff or repetition. The structure makes it easy for an agent to quickly grasp the essential behavior.

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 destructive delete operation with annotations (destructiveHint, idempotentHint) and a complete schema, the description covers the key aspects: what it deletes, the HTTP method and response, the effect on messages, and the confirmation flag. It does not explicitly mention how to obtain the imageId (e.g., via list_brandmessage_images) but that is a minor omission given the schema and surrounding sibling tools. Overall, it is sufficiently complete for an agent to call correctly.

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 coverage is 100%, so all three parameters (imageId, confirm, serviceId) have descriptions in the schema. The tool description does not add additional parameter semantics beyond the schema—it only references the endpoint path that includes serviceId and imageId. Since the schema already documents each parameter adequately, a baseline of 3 is appropriate; the description adds no extra clarity.

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 clearly states the action: 'Delete an uploaded Brand Message image' with a specific HTTP endpoint and effect. It distinguishes from siblings like ncloud_sens_list_brandmessage_images and ncloud_sens_get_brandmessage_image by focusing on deletion. The warning and consequence ('Messages referencing the imageId can no longer be sent') reinforce the specific resource and operation.

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 usage (deleting an image) but does not explicitly state when to use this tool versus alternatives or when not to use it. It mentions the destructive nature and the need for confirm=true, but lacks explicit guidance on prerequisites or conditions. There is no mention of alternative tools for listing or retrieving images, though the purpose is clear enough for an agent to infer the usage context.

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