Skip to main content
Glama
Sign In
SkillTotal

SkillTotal

by pezhik
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

List detection rules

list_rules
Read-only

List SkillTotal detection rules: id, severity, category, title, threat class and capability. Use it to look up a rule id from a scan_component or diff_components result, or to see what SkillTotal checks before scanning.

Instructions

List SkillTotal detection rules: id, severity, category, title, threat class and capability. Use it to look up a rule id from a scan_component or diff_components result, or to see what SkillTotal checks before scanning. It reads the rule list bundled with this engine: offline, instant, no side effects. With no arguments it returns every rule. ids and query narrow the list and combine (a rule must match both); no match returns an empty array []. Pass verbose=true for each rule's description and recommendation.

Input Schema

NameRequiredDescriptionDefault
idsNoOnly these rule ids, as a finding's rule field shows them (case-insensitive). Unknown ids are skipped, not an error.
queryNoOnly rules whose id or title contains this text (case-insensitive substring; descriptions are not searched).
verboseNoAlso return each rule's description and recommendation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.79.1
    • changedInput schema / properties / ids / description
      Previous value: -"Only these rule ids (case-insensitive)."New value: +"Only these rule ids, as a finding's rule field shows them (case-insensitive). Unknown ids are skipped, not an error."
    • changedInput schema / properties / query / description
      Previous value: -"Only rules whose id or title contains this text (case-insensitive)."New value: +"Only rules whose id or title contains this text (case-insensitive substring; descriptions are not searched)."
  2. Changed3 schema fields changedv0.75.0
    • addedInput schema / properties / ids
      Added value: +{
+  "description": "Only these rule ids (case-insensitive).",
+  "examples": [
+    [
+      "ST-SHELL-PIPE-EXEC"
+    ]
+  ],
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / query
      Added value: +{
+  "description": "Only rules whose id or title contains this text (case-insensitive).",
+  "examples": [
+    "prompt injection"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / verbose / examples
      Added value: +[
+  true
+]
  3. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint/openWorldHint=false, and the description goes beyond them: the rule list is bundled with the engine, so calls are offline and instant, and it discloses the no-match behavior (empty array []) plus the effect of verbose=true. This is exactly the operational context an agent needs before deciding to call it.

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

Conciseness5/5

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

Front-loads what is returned, then use cases, then behavior and filtering, in four tight sentences with no filler. Every clause carries information an agent would otherwise have to infer.

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?

There is no output schema, and the description compensates by listing the returned fields, the empty-result shape, and what verbose adds. For a zero-required-parameter read tool with full schema coverage, nothing needed for correct invocation 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; the description adds real value on top by stating that ids and query combine with AND semantics and that a non-matching filter yields [] rather than an error. It doesn't restate case-insensitivity or unknown-id skipping, which the schema already covers.

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 (list detection rules) and enumerates the fields returned: id, severity, category, title, threat class, capability. It also distinguishes itself from siblings by naming scan_component and diff_components as the sources of rule ids, so an agent can place it in the workflow without opening the 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 two concrete when-to-use conditions: resolving a rule id from a scan_component or diff_components result, and previewing what SkillTotal checks before scanning. Sibling tools are named explicitly, and the 'before scanning' framing makes the sequencing relative to scan_component obvious.

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