Skip to main content
Glama

add_interception_rule

Add a custom rule to an active 3D printing session to monitor temperature, feedrate, flow, position, or command patterns and apply allow, block, modify, pause, or alert actions when thresholds are met.

Instructions

Add a custom interception rule to an active session.

Args:
    session_id: Target session ID.
    name: Human-readable rule name.
    trigger: Trigger type -- one of: temp_exceeds, temp_below,
        temp_delta, feedrate_exceeds, flow_anomaly, position_limit,
        command_blocked, pattern_match, always, layer_change.
    action: Action to take -- one of: allow, block, modify, pause, alert.
    priority: Rule priority -- one of: critical, high, medium, low.
    threshold: Numeric threshold for trigger evaluation.
    threshold_max: Upper bound for range-based triggers.
    blocked_commands: List of G/M codes for command_blocked trigger.
    pattern: Regex pattern for pattern_match trigger.
    modify_params: Parameter overrides for modify action (e.g. {"F": 3000}).
    message: Human-readable explanation shown when rule fires.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "session_id": "<session_id>",
      "name": "<name>",
      "trigger": "<trigger>",
      "action": "<action>"
    },
    "name": "add_interception_rule"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesHuman-readable rule name.
actionYesAction to take -- one of: allow, block, modify, pause, alert.
messageNoHuman-readable explanation shown when rule fires. Default: "".
patternNoRegex pattern for pattern_match trigger.
triggerYesTrigger type -- one of: temp_exceeds, temp_below, temp_delta, feedrate_exceeds, flow_anomaly, position_limit, command_blocked, pattern_match, always, layer_change.
priorityNoRule priority -- one of: critical, high, medium, low. Default: "medium".
thresholdNoNumeric threshold for trigger evaluation.
session_idYesTarget session ID.
modify_paramsNoParameter overrides for modify action (e.g. {"F": 3000}).
threshold_maxNoUpper bound for range-based triggers.
blocked_commandsNoList of G/M codes for command_blocked trigger.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv1.5.1
    • addedInput schema / properties / action / description
      Added value: +"Action to take -- one of: allow, block, modify, pause, alert."
    • addedInput schema / properties / blocked_commands / description
      Added value: +"List of G/M codes for command_blocked trigger."
    • changedInput schema / properties / message / description
      Previous value: -"Default: \"\"."New value: +"Human-readable explanation shown when rule fires. Default: \"\"."
    • addedInput schema / properties / modify_params / description
      Added value: +"Parameter overrides for modify action (e.g. {\"F\": 3000})."
    • addedInput schema / properties / name / description
      Added value: +"Human-readable rule name."
    • addedInput schema / properties / pattern / description
      Added value: +"Regex pattern for pattern_match trigger."
    • changedInput schema / properties / priority / description
      Previous value: -"Default: \"medium\"."New value: +"Rule priority -- one of: critical, high, medium, low. Default: \"medium\"."
    • addedInput schema / properties / session_id / description
      Added value: +"Target session ID."
    • addedInput schema / properties / threshold / description
      Added value: +"Numeric threshold for trigger evaluation."
    • addedInput schema / properties / threshold_max / description
      Added value: +"Upper bound for range-based triggers."
    • addedInput schema / properties / trigger / description
      Added value: +"Trigger type -- one of: temp_exceeds, temp_below, temp_delta, feedrate_exceeds, flow_anomaly, position_limit, command_blocked, pattern_match, always, layer_change."
  2. Changed9 schema fields changedv1.5.0
    • removedInput schema / properties / blocked_commands / default
      Removed value: -null
    • removedInput schema / properties / message / default
      Removed value: -""
    • addedInput schema / properties / message / description
      Added value: +"Default: \"\"."
    • removedInput schema / properties / modify_params / default
      Removed value: -null
    • removedInput schema / properties / pattern / default
      Removed value: -null
    • removedInput schema / properties / priority / default
      Removed value: -"medium"
    • addedInput schema / properties / priority / description
      Added value: +"Default: \"medium\"."
    • removedInput schema / properties / threshold / default
      Removed value: -null
    • removedInput schema / properties / threshold_max / default
      Removed value: -null
  3. First observedv0.1.0

TDQS

C2.8/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. Beyond that the description adds almost nothing: it does not say whether the rule takes effect immediately mid-print, whether it persists after the session ends, how overlapping rules are resolved by priority, or what happens if a rule with the same name already exists.

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

Conciseness3/5

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

The purpose sentence is front-loaded and clear, but the following Args block repeats the schema field-by-field at zero informational gain, padding a short description considerably. Structure is legible (docstring style) yet about half the text earns no place given 100% schema coverage.

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

Completeness2/5

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

This is a complex 11-parameter mutation tool with conditional parameter dependencies, and the description leaves the important parts unaddressed: no trigger-to-parameter mapping, no priority/precedence semantics, no lifecycle or persistence behavior. The output schema and annotations relieve some burden, but not enough for a tool of this complexity.

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 every parameter is already documented and the Args block is largely verbatim duplication of the schema text. It does add cross-field hints (blocked_commands for command_blocked, pattern for pattern_match), but never explains which optional parameters are required for which trigger/action combination, which is the real semantic gap for a 10-trigger, 5-action tool.

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

Purpose4/5

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

States a specific verb and resource ('Add a custom interception rule') plus a scoping qualifier ('to an active session'), which is enough to distinguish it from list/get-style siblings like get_interception_status. It stops short of naming the closest sibling, remove_interception_rule, or distinguishing itself from load_safety_interception_rules and intercept_gcode_command.

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

Usage Guidelines2/5

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

There is no when-to-use guidance at all: nothing says whether this should be preferred over load_safety_interception_rules, when a rule is appropriate versus a one-off intercept_gcode_command, or what prerequisites exist (an active monitored session, required permissions). The only usage-adjacent signal is the phrase 'active session', which is a constraint rather than guidance.

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