ncloud_serverless_list_processes

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

Annotations already declare readOnlyHint=true, so the description does not need to cover safety. It adds useful context about the return fields (sessionNo, command, state, etc.) and sortable fields, which are not in the annotations. However, it does not disclose any other behavioral traits like pagination limits or error handling beyond what the schema already provides. With annotations covering the read-only nature, the description contributes some context but remains limited.

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 two sentences and front-loaded with the core purpose. It packs the API endpoint, returned fields, and sort fields without extraneous wording. Every sentence earns its place, and the structure is highly efficient.

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 read-only list operation with 5 parameters (2 required) and full schema coverage, the description is complete. It provides the purpose, the API endpoint, the returned fields, and sort semantics. The schema covers parameter details like pageNo/pageSize and naming conventions. No output schema exists, so describing return fields is a plus. Missing are potential error cases or permission notes, but these are minor for such a straightforward listing 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 has 100% description coverage, so all parameters are already documented. The description adds value by specifying the allowed sort fields (sessionNo, elapsedSeconds, userName, databaseName), which the schema only vaguely mentions as 'allowed fields per tool'. This clarifies the sort parameter's possible values beyond the schema. It also lists the returned fields, though those are not parameters.

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 verb 'List' and the resource 'DB sessions of an instance', and even provides the exact API endpoint (GET /mysql/v1/clusters/{clusterName}/instances/{instanceName}/processes). It also enumerates the returned fields, making its purpose unambiguous. This clearly distinguishes it from sibling tools like ncloud_serverless_kill_processes, which is a different 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: if you need to list DB sessions, use this tool. However, it does not explicitly mention when not to use it or suggest alternatives such as ncloud_serverless_kill_processes for terminating sessions. There is no exclusion or routing to sibling tools, so guidance is implied rather than explicit.

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