ncloud_get_public_ip_detail

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

Annotations already declare readOnlyHint=true, covering the safety profile. The description adds valuable behavioral context by revealing an API limitation: the response payload carries no product code, which could affect downstream pricing decisions. This is beyond what annotations provide and helps the agent avoid a misleading call. It does not describe auth or rate limits, but those are less critical given the simple read-only nature.

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?

Two sentences, each earning its place. The first states the core purpose; the second provides a critical limitation and routes the agent to a pricing alternative. No filler, no redundancy, and the most important caveat is front-loaded after the purpose.

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 simple one-parameter read-only detail tool, the description is largely complete. It covers the API limitation and the pricing workaround. No output schema exists, so agents might want more specifics on returned fields, but 'detailed information' is reasonably descriptive. A minor gap is that it doesn't mention that the required instance number must be obtained first (e.g., from list_public_ips), but this is implicit in the tool's design and the sibling list tool.

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 fully documents the single parameter publicIpInstanceNo with a description ('Public IP instance number'), so schema coverage is 100%. The description adds no additional meaning about this parameter—it only mentions a product-code limitation, not the parameter itself. Baseline 3 is appropriate because the schema does the heavy lifting.

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 a specific verb and resource: 'Get detailed information about a specific public IP instance.' This distinguishes it from siblings like ncloud_list_public_ips (list vs. detail) and ncloud_get_public_ip_target_servers (target servers vs. instance details). The purpose is 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 provides clear guidance on an important usage caveat: the payload carries no product code, so pricing must be obtained via ncloud_get_product_price_list with productName='Public IP'. This effectively tells the agent when not to use this tool (for pricing) and names the alternative. However, it does not explicitly contrast with the listing tool or other detail endpoints, leaving some sibling differentiation to inference.

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