Skip to main content
Glama
rstierli

FortiManager MCP Server

by rstierli

delete_device_wtp

Removes a managed FortiAP registration from a device DB by serial, dropping its wtp-profile reference; deleting the last AP may prune that profile on install.

Instructions

Delete a managed FortiAP registration from a device's device DB.

This drops the AP's reference to its wtp-profile. FortiManager prunes a wtp-profile that no wtp entry references on install (see create_device_wtp), so deleting the last AP on a profile loses that profile on the next install_device_settings.

Args: device: Managed device name wtp_id: FortiAP serial number (the wtp-id / table mkey) vdom: VDOM the AP is registered in (default "root")

Returns: Deletion result

Input Schema

NameRequiredDescriptionDefault
vdomNoroot
deviceYes
wtp_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.12.0

TDQS

A4.4/5.0
Behavior4/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 well: it discloses the direct effect (reference dropped) and the non-obvious downstream consequence (wtp-profile pruning on the next install_device_settings), which is exactly the kind of cross-object side effect an agent needs. It omits permission requirements, idempotency, and behavior when the ID is not found.

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 purpose sentence comes first, followed by the important caveat, then a compact Args/Returns block. Slightly padded by the line-wrapped prose, but every sentence contributes information an agent needs.

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?

An output schema exists so return format needn't be explained, and params plus side effects are covered. What remains missing is whether a commit/install step is required to apply the deletion and how to recover from an unknown wtp_id — minor but relevant for a destructive operation.

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% (fields are bare titles like 'Wtp Id'), so the description must compensate, and it does: device is the managed device name, wtp_id is the FortiAP serial number / wtp-id table mkey, vdom is the registering VDOM with default 'root'. The clarification that wtp_id is a serial rather than a numeric ID is materially useful.

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?

States a specific verb (delete) and a precisely scoped resource (a managed FortiAP registration from a device's device DB), which cleanly separates it from list_device_wtps, get_device_wtp, create_device_wtp and update_device_wtp in the sibling set. No ambiguity about what is being removed.

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?

Gives clear operational context: the AP's wtp-profile reference is dropped and the profile can be pruned on the next install, and it cross-references create_device_wtp and install_device_settings. It does not tell the agent how to discover a wtp_id first (get_device_wtp / list_device_wtps) or what to do if the AP is absent, so no explicit alternatives guidance.

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