ncloud_create_sub_account_access_key

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

Annotations only provide destructiveHint: false, so the description carries the full behavioral burden — and it delivers. It discloses the one-time-only secret exposure ('it CANNOT be retrieved again afterwards'), the undocumented two-key limit verified against the live API, the exact 409 error message ('최대 허용값을 초과하였습니다'), and the API Gateway access prerequisite. All of this goes well beyond the minimal annotation, and nothing contradicts destructiveHint: false since issuing a key is non-destructive.

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?

Three dense sentences, front-loaded with the core action and the security-critical warning (secret cannot be retrieved again) before prerequisites and limit details. Every sentence carries non-redundant information; even the parenthetical about live-API verification earns its place by signaling the reliability of a limit absent from the API docs.

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?

With no output schema, the description names the critical return value (keySecret) and its irrecoverable nature, covers the failure mode and remediation for the two-key limit, and states the prerequisite. For a tool with a single required parameter, nothing an agent needs to call it correctly is missing.

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% — subAccountId is already documented in the schema with a pointer to ncloud_list_sub_accounts for lookup. The description adds helpful context about the target sub account's state (API Gateway access, two-key limit) but does not add meaning to the parameter itself, so the rubric's baseline 3 applies.

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?

States a specific verb ('Issue'), a concrete resource ('new API access key for a sub account'), and the downstream purpose ('so that account can call the Ncloud API'). The phrase 'new API access key (access key + secret key)' clearly delineates it from sibling key-management tools like ncloud_set_sub_account_access_key_status, ncloud_delete_sub_account_access_key, and ncloud_list_sub_account_access_keys.

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?

Explicitly states the prerequisite ('The sub account must have API Gateway access enabled (canAPIGatewayAccess)') and provides a when-not rule: a third key fails with 409, so delete an unused key first or 'deactivate one with ncloud_set_sub_account_access_key_status when rotating'. This names the exact alternative tool and the condition that should route the agent away from a direct creation call.

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