Api comments destroy
ciso_assistant_api_comments_destroyDeletes a CISO Assistant comment by ID, removing outdated or incorrect notes from GRC records.
Instructions
api_comments_destroy
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
ciso_assistant_api_comments_destroyDeletes a CISO Assistant comment by ID, removing outdated or incorrect notes from GRC records.
api_comments_destroy
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Changes observed during successful MCP inspections.
v2.3.6Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=true, yet the description adds nothing about what 'destroy' means here: permanent removal vs soft delete, cascading effects on replies/attachments, required permissions, or failure behavior for a non-existent id. For a destructive operation the description contributes zero behavioral context.
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?
It is not verbose, but the single token is under-specification rather than conciseness; there is no front-loaded statement of action or scope for the reader to anchor on.
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?
A destructive, open-world, irreversible-looking deletion with no output schema, no parameter documentation, and no description of consequences is completely inadequate for safe invocation; nothing tells the agent what it is about to permanently remove.
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 single required parameter 'id' has 0% schema description coverage and the description says nothing about it - not its format (integer vs UUID string), not whether it is the comment id, and not what happens if it references a reply or a missing record. With one undocumented param the description must compensate and does not.
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 is the tool name with underscores transposed ('api_comments_destroy'), a pure tautology that restates the identifier. It does not state what is deleted, from where, or how this differs from siblings such as ciso_assistant_api_comments_update or ciso_assistant_api_comments_batch_action_create.
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?
There is no guidance at all: no statement of when to use this instead of comments_update, comments_partial_update, or comments_batch_action_create, and no warning about when deletion is appropriate. An agent must infer everything from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.