pfSense MCP Server

create_traffic_limiter

Create a dummynet pipe to limit bandwidth on pfSense, specifying bandwidth, unit, and optional parameters like scheduler and queue management for traffic control.

Instructions

Create a traffic limiter (dummynet pipe)

Input Schema

TableJSON Schema

Name	Required	Description	Default
`aqm`	No	Queue management algorithm (droptail, codel, pie, red, gred)	droptail
`mask`	No	Mask type (none, srcaddress, dstaddress)
`name`	Yes	Limiter name
`descr`	No	Optional description
`sched`	No	Scheduler (wf2q+, fifo, qfq, rr, prio, fq_codel, fq_pie)	wf2q+
`enabled`	No	Whether the limiter is enabled
`maskbits`	No	Mask bits for per-host limiting
`bandwidth`	Yes	Bandwidth value
`bandwidthtype`	Yes	Bandwidth unit (b, Kb, Mb, Gb — Gb is sent as Mb)
`apply_immediately`	No	Whether to apply changes immediately

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.1.0Sep 26, 2026

addedInput schema / properties / aqm

Added value: +{
+  "default": "droptail",
+  "description": "Queue management algorithm (droptail, codel, pie, red, gred)",
+  "type": "string"
+}

changedInput schema / properties / bandwidthtype / description

Previous value: -"Bandwidth unit (Kb, Mb, Gb, b)"New value: +"Bandwidth unit (b, Kb, Mb, Gb — Gb is sent as Mb)"

addedInput schema / properties / sched

Added value: +{
+  "default": "wf2q+",
+  "description": "Scheduler (wf2q+, fifo, qfq, rr, prio, fq_codel, fq_pie)",
+  "type": "string"
+}

First observedv1.0.0Aug 9, 2026

TDQS

B3.3/5.0

Behavior3/5

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

Annotations (readOnlyHint=false, destructiveHint=false) already signal this is a write operation that isn't destructive, and the description's verb 'create' is consistent with those annotations. The description adds no behavioral context beyond that — no mention that apply_immediately=true by default means the live firewall config may change on creation, and no statement about prerequisites or side effects. This doesn't contradict the annotations, so a baseline 3 is appropriate.

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?

One short sentence with zero wasted words: the verb is front-loaded, the resource is named, and the parenthetical earns its place by clarifying what a traffic limiter is at the system level. Nothing could be cut without losing information.

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

Completeness3/5

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

The schema covers all 10 parameters and an output schema exists, so return values and parameter meaning are handled outside the description. However, the tool sits in a crowded bandwidth-management domain (shapers, queues, limiters) and the one-sentence description does nothing to explain when a limiter is the correct choice or how it relates to dummynet pipes in practice. Adequate, but with clear navigational gaps for an agent.

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 (bandwidth, bandwidthtype, sched, aqm, mask, maskbits, etc.) is already documented in structured form. The description adds zero parameter-level meaning. Per the rubric, high schema coverage sets the baseline at 3, which is correct here.

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?

The description states a specific verb and resource: 'Create a traffic limiter (dummynet pipe)'. The parenthetical adds domain-meaningful detail about the underlying mechanism, which helps differentiate it from the many shaper/queue siblings. It doesn't explicitly name the sibling it is not, but 'create' + 'traffic limiter' + 'dummynet pipe' is a clear, specific purpose.

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?

No guidance is given on when to use this tool versus its close siblings: delete_traffic_limiter, update_traffic_limiter, search_traffic_limiters, create_traffic_shaper, and create_shaper_queue. An agent cannot tell from the description whether a limiter, a shaper, or a queue is the right construct for a given bandwidth-management task. No exclusions or alternative routes are provided.

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

Deploy Server