FortiManager MCP Server

Overview Schema Source Related Servers Discussions Admin

create_firmware_template

Creates an unassigned firmware template with catalog-validated versions per platform; assign it later to schedule device upgrades or downgrades.

Instructions

Create a firmware template (not assigned to any device).

Each version is checked against the platform's firmware catalog, so the template can only enforce an image FortiManager can actually get. Assigning the template is a separate step, done in the GUI: once assigned, FortiManager upgrades (or downgrades) the devices to the enforced version in the schedule window.

Verified on FortiManager 8.0.2; the template table is not in the bundled API reference, so other versions may refuse it (reported as firmware_templates_unavailable).

Args: name: Template name versions: Enforced versions, one per platform: [{"platform": "FortiGate-VM64-KVM", "version": "7.4.9"}]. The version may include the build ("7.4.9-b2829") adom: ADOM name (default: from DEFAULT_ADOM env var, or "root") description: Optional description image_source: "fds" (FortiGuard, default) or "fmg" (images on FortiManager) schedule_type: "daily" (default) or "weekly" schedule_start_time: Window start, "HH:MM" (default "00:00") schedule_end_time: Window end, "HH:MM" (default "23:59") schedule_days: Days for a weekly schedule, e.g. ["saturday", "sunday"]

Returns: dict: status, template (as list_firmware_templates shows it), message

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>",
      "versions": "<versions>"
    },
    "name": "create_firmware_template"
  }
}

Input Schema

Name	Required	Default
`adom`	No
`name`	Yes
`versions`	Yes
`description`	No
`image_source`	No	fds
`schedule_days`	No
`schedule_type`	No	daily
`schedule_end_time`	No	23:59
`schedule_start_time`	No	00:00

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.13.1Nov 10, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations supplied, the description carries the full burden and does so: it discloses that versions are validated against the platform firmware catalog, that assignment triggers upgrade/downgrade inside a schedule window, and that unsupported FortiManager versions may reject the call with 'firmware_templates_unavailable'. That is exactly the pre-call risk information an agent needs for a mutating operation.

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?

Purpose and the two key constraints are front-loaded before the Args block, and the Args/Returns structure makes scanning easy. The prose paragraph on assignment behavior is slightly long, and the Returns section partly restates what the output schema already provides.

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 9-parameter mutation tool with no annotations, the definition covers purpose, validation behavior, scheduling semantics, version compatibility risk, and error signaling. Nothing an agent needs in order to call it correctly appears to be missing.

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%, yet the description documents all nine parameters with defaults, accepted value sets ('fds'/'fmg', 'daily'/'weekly'), and concrete formats such as 'HH:MM' times and the versions list shape with an optional build suffix. This is meaning the schema alone does not convey.

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?

Opens with a specific verb+resource ('Create a firmware template') and immediately scopes it with '(not assigned to any device)', which separates creation from assignment in a sibling set full of assign_* tools. An agent can identify the operation without opening the schema.

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?

Explicitly states that assigning the template is a separate step performed in the GUI, which tells the agent this tool alone will not push firmware to devices. It does not name specific alternatives (e.g. list_firmware_templates to verify results, delete_firmware_template to undo), so routing guidance is clear but not exhaustive.

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

Deploy Server