Skip to main content
Glama
coreyhines

coreyhines/opnsense-mcp

by coreyhines
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

fw_rule

Manage OPNsense firewall filter rules and interface groups. Create, update, delete, toggle, list, and apply rule changes to control network traffic.

Instructions

Firewall filter rules, and the interface groups a rule can target so one rule covers several networks. Call action='help' for each action's fields and rules.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
logNo[update] Log packets matched by this rule
uuidNoRecord to act on, identified by a list action.
applyNoApply now rather than leaving the change staged. The default differs by action; action='help' reports each one.
descrNo[set_group] descr
quickNo[update] Stop evaluating further rules on a match
actionYesOperation to run. 'help' lists fields.
confirmNoToken returned by the previous call, to confirm.
enabledNoTarget state, set explicitly rather than flipped.
gatewayNo[create, update] gateway
membersNo[set_group] Interface keys the group should contain, e.g. ['opt3', 'opt4']. This replaces the membership rather than adding to it.
protocolNo[create, list, update] protocolany
directionNo[create, update] directionin
interfaceNo[create, list, update] interfacelan
rule_uuidNo[delete, toggle, update] UUID of the rule to delete
ipprotocolNo[create, update] ipprotocolinet
source_netNo[create, update] source_netany
source_notNo[update] Invert the source match
descriptionNoFree-text note stored on the record.
rule_actionNo[create, list, update] rule_actionpass
source_portNo[create, update] source_portany
interfacenotNo[update] Invert the interface match
destination_netNo[create, update] destination_netany
destination_notNo[update] Invert the destination match
destination_portNo[create, update] destination_portany

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.0

TDQS

C2.6/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention that changes can be staged, that apply/confirm may be required, that delete/toggle are destructive, or that set_group replaces membership rather than appending.

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?

The description is very concise and front-loaded with the domain. The pointer to action='help' earns its place, though the overall terseness leaves behavioral aspects unaddressed.

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 tool with 24 parameters, 9 actions, no annotations, and no output schema. The description gives only a high-level domain and a help pointer, which is insufficient orientation for correct selection and invocation of all these operations.

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 the schema does the heavy lifting for parameter semantics. The description's mention of interface groups adds mild context for group-related parameters, but it does not add meaningful meaning beyond the schema.

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

Purpose3/5

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

The description identifies the resource domain clearly: firewall filter rules and interface groups. However, it lacks a specific verb or action statement, leaving the actual operations to be inferred from the schema's action enum.

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?

The only usage guidance is to call action='help' for field-level details. There is no statement about when to use fw_rule versus sibling tools like nat_outbound or alias, and no exclusions or alternatives are given.

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