Skip to main content
Glama
FortiManager MCP Server

FortiManager MCP Server

by rstierli

set_metadata_variable

Sets an existing metadata variable's value for a managed device, optionally for one VDOM scope, so templates apply it at the next install. Preview install if the value can affect network settings.

Instructions

Set a device's value for an existing metadata variable.

A device can hold one mapping per scope, for example "global" and "root", and templates can read either, so a value changed in one scope alone can leave the other behind. Without vdom every mapping the device has is changed; a device without any gets a "global" mapping.

Only FortiManager changes here. Templates use the new value at the next install: run preview_install(package=None) first, because a variable such as branch_id can move LAN addresses and BGP identities.

Args: adom: ADOM name name: Variable name (it must already exist) device: Managed device name value: New value: one line, at most 255 characters, no newlines or other control characters and none of ", \, #, {{, {%, {# or $( (templates paste it into CLI as is) vdom: Only this scope (optional, e.g. "global" or "root")

Returns: dict: status, variable, device, changes[{vdom, old, new}] (password variables redacted), or message on failure. A failure after some scopes were written also carries changes, for those scopes only

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": {
      "adom": "<adom>",
      "name": "<name>",
      "device": "<device>",
      "value": "<value>"
    },
    "name": "set_metadata_variable"
  }
}

Input Schema

NameRequiredDescriptionDefault
adomYes
nameYes
vdomNo
valueYes
deviceYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.13.1

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so well: it explains scope behavior, that omitting vdom changes every mapping, that a device without any mapping gets a global one, that only FortiManager changes immediately, and that templates use the new value at the next install. It also discloses partial-failure behavior and value constraints.

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 front-loaded with the core action, then structured into Args and Returns sections. The extra detail about scopes, value restrictions, and preview installation is necessary for correct invocation rather than wasted space.

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 mutation tool with no annotations and low schema description coverage, the definition is complete: it covers purpose, scope behavior, prerequisites, parameter constraints, return shape, and partial-failure behavior. An output schema exists, and the description still provides enough return context.

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%, so the description must define the five parameters. Its Args section explains each one, including that name must already exist, the detailed value constraints, and that vdom optionally limits the change to one scope.

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 opens with a specific verb and resource: "Set a device's value for an existing metadata variable." It distinguishes this operation from related templates and explicitly notes that only FortiManager changes immediately, while templates pick up the value at the next install.

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?

It gives a clear prerequisite to run preview_install(package=None) first because the change can affect LAN addresses and BGP identities. It also explains the vdom scope choice, but does not explicitly discuss when to use this tool versus alternatives such as listing variables to confirm existence.

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