ise_openapi_hotpatch_rollback

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. It marks [DESTRUCTIVE] and [Patch] inline and notes it's a rollback operation. However, it doesn't state what exactly gets reverted, whether the node restarts, session impact, or reversibility. The confirm param elaboration (server requires ALLOW_DESTRUCTIVE env var) adds real transparency value, but that's in the schema, not the description text.

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 compact line with the endpoint, plus the [DESTRUCTIVE]/[Patch] tags leading. It's efficient. The confirm and deployment param descriptions do meaningful work. Slight redundancy since [DESTRUCTIVE] appears in both description and confirm schema, but the tags are useful for safety signaling.

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?

Despite no annotations or output schema, the description plus enriched param schemas give good coverage. The confirm flag's dual requirement (user true + server-side env var) is well explained. For a 3-param destructive tool, this is reasonably complete, though the absence of behavioral details on node impact and reversibility keeps it short of a 5.

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%, and the confirm param has rich explanation (must be true, server-side env var requirement). The deployment param (name/slug/number) is well-specified with a fallback default and pointer to ise_list_deployments. The 'data' param is noted as the JSON body with an example endpoint. Since schema already covers everything at 100%, baseline is 3, and the confirm/deployment detail pushes it to 4.

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 states a specific verb+resource: 'Rollback hotpatch from the Cisco ISE node' and includes the REST endpoint. It clearly indicates a destructive patch operation. It distinguishes from siblings like ise_openapi_patch_rollback and ise_openapi_hotpatch_install by specifying hotpatch rollback specifically.

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 itself doesn't state when to use this tool vs alternatives, though the [DESTRUCTIVE] flag and the confirm param schema hint at the safety requirement. The deployment param schema directs to ise_list_deployments but the main description lacks explicit when-to-use guidance. The confirm-required and environment-var requirement are in the schema description, not the main description.

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