iris-eval/mcp-server

Delete or Disable Custom Rule

delete_rule

Destructive

Delete a deployed custom evaluation rule or disable/re-enable it without removal, controlling whether it fires on the next evaluate_output call.

Instructions

Remove a deployed custom rule — or, with enabled, disable or re-enable it without removing it — effective on the next evaluate_output call.

What it does. Without enabled: deletes the rule and writes an audit entry; deleted is false when no rule has that id. With enabled: false stops it firing and keeps it stored, true re-enables it. Past evaluations are untouched. Full detail: iris://capabilities.

When not to use it. On built-in rules (they are not in the store). To replace a rule (deploy_rule with replace: true).

Returns. JSON: deleted, rule_id, toggled, enabled, rule.

Errors. IRIS_STORAGE_ERROR. A malformed rule_id is refused. Failures return {"error":{code,message,recovery}} with isError; follow recovery.

Siblings. deploy_rule — add or replace a rule; list_rules — find the id; evaluate_output — where the rule fires.

Input Schema

Name	Required	Description	Default
`enabled`	No	When present the rule is kept: false disables it (stops firing), true re-enables it. Omit to delete
`rule_id`	Yes	Rule id to delete or toggle (format: rule-<hex>); obtained from list_rules or deploy_rule response

Output Schema

Name	Required	Description	Default
`rule`	No
`deleted`	Yes
`enabled`	No
`rule_id`	Yes
`toggled`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.10.1Oct 26, 2026

changedInput schema / properties / enabled / description

Previous value: -"When present the rule is NOT deleted: false DISABLES it (kept in the store, stops firing immediately, history and provenance preserved); true RE-ENABLES a disabled rule. Omit to delete"New value: +"When present the rule is kept: false disables it (stops firing), true re-enables it. Omit to delete"

removedOutput schema / properties / deleted / description

Removed value: -"true when a rule was removed; always false on a toggle"

removedOutput schema / properties / enabled / description

Removed value: -"toggle only: the rule's state after the call"

removedOutput schema / properties / rule / description
```
Removed value: -"toggle only: the rule as stored"
```
removedOutput schema / properties / rule_id / description
```
Removed value: -"the id that was asked for"
```

removedOutput schema / properties / toggled / description

Removed value: -"toggle only: true when the rule exists (also when it was already in the requested state)"

Changed1 schema field changedv0.9.0Sep 5, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "deleted": {
+      "description": "true when a rule was removed; always false on a toggle",
+      "type": "boolean"
+    },
+    "enabled": {
+      "description": "toggle only: the rule's state after the call",
+      "type": "boolean"
+    },
+    "rule": {
+      "additionalProperties": {},
+      "description": "toggle only: the rule as stored",
+      "properties": {},
+      "type": "object"
+    },
+    "rule_id": {
+      "description": "the id that was asked for",
+      "type": "string"
+    },
+    "toggled": {
+      "description": "toggle only: true when the rule exists (also when it was already in the requested state)",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "deleted",
+    "rule_id"
+  ],
+  "type": "object"
+}

Changed3 schema fields changedv0.8.0Sep 4, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / enabled

Added value: +{
+  "description": "When present the rule is NOT deleted: false DISABLES it (kept in the store, stops firing immediately, history and provenance preserved); true RE-ENABLES a disabled rule. Omit to delete",
+  "type": "boolean"
+}

changedInput schema / properties / rule_id / description

Previous value: -"Rule id to delete (format: rule-<hex>); obtained from list_rules or deploy_rule response"New value: +"Rule id to delete or toggle (format: rule-<hex>); obtained from list_rules or deploy_rule response"

Changed1 schema field changedv0.4.6Aug 11, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
Addedv0.1.10May 3, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Goes well beyond the destructive/not-idempotent annotations by disclosing that an audit entry is written, that 'deleted' is false when the id is absent, that past evaluations are untouched, and that the change applies on the next evaluate_output. Error codes and a recovery-following convention are also spelled out. The only shortfall is that reversibility of the delete itself (no restore path) is not explicitly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded summary sentence captures the delete-or-toggle duality before any detail, and the labelled sections (What it does / When not to use it / Returns / Errors / Siblings) make it scannable. Slight redundancy in enumerating return fields that an output schema already covers.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive two-parameter mutation tool, the description covers preconditions (custom rules only), side effects (audit entry, next-evaluation timing), failure modes and recovery. Return-value enumeration is redundant given an output schema, but that is harmless rather than a gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented, and the description largely restates them (omit 'enabled' to delete, false disables, true re-enables). It adds the small point that a malformed rule_id is refused, but supplies no format detail beyond the schema pattern.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Remove a deployed custom rule') plus the alternate mode gated on 'enabled', so the agent immediately knows this tool both deletes and toggles. The sibling section names deploy_rule, list_rules and evaluate_output, making it distinguishable without opening their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

An explicit 'When not to use it' block excludes built-in rules and redirects replacement to deploy_rule with replace: true. The Siblings line further maps each alternative to its role (find the id, add/replace, where the rule fires), leaving nothing to inference.

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

Deploy Server