Skip to main content
Glama
coreyhines

coreyhines/opnsense-mcp

by coreyhines
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

shaper

Create and manage bandwidth pipes, queues, and rules to prioritize traffic, then apply or audit changes to optimize network performance.

Instructions

Traffic shaper: pipes, queues, rules, and applying or auditing them. Call action='help' for each action's fields and rules.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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.
protoNo[create_rule, update_rule] proto
actionYesOperation to run. 'help' lists fields.
presetNo[apply_preset] presetbufferbloat_wan
weightNo[create_queue, update_queue] weight
confirmNoToken returned by the previous call, to confirm.
enabledNoTarget state, set explicitly rather than flipped.
sequenceNo[create_rule] Rule order; auto-assigned when omitted
bandwidthNo[create_pipe, update_pipe] bandwidth
directionNo[create_rule, update_rule] direction
fetch_allNo[list_pipes, list_queues, list_rules] When true, paginate until all rows are returned
interfaceNo[create_rule, list_rules, update_rule] interface
pipe_uuidNo[create_queue, update_queue] pipe_uuid
row_countNo[list_pipes, list_queues, list_rules] Search API page size (default 50, max 500)
schedulerNo[create_pipe, update_pipe] schedulerfq_codel
baseline_idNo[statistics] Optional baseline id from a prior shaper_statistics call for pkts/bytes delta comparison
descriptionNoFree-text note stored on the record.
snapshot_idNo[restore_snapshot] snapshot_id
target_uuidNo[create_rule, update_rule] target_uuid
upload_mbitNo[apply_preset] upload_mbit
download_mbitNo[apply_preset] download_mbit
include_auditNo[explain] When true, run audit first and weave findings into the narrative
wan_interfaceNo[apply_preset] wan_interfacewan
remove_orphansNo[restore_snapshot] Delete live objects whose UUID is absent from the snapshot
isp_upload_mbitNo[audit] Reference ISP upload rate in Mbit/s
bandwidth_metricNo[create_pipe, update_pipe] bandwidth_metricMbit
capture_snapshotNo[create_pipe, create_queue, create_rule, update_pipe, update_queue, update_rule] capture_snapshot
isp_download_mbitNo[audit] Reference ISP download rate in Mbit/s
wan_line_rate_mbitNo[audit] WAN physical line rate cap in Mbit/s
mutation_snapshot_idNo[create_pipe, create_queue, create_rule, update_pipe, update_queue, update_rule] mutation_snapshot_id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.0

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It mentions applying and auditing, but does not disclose important behaviors like staged changes, snapshot/restore effects, confirm tokens, destructive operations, or the side effects of any of the many actions.

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 two compact clauses with no filler: it states the domain and provides a concrete self-service mechanism for deeper details. Every sentence earns its place.

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?

Given 31 parameters, 26 actions, no annotations, no output schema, and complex operations like snapshots and audits, this one-sentence definition is not complete. Pointing to action='help' mitigates the gap, but the description still leaves selection, behavioral, and side-effect context entirely undisclosed.

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 itself documents all parameters, including action-name prefixes. The description adds no parameter meaning beyond pointing to the help action, which is useful but does not elevate it above the baseline.

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 clearly identifies the tool as a traffic shaper operating on pipes, queues, and rules, and mentions applying/auditing. This is understandable and domain-specific, though it does not differentiate it from siblings beyond the domain label.

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 gives operational guidance by telling the agent to call action='help' for fields and rules, which is useful. However, it does not specify when to use this tool versus its siblings or when a particular action should be chosen.

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