Skip to main content
Glama
Sign In
Aegis Guardrails

Aegis Guardrails

by nseney1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

aegis_list_rules

Read-onlyIdempotent

Lists all project rules with metadata and fitness flags, shows rules edited since the last sync, and reports ignored non-rule files under .aegis/rules/ for pre-edit auditing.

Instructions

Lists every rule with metadata and ledger fitness (_error if unloadable, _expired: true if retired), the stale_rules edited since the last aegis sync, and non-rule files under .aegis/rules/ (ignored). Records no scan or exposure: call aegis_scan before editing files.

Input Schema

NameRequiredDescriptionDefault
viewNo'full' (default), 'summary' (key fields, lists capped at 10 plus <list>_count) or 'ids'.
rule_typeNoOnly rules and stale_rules of this type.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv4.4.0
    • changedInput schema / properties / rule_type / description
      Previous value: -"Optional filter restricting both 'rules' and 'stale_rules' to a single rule category ('invariant', 'trap', 'gate', 'boundary', 'persona', or 'contract'). Omit to list all categories."New value: +"Only rules and stale_rules of this type."
    • changedInput schema / properties / view / description
      Previous value: -"Optional response projection: 'full' (default, complete payload), 'summary' (retains identity/type/status/fitness fields, caps lists at 10 items, and adds <list>_count), or 'ids' (projects each list to rule ID strings). Error responses are never projected."New value: +"'full' (default), 'summary' (key fields, lists capped at 10 plus <list>_count) or 'ids'."
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": false,
-  "properties": {
-    "error": {
-      "description": "Error message when status='FAIL'.",
-      "type": "string"
-    },
-    "ignored": {
-      "description": "Non-rule markdown files under .aegis/rules/ with path and reason.",
-      "type": "array"
-    },
-    "ignored_count": {
-      "description": "Total count of ignored files before 'summary' view truncation (present when view='summary').",
-      "type": "integer"
-    },
-    "rules": {
-      "description": "Workspace rule records with metadata and ledger fitness (or rule ID strings when view='ids').",
-      "type": "array"
-    },
-    "rules_count": {
-      "description": "Total count of rules before 'summary' view truncation (present when view='summary').",
-      "type": "integer"
-    },
-    "stale_rules": {
-      "description": "Rules edited since the last 'aegis sync' derived-file regeneration.",
-      "type": "array"
-    },
-    "stale_rules_count": {
-      "description": "Total count of stale_rules before 'summary' view truncation (present when view='summary').",
-      "type": "integer"
-    },
-    "status": {
-      "description": "Present with value 'FAIL' only when the rules directory cannot be safely loaded.",
-      "type": "string"
-    }
-  },
-  "required": [
-    "rules",
-    "stale_rules",
-    "ignored"
-  ],
-  "type": "object"
-}New value: +null
  2. Changed3 schema fields changedv4.3.4
    • changedInput schema / properties / rule_type / description
      Previous value: -"Optional rule type filter."New value: +"Optional filter restricting both 'rules' and 'stale_rules' to a single rule category ('invariant', 'trap', 'gate', 'boundary', 'persona', or 'contract'). Omit to list all categories."
    • changedInput schema / properties / view / description
      Previous value: -"Optional response projection: full (default), summary or ids."New value: +"Optional response projection: 'full' (default, complete payload), 'summary' (retains identity/type/status/fitness fields, caps lists at 10 items, and adds <list>_count), or 'ids' (projects each list to rule ID strings). Error responses are never projected."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "error": {
+      "description": "Error message when status='FAIL'.",
+      "type": "string"
+    },
+    "ignored": {
+      "description": "Non-rule markdown files under .aegis/rules/ with path and reason.",
+      "type": "array"
+    },
+    "ignored_count": {
+      "description": "Total count of ignored files before 'summary' view truncation (present when view='summary').",
+      "type": "integer"
+    },
+    "rules": {
+      "description": "Workspace rule records with metadata and ledger fitness (or rule ID strings when view='ids').",
+      "type": "array"
+    },
+    "rules_count": {
+      "description": "Total count of rules before 'summary' view truncation (present when view='summary').",
+      "type": "integer"
+    },
+    "stale_rules": {
+      "description": "Rules edited since the last 'aegis sync' derived-file regeneration.",
+      "type": "array"
+    },
+    "stale_rules_count": {
+      "description": "Total count of stale_rules before 'summary' view truncation (present when view='summary').",
+      "type": "integer"
+    },
+    "status": {
+      "description": "Present with value 'FAIL' only when the rules directory cannot be safely loaded.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "rules",
+    "stale_rules",
+    "ignored"
+  ],
+  "type": "object"
+}
  3. First observedv0.1.0

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context about sentinel fields (`_error` for unloadable rules, `_expired: true` for retired ones) and the existence of stale_rules and ignored files. However, it doesn't state anything about pagination, capping, or ordering beyond what the schema's view description hints at. With annotations covering safety, a 3 is fair; the added context about return shape nudges the score up.

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?

One dense sentence packs purpose, three output categories, and a prerequisite call, front-loading the main verb. It is slightly over-packed with parentheticals, which impacts readability, but every clause earns its place.

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

Completeness4/5

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

There is no output schema, so the description must convey the return shape. It covers the main fields (metadata, fitness, stale_rules, ignored) and sentinel values, which is sufficient for an agent to anticipate the response. Minor gap: the view mode implications (capping at 10, ids) are left to the schema.

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?

The schema describes both parameters at 100% coverage, so the description doesn't need to repeat their semantics. It does add conceptual context by mentioning stale_rules inline, which helps the agent understand what rule_type filters against. Baseline 3 is appropriate when the schema carries the parameter documentation burden.

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 (Lists) and resource (rules) plus scope: metadata, ledger fitness flags, stale rules, and ignored non-rule files. This is distinguishable from the siblings aegis_scan, aegis_create_rule, aegis_report_outcome, and aegis_capture_insight, none of which are list operations.

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

Usage Guidelines4/5

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

Explicitly warns that this tool records no scan or exposure and directs the agent to call aegis_scan before editing files, naming the alternative. It does not, however, explain when to prefer one list view over another, leaving that to the schema.

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

Deploy Server

Other Tools