Skip to main content
Glama
Sign In
FortiManager MCP Server

FortiManager MCP Server

by rstierli
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

delete_firmware_template

Delete an unassigned firmware template from FortiManager. Refuses templates still assigned to a device or group and lists the assignments, so firmware targets change only through an explicit unassign step.

Instructions

Delete a firmware template that is not assigned to any device or group.

An assigned template is refused, with the assignment listed: unassign it in the GUI first, so a delete can never change what firmware a device is held to without that being a deliberate step.

Verified on FortiManager 8.0.2; the template table is not in the bundled API reference.

Args: name: Template name adom: ADOM name (default: from DEFAULT_ADOM env var, or "root")

Returns: dict: status, message (and assigned_to when refused)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "delete_firmware_template"
  }
}

Input Schema

NameRequiredDescriptionDefault
adomNo
nameYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.13.1

TDQS

A4.5/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 refusal behavior, that the assignment is listed in the response, and the deliberate-safety rationale. It omits permissions/auth needs and does not state outright that deletion is irreversible, which is notable for a destructive operation.

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?

Front-loaded with the action and its precondition, then rationale, then version caveat, then args/returns. Every sentence adds information an agent needs to call it correctly or interpret a refusal.

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?

For a two-parameter destructive tool, the definition covers scope, failure mode, remediation, return keys, and a version-compatibility caveat not in the bundled API reference. An output schema exists, so the Returns section is a bonus rather than a necessity.

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 description coverage is 0%, so the description must compensate, and it does: name is identified as the template name and adom as the ADOM name with a concrete resolution chain (DEFAULT_ADOM env var, then "root"). Only the name doc is somewhat thin, hence not a 5.

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 and resource (delete a firmware template) plus a hard scope constraint: only templates not assigned to any device or group. That constraint distinguishes it cleanly from sibling delete/assign tools without needing their schemas.

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?

Explicit about the precondition (template must be unassigned) and the remediation path when refused: unassign in the GUI first. It does not name alternative tools for assigned templates or point to list_firmware_templates for discovery, so a small gap remains.

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