ncloud_mailer_register_unsubscribers

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

Annotations only include destructiveHint:false. The description adds meaningful context beyond this: it notes the legacy status, the effect of registering addresses, and the returned fields (count / requestCount / ignoreCount). It also mentions the HTTP method (POST) and endpoint. This is useful behavioral disclosure that goes beyond the sparse annotations, though it doesn't cover auth or rate limiting, which are not expected here.

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 dense but efficient. It leads with the legacy caveat, then the purpose, return fields, and a note on missing list API. Each sentence provides necessary information for correct tool selection and invocation. While it is longer than minimal, there is no redundancy, and the structure front-loads critical context.

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 only two parameters (both fully documented in the schema), no output schema, and minimal annotations, the description provides adequate context: it explains the legacy status, the modern alternatives, the operation's effect, and the absence of a list endpoint. The returned fields are mentioned, giving the agent a clear expectation of the response. No critical information appears missing for an agent to use it 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 description coverage is 100% for both parameters (region enum, blockedReceivers with format email and minItems). The description does not add extra explanation about these parameters beyond the schema definitions. Since the schema fully documents them, a baseline of 3 is appropriate—the description adds no additional value for parameter understanding.

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: 'Register addresses as unsubscribed so they are excluded from advertising mail.' It also distinguishes this from sibling tools by noting it's a legacy API and pointing to alternatives (ncloud_sens_send_mail / ncloud_sens_list_mail_requests). The verb-resource pairing is specific and unambiguous.

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 explicitly states this is a legacy API only for migrated projects and provides the modern replacements for new mail operations. It also clarifies that there is no list API for unsubscribers in v1, preventing the agent from searching for a non-existent operation. This gives clear when-to-use and when-not-to-use guidance with named alternatives.

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