ise_openapi_hotpatch_list

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

No annotations are provided, so the description carries the burden of behavioral disclosure. The description indicates this is a GET/read operation that lists hot patches, which implies a non-destructive read. However, it doesn't state whether pagination is applied, what the response format looks like, or how many results are returned by default. The description provides only minimal behavioral context for a list operation.

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 concise sentence that communicates the purpose efficiently: 'List installed hot patches (GET /api/v1/hotpatch)'. The endpoint reference is useful operational context, and the '[Patch]' prefix appears to be a category label. Zero wasted words; every element earns its place.

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 list operation with 0 required parameters and no output schema, this description is reasonably complete for the core purpose. However, given the existence of ise_openapi_patch_list sibling, the description could clarify the distinction between regular patches and hot patches. The pagination behavior via page/size params is implied but not elaborated, and the default size of 100 isn't mentioned. It's adequate but has gaps.

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 33% (1 of 3 params documented). The 'deployment' parameter has a rich description explaining how to specify deployment (name, slug, or number) and even cross-references ise_list_deployments. However, 'page' and 'size' parameters have no description, relying on their names - 'page' implies pagination and 'size' implies page size, but format/behavior isn't explained. The description itself doesn't elaborate on 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 'List installed hot patches' with the verb 'List' and resource 'hot patches', which is specific and clear. The '[Patch]' prefix signals it's a read-only list operation on the hot patch endpoint, distinguishing it from related siblings like ise_openapi_hotpatch_install/rollback. It identifies the resource clearly but could be marginally better about scope (all vs filtered).

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 the HTTP endpoint (GET /api/v1/hotpatch) which is useful context, but there's no explicit when-to-use guidance versus alternatives like ise_openapi_patch_list (regular patches vs hot patches). The sibling ise_openapi_patch_list exists and would compete for the same use case; the description doesn't clarify when to choose hotpatch vs patch listing. No exclusions are stated.

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