Skip to main content
Glama
rstierli

FortiManager MCP Server

by rstierli

update_device_wtp_profile_radio

Update a single radio's channel and/or channel width on a FortiAP profile while preserving existing radio settings by reading the profile first and writing back unchanged fields.

Instructions

Update a single radio's channel and/or channel width on a FortiAP profile.

This is a read-modify-write, like assign_vap_to_wtp_profile: the profile is read first and every other field already on the target radio (band, power, vap-all, vaps, mode, ...) is carried through unchanged, minus a couple of read-only bookkeeping keys the API injects on GET but rejects on write (see _WTP_RADIO_READONLY_KEYS). FortiManager replaces a nested radio object rather than merging into it, so writing back only channel/channel-bonding would reset the rest to defaults on the next install_device_settings.

Args: device: Managed device name profile: FortiAP (WTP) profile name radio: Radio to update, 1-3 channel: Channel(s) to pin the radio to. For radio 1/2 (2.4/5GHz) this is a single-element list, e.g. [36], to pin one channel. For radio 3 (6GHz) at a bonding width above 20MHz, FortiOS represents the wide channel as the full list of its member 20MHz sub-channels rather than a single label -- pass either the single conventional wide-channel label (e.g. [15] for 160MHz channel 15) and it is expanded to the correct member list automatically, or the explicit member list itself (e.g. [1, 5, 9, 13, 17, 21, 25, 29]). channel_bonding: Channel width/bonding, one of WTP_PROFILE_CHANNEL_BONDING_MODES ("20MHz", "40MHz", "80MHz", "160MHz") vdom: VDOM the profile lives in (default "root")

Returns: Update result

Input Schema

NameRequiredDescriptionDefault
vdomNoroot
radioYes
deviceYes
channelNo
profileYes
channel_bondingNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.12.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses the read-modify-write behavior, preservation of existing radio fields, rejection of read-only bookkeeping keys, and the critical FortiManager behavior where nested radio objects are replaced rather than merged. This directly warns that partial writes could reset fields on the next install_device_settings.

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 front-loaded with purpose and then organized into behavior, args, and returns. It is somewhat long and includes an internal implementation reference (_WTP_RADIO_READONLY_KEYS), but the detail is largely justified by the complexity of channel semantics and the read-modify-write behavior.

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

Completeness5/5

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

Given the absence of annotations, 0% schema description coverage, and six parameters, the description is complete enough for correct invocation. It covers the mutation behavior, preservation semantics, parameter meanings, and channel edge cases; return values are covered by the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates thoroughly. It explains device, profile, radio range, vdom, channel handling for 2.4/5GHz versus 6GHz wide channels, automatic expansion of conventional wide-channel labels, and allowed channel_bonding values.

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 states a specific verb and resource: updating a single radio's channel and/or channel width on a FortiAP profile. The narrow scope distinguishes it from broader WTP profile operations such as update_device_wtp, even though that sibling is not named explicitly.

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

Usage Guidelines4/5

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

The description clearly frames the operation as a read-modify-write and explains that other radio fields are preserved, which helps an agent understand when this tool is appropriate. It does not explicitly compare against get_device_wtp_profile or update_device_wtp, so the when-to-use guidance is strong but not fully explicit.

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