iris-eval/mcp-server

List Rules

list_rules

Read-onlyIdempotent

Retrieves every built-in and custom evaluation rule with required inputs, criticality, accuracy, and enabled status, so you can audit which checks will run before evaluating output quality.

Instructions

The rule inventory: every built-in rule with what it needs, its effective criticality and published accuracy, plus every deployed custom rule.

What it does. Read-only, no network. built_in is never narrowed by the filters; a rule whose needs are absent skips, never passes. Read critical and criticalSource before trusting passed: true. rules is the custom-rule store, filterable by eval_type and enabled_only. Full detail: iris://capabilities.

When not to use it. To add, remove or pause a rule (deploy_rule, delete_rule); built-in rules cannot be.

Returns. JSON: untrusted, rules, total, enabled_count, built_in, quarantined, plugins.

Errors. IRIS_INTERNAL_ERROR if the store cannot be read; a missing store is an empty list. Failures return {"error":{code,message,recovery}} with isError; follow recovery.

Siblings. deploy_rule — add a custom rule; delete_rule — remove, disable or re-enable one; evaluate_output — run the rules.

Input Schema

Name	Required	Description	Default
`eval_type`	No	Filter the custom rules to one eval category (exact match); built_in is never filtered
`enabled_only`	No	Return only enabled custom rules (a rule disabled with delete_rule stays in the store and does not fire)

Output Schema

Name	Required	Description	Default
`rules`	Yes
`total`	Yes
`plugins`	Yes
`built_in`	Yes
`untrusted`	No
`quarantined`	Yes
`enabled_count`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed22 schema fields changedv0.10.1Oct 26, 2026

removedOutput schema / properties / built_in / description

Removed value: -"the shipped roster, never filtered: name, category, description, weight, kind, mechanism, needs, question, classes, version, the EFFECTIVE critical flag with criticalSource, and proof (published precision, recall, intervals and ppvAt from https://iris-eval.com/proof; null where the proof is a conformance check)"

removedOutput schema / properties / built_in / items / additionalProperties
```
Removed value: -{}
```
removedOutput schema / properties / built_in / items / properties
```
Removed value: -{
-  "name": {
-    "type": "string"
-  }
-}
```
removedOutput schema / properties / built_in / items / required
```
Removed value: -[
-  "name"
-]
```
removedOutput schema / properties / built_in / items / type
```
Removed value: -"object"
```
removedOutput schema / properties / enabled_count / description
```
Removed value: -"of those, how many are enabled"
```
removedOutput schema / properties / enabled_count / maximum
```
Removed value: -9007199254740991
```
removedOutput schema / properties / enabled_count / minimum
```
Removed value: --9007199254740991
```
changedOutput schema / properties / enabled_count / type
```
Previous value: -"integer"New value: +"number"
```

addedOutput schema / properties / plugins

Added value: +{
+  "items": {},
+  "type": "array"
+}

removedOutput schema / properties / quarantined / description

Removed value: -"entries in the store this version could not validate; they do not fire and are never deleted by a deploy"

removedOutput schema / properties / rules / description

Removed value: -"the deployed custom rules after the filters: id, name, description, evalType, severity, definition, enabled, createdAt, updatedAt, version, sourceMomentId"

removedOutput schema / properties / rules / items / additionalProperties
```
Removed value: -{}
```

removedOutput schema / properties / rules / items / properties

Removed value: -{
-  "id": {
-    "type": "string"
-  },
-  "name": {
-    "type": "string"
-  }
-}

removedOutput schema / properties / rules / items / required
```
Removed value: -[
-  "id",
-  "name"
-]
```
removedOutput schema / properties / rules / items / type
```
Removed value: -"object"
```
removedOutput schema / properties / total / description
```
Removed value: -"custom rules after the filters"
```
removedOutput schema / properties / total / maximum
```
Removed value: -9007199254740991
```
removedOutput schema / properties / total / minimum
```
Removed value: --9007199254740991
```

changedOutput schema / properties / total / type

Previous value: -"integer"New value: +"number"

addedOutput schema / properties / untrusted

Added value: +{
+  "additionalProperties": {},
+  "properties": {},
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "rules",
-  "total",
-  "enabled_count",
-  "built_in",
-  "quarantined"
-]New value: +[
+  "rules",
+  "total",
+  "enabled_count",
+  "built_in",
+  "quarantined",
+  "plugins"
+]

Changed3 schema fields changedv0.9.0Sep 5, 2026

changedInput schema / properties / enabled_only / description

Previous value: -"Return only enabled rules (excludes disabled ones)"New value: +"Return only enabled custom rules (a rule disabled with delete_rule stays in the store and does not fire)"

changedInput schema / properties / eval_type / description

Previous value: -"Filter to rules of a specific eval category"New value: +"Filter the custom rules to one eval category (exact match); built_in is never filtered"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "built_in": {
+      "description": "the shipped roster, never filtered: name, category, description, weight, kind, mechanism, needs, question, classes, version, the EFFECTIVE critical flag with criticalSource, and proof (published precision, recall, intervals and ppvAt from https://iris-eval.com/proof; null where the proof is a conformance check)",
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "name": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "name"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "enabled_count": {
+      "description": "of those, how many are enabled",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "quarantined": {
+      "description": "entries in the store this version could not validate; they do not fire and are never deleted by a deploy",
+      "items": {},
+      "type": "array"
+    },
+    "rules": {
+      "description": "the deployed custom rules after the filters: id, name, description, evalType, severity, definition, enabled, createdAt, updatedAt, version, sourceMomentId",
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "id": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "name"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "total": {
+      "description": "custom rules after the filters",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "rules",
+    "total",
+    "enabled_count",
+    "built_in",
+    "quarantined"
+  ],
+  "type": "object"
+}

Changed1 schema field changedv0.8.0Sep 4, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
Changed1 schema field changedv0.4.6Aug 11, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
Addedv0.1.10May 3, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/destructive=false, and the description still adds genuinely non-obvious behavior: built_in is never narrowed by filters, rules whose needs are absent skip rather than pass, and agents must read critical/criticalSource before trusting passed:true. It also documents the error envelope and recovery path, which annotations cannot convey.

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-loads the inventory summary, then sections by What/When-not/Returns/Errors/Siblings, so an agent can scan to the part it needs. Slightly header-heavy and the Siblings list partially duplicates the tool roster, but no sentence is filler.

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?

Despite an output schema existing, the description still names the top-level return keys and flags the list as untrusted, plus covers error codes and recovery. For a read-only dual-store listing tool, nothing an agent needs to call it or interpret results is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it clarifies that filters apply only to custom rules and never to built_in, and that a rule disabled via delete_rule persists in the store without firing. It stops short of restating the enum values, which is appropriate for a 100%-covered schema.

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 ("The rule inventory") and enumerates exactly what is returned: built-in rules with needs/criticality/accuracy plus deployed custom rules. An agent can distinguish it from deploy_rule, delete_rule and evaluate_output without opening any schema.

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?

Has an explicit "When not to use it" section routing to deploy_rule/delete_rule and noting built-ins cannot be modified, plus a Siblings line that spells out each alternative's role. The when/when-not/alternative triad is fully covered.

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

Deploy Server