ncloud_sens_get_mail_request

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

The annotation readOnlyHint: true already declares this as a read-only operation, which covers the safety profile. The description adds the endpoint and the specific returned fields, which is useful context beyond the annotation, but does not disclose additional behavioral aspects such as error handling or rate limits. Since the annotation covers the main behavioral trait, a score of 3 is appropriate.

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 sentence that front-loads the main action, includes the API path, and lists the returned fields. There is no filler or redundancy; every part earns its place. It is concise and well-structured.

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?

There is no output schema, but the description lists the returned fields, giving an agent a sense of the response. The schema descriptions for parameters cover how to obtain requestId and serviceId, including troubleshooting for Forbidden errors. For a simple read operation, this is mostly complete, though it does not explain the meaning or structure of countsByStatus[] in detail, which is a minor gap.

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 schema provides 100% coverage for both parameters with detailed descriptions, especially for serviceId which explains defaults, discovery, and troubleshooting. The tool description itself does not add parameter meaning beyond repeating the purpose. With high schema coverage, the baseline is 3, and the description does not compensate with extra 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 clearly states the action (Get), the resource (one SENS mail send request), and lists the specific status counts returned (status, requestCount, sentCount, finishCount, countsByStatus[]). It also includes the API endpoint, which adds precision. This distinguishes it from list operations and the send operation by focusing on a single request with a requestId.

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 does not explicitly mention when to use this tool versus alternatives like ncloud_sens_list_mail_requests or ncloud_sens_get_mail. However, the required requestId parameter implies it is used when you have a specific request ID from sending, but this is implicit rather than stated. No explicit exclusions or alternative guidance is provided.

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