warden

Overview Schema Source Related Servers Discussions Admin

List the published WARDEN static-scan rule table

list_scan_rules

Read-onlyIdempotent

Return the in-force static-scan ruleset identity—version, digest, rule codes, severities, tiers, surfaces, and guards—to explain findings or reproduce scan verdicts with the same rules.

Instructions

Return the in-force static-scan ruleset: version, digest, and every rule's code, severity, tier (block vs advise), surfaces (name / description / inputSchema / title / outputSchema / annotations / metadata), optional regex source, and named guards. A recorded verdict is only reproducible together with this identity.

When to use: explain a finding code, confirm the current ruleset version and digest, or re-run a scan with the same table. include_source=true adds the regex source and flags for an independent re-implementation.

When NOT to use: evaluating a live tools/list (static_scan_tools or vet_mcp_server — those apply the table). This tool does not scan anything.

Behaviour: local snapshot of the compiled rule table, no network, no mutation. Digest is sha256 over the RFC 8785 form of {version, fold, rules} (each rule carries its raw flag).

Returns the ruleset object. Example: list_scan_rules({ include_source: false }).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_scan_rules"
  }
}

Input Schema

Name	Required	Description	Default
`include_source`	No	When true, each rule includes source (regex body) and flags so a third party can re-run the exact pattern. Default false — identity, tier, surfaces, and guards only, smaller payload.

Output Schema

Name	Required	Description
`fold`	Yes	Identity of the text normalisation applied before a non-raw rule is matched.
`rules`	Yes
`digest`	Yes	sha256-<base64> of the canonical rule table (preimage {version, fold, rules}).
`version`	Yes	Monotonic ruleset version.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.16.0Oct 14, 2026

changedOutput schema / properties / digest / description

Previous value: -"sha256-<base64> of the canonical rule table."New value: +"sha256-<base64> of the canonical rule table (preimage {version, fold, rules})."

addedOutput schema / properties / fold

Added value: +{
+  "description": "Identity of the text normalisation applied before a non-raw rule is matched.",
+  "type": "string"
+}

addedOutput schema / properties / rules / items / properties / raw

Added value: +{
+  "description": "true: matches the raw text; false: matches the folded text (see fold).",
+  "type": "boolean"
+}

changedOutput schema / properties / rules / items / properties / surfaces / items / enum

Previous value: -[
-  "name",
-  "description",
-  "inputSchema"
-]New value: +[
+  "name",
+  "description",
+  "inputSchema",
+  "title",
+  "outputSchema",
+  "annotations",
+  "metadata"
+]

changedOutput schema / properties / rules / items / required

Previous value: -[
-  "code",
-  "severity",
-  "tier",
-  "surfaces",
-  "guards"
-]New value: +[
+  "code",
+  "severity",
+  "tier",
+  "surfaces",
+  "guards",
+  "raw"
+]

changedOutput schema / required

Previous value: -[
-  "version",
-  "digest",
-  "rules"
-]New value: +[
+  "version",
+  "fold",
+  "digest",
+  "rules"
+]

First observedv1.0.0Sep 5, 2026

TDQS

A4.4/5.0

Behavior3/5

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

The annotations already declare readOnly, idempotent, non-destructive and closed-world, so the 'local snapshot, no network, no mutation' sentence largely restates them. The genuinely additive part is the reproducibility contract — sha256 over the RFC 8785 form of {version, fold, rules} — which tells an agent why the digest matters for re-running scans. Useful, but the behavioral disclosure is thin beyond that one line.

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 identity sentence, then clearly labelled When to use / When NOT to use / Behaviour / Returns blocks — easy to scan. Slightly overbuilt at the tail: the Returns line and the example call with a single defaulted boolean add little an agent could not get from the output schema.

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 one-parameter read tool with an output schema and full annotations, nothing material is missing: the agent knows what comes back, why the digest exists, what the flag changes, and which siblings to use instead. The reproducibility rationale is exactly the context an agent needs to use the returned identity correctly.

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% and the boolean is already well documented, so the baseline is 3. The description adds intent beyond the schema by explaining that include_source exists for independent re-implementation and that the default gives a smaller payload, which tells an agent when the flag is worth setting.

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 ('Return the in-force static-scan ruleset') and enumerates exactly what is in it: version, digest, rule code, severity, tier, surfaces, regex source, guards. It also explicitly separates itself from static_scan_tools and vet_mcp_server, so an agent can pick the right tool 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?

Gives three concrete when-to-use triggers (explain a finding code, confirm version/digest, re-run with the same table) and an explicit when-NOT-to-use section naming the sibling tools that actually perform scanning. No inference is required about which tool applies the ruleset versus describes it.

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

Deploy Server