Activate or deactivate a destroy rule. Activation requires confirmation; it permanently deletes eligible archived records. [Destructive]
Activate or deactivate a destroy rule. Activation requires confirmation; it permanently deletes eligible archived records. [Destructive]
| Name | Required | Description | Default |
|---|---|---|---|
| active | Yes | ||
| sys_id | Yes | ||
| confirmation | No | Required when activating: I_UNDERSTAND |
Changes observed during successful MCP inspections.
v1.15.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds valuable context by saying activation requires confirmation and permanently deletes eligible archived records. It does not describe deactivation behavior or permission requirements, but it meaningfully supplements the annotations.
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 front-loaded with the core action and immediately follows with the critical safety consequence and confirmation requirement. The extra [Destructive] marker is somewhat redundant with annotations but does not harm readability.
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 mutation with no output schema, the description provides the key warning about permanent deletion and the confirmation requirement. It could be more complete by explaining deactivation effects and the sys_id parameter, but it gives enough for correct and cautious invocation.
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 only 33%, and the description does not compensate for the undocumented sys_id and active parameters. It mentions confirmation for activation, but the schema already defines confirmation as requiring I_UNDERSTAND, so little meaning is added beyond structured data.
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 pair: activating or deactivating a destroy rule. It also discloses the destructive consequence, which clearly distinguishes it from sibling setters such as set_archive_rule_active and set_cleanup_rule_active.
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?
It implies when to use the tool by explaining that activation requires confirmation and permanently deletes eligible archived records. However, it does not explicitly compare this tool with sibling alternatives or state when deactivation should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.