ise_openapi_cert_system_delete

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

The description explicitly documents the destructive nature and the confirm-flag requirement, including the server-side environment variable gate (CISCO_ISE_MCP_ALLOW_DESTRUCTIVE=1) and the refusal behavior when not enabled. While no annotations are provided, the description carries its burden well by disclosing the two-step safety confirmation required for execution. The deployment targeting behavior is also disclosed.

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 focused sentence with a clear destructive warning prefix, endpoint path, and resource type. The param-level details are appropriately placed in the schema. It's efficient, but the front-loaded [DESTRUCTIVE] tag and endpoint string are slightly dense; still, nothing is wasted.

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 destructive operation with no output schema and no annotations, the description effectively covers the identification of the resource (ID + hostname), the safety requirements (confirm flag + env variable), and deployment targeting. The main gap is that it doesn't describe what happens on success/failure or whether the operation is reversible, but for a delete operation the destructive framing already sets expectations. The nested 'data' object param is unexplained in the description, but the schema covers it.

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%, so the schema already documents all 5 parameters. The description adds value on the 'confirm' parameter by explaining the destructive-operation requirement and environment variable gate beyond its basic boolean default. The 'deployment' parameter also gets useful context about name/slug/number formats and the sibling list tool. However, core path parameters (id, hostName) get no additional meaning beyond the schema.

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 'Delete System Certificate by ID and hostname' with the specific HTTP endpoint and resource type labeled 'System Certificate'. The verb (Delete) + resource (System Certificate) + identifying parameters (ID, hostname) are all explicit, and the endpoint path is provided for precision. It distinguishes itself from sibling cert tools (trusted certs, CSR) by specifying 'System Certificate'.

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 [DESTRUCTIVE] tag clearly flags when this should be used cautiously, and the confirm parameter documentation explains that it must be set to true and that destructive tools must be enabled at the server level. However, it doesn't explicitly contrast with the import/export/list/get sibling cert tools or explain when one would choose deletion vs other cert operations, though the destructive framing implies prudent use.

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