Skip to main content
Glama
amittell

firewalla-mcp-server

by amittell
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

search_rules

Read-only

Find firewall rules by target, action, or status using Firewalla query syntax to locate matching rules across boxes.

Instructions

Search firewall rules by target, action or status; the MSP API applies the query (GET /v2/rules). Supports all rule fields. Scoped to FIREWALLA_BOX_ID when set, otherwise every box.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of rules to return
queryYesSearch query using Firewalla syntax. Supported fields: action:allow/block/timelimit, target.type:domain/ip/device, target.value:*.facebook.com, status:active/paused, direction:bidirection/inbound/outbound, protocol:tcp/udp, box.id:box_gid, scope.type:device/network, notes:"description text". Examples: "action:block AND target.value:*.social.com", "status:paused", "target.type:domain AND action:block"

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.0
    • changedInput schema / properties / query / description
      Previous value: -"Search query using Firewalla syntax. Supported fields: action:allow/block/timelimit, target.type:domain/ip/device, target.value:*.facebook.com, status:active/paused, direction:bidirection/inbound/outbound, protocol:tcp/udp, gid:box_id, scope.type:device/network, notes:\"description text\". Examples: \"action:block AND target.value:*.social.com\", \"status:paused\", \"target.type:domain AND action:block\""New value: +"Search query using Firewalla syntax. Supported fields: action:allow/block/timelimit, target.type:domain/ip/device, target.value:*.facebook.com, status:active/paused, direction:bidirection/inbound/outbound, protocol:tcp/udp, box.id:box_gid, scope.type:device/network, notes:\"description text\". Examples: \"action:block AND target.value:*.social.com\", \"status:paused\", \"target.type:domain AND action:block\""
  2. Changed2 schema fields changedv1.3.0
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "Maximum number of rules to return",
+  "type": "number"
+}
    • changedInput schema / required
      Previous value: -[]New value: +[
+  "query"
+]
  3. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds behavioral value beyond that: it identifies the API endpoint (GET /v2/rules), notes that all rule fields are supported, and explains the FIREWALLA_BOX_ID scoping behavior that affects which rules are returned.

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?

The description is compact and front-loaded: the core purpose appears in the first clause, followed by only necessary scope and capability details. There is no redundant filler, and each sentence contributes useful information.

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?

For a read-only search tool with a rich schema, the description adequately covers the query scope and the box-scoping behavior. It does not describe the response payload, and there is no output schema to fill that gap, but the return of firewall rules is strongly implied; a brief note on result format would make it fully complete.

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 provides 100% parameter coverage, including a detailed query syntax and examples for both query and limit. The description's reference to 'target, action or status' is only a light restatement of the schema, not additional semantic meaning, so the baseline of 3 applies.

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?

The description opens with 'Search firewall rules by target, action or status', which names a specific verb, resource, and query dimensions. Adding 'Supports all rule fields' clarifies the scope and distinguishes it from simple list/get siblings like get_network_rules.

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

Usage Guidelines3/5

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

The description provides useful context, especially 'Scoped to FIREWALLA_BOX_ID when set, otherwise every box', and implies query-based use. However, it does not explicitly state when to prefer search_rules over alternatives such as get_network_rules or search_flows, nor does it give when-not-to-use 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