pfSense MCP Server

create_dhcp_static_mapping

Reserve a fixed IP for a device on a pfSense interface by creating a DHCP static reservation based on its MAC address, ensuring consistent lease assignment.

Instructions

Create a DHCP static mapping (reservation)

Lease times are not optional in effect: the API package materialises defaultleasetime 7200 and maxleasetime 86400 whenever the field is absent from the request, and a later PATCH sending an explicit null returns 200 but reads back unchanged. Pass the values you want at create time.

Whether the DHCP daemon acts on the per-host values is unverified. On an ISC deployment they were present in config.xml but absent from the generated dhcpd.conf; the Kea config was not readable.

Input Schema

TableJSON Schema

Name	Required	Description
`domain`	No	Optional domain name
`gateway`	No	Optional gateway override
`hostname`	No	Optional hostname
`interface`	Yes	Interface/DHCP pool (e.g., "lan")
`dns_server`	No	Optional DNS server override
`ip_address`	Yes	IP address to assign
`description`	No	Optional description
`mac_address`	Yes	MAC address to reserve for
`max_lease_time`	No	Per-host maximum lease time in seconds. Omitted from the request when unset, in which case the API package applies its own default of 86400.
`apply_immediately`	No	Whether to apply changes immediately
`default_lease_time`	No	Per-host default lease time in seconds. Omitted from the request when unset, in which case the API package applies its own default of 7200.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.1.0Sep 26, 2026

addedInput schema / properties / default_lease_time

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Per-host default lease time in seconds. Omitted from the request when unset, in which case the API package applies its own default of 7200."
+}

addedInput schema / properties / max_lease_time

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Per-host maximum lease time in seconds. Omitted from the request when unset, in which case the API package applies its own default of 86400."
+}

First observedv1.0.0Aug 9, 2026

TDQS

A3.8/5.0

Behavior5/5

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

Excellent disclosure: describes that lease times are effectively mandatory due to the API materializing defaults (7200/86400), that later PATCH with null is ineffective, and that the DHCP daemon's application of per-host values is unverified on ISC and unreadable on Kea. These details go well beyond the annotations' basic readOnlyHint/destructiveHint flags.

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 efficiently structured: starts with a clear one-line purpose, then two short paragraphs of critical caveats. Each sentence adds value, with no redundant fluff. The lease time and daemon uncertainty notes are essential for correct usage, so the length is justified.

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?

Given the tool's complexity (11 parameters, output schema, and annotations), the description covers the most critical behavioral pitfalls—lease time handling and daemon uncertainty. It does not mention prerequisites like pool existence or IP/MAC uniqueness, but those can be inferred from domain knowledge and the schema's example for interface.

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 parameters already have descriptive text, including the default lease time behavior. The description adds the important nuance that passing explicit null later won't change data, reinforcing that lease times must be set at creation. This is a valuable supplement to the schema.

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?

Description states a clear verb and resource: 'Create a DHCP static mapping (reservation)'. This clearly separates it from related operations like update_dhcp_static_mapping or search_dhcp_static_mappings. Though it doesn't explicitly name alternatives, the action is unambiguous.

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 on when to use this tool versus updating or searching existing mappings. It does not mention prerequisites like checking for duplicate IP/MAC addresses or ensuring the interface pool exists. The description focuses on behavioral caveats rather than tool selection context.

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

Deploy Server