Skip to main content
Glama
Sign In
FortiManager MCP Server

FortiManager MCP Server

by rstierli
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

list_metadata_variables

Fetch metadata variables for an ADOM and their device mappings; specify a device to see each variable's effective value and whether it comes from the device or ADOM default.

Instructions

List an ADOM's metadata variables and their per-device values.

Metadata variables are what templates reference as $(name); a model device import (add_model_device with meta_variables) stores its values as per-device mappings. Password-type values are redacted.

Args: adom: ADOM name device: Optional device name; when given, device_values holds the effective value of every variable for that device and where it comes from ("device" mapping or ADOM "default")

Returns: dict: status, count, variables (name, type, description, default, mappings[{device, vdom, value}]) and, with device, device_values

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": "list_metadata_variables"
  }
}

Input Schema

NameRequiredDescriptionDefault
adomYes
deviceNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.13.1

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full load and does well: it discloses that password-type values are redacted, that values come from per-device mappings or an ADOM default, and that ``device_values`` reports both the effective value and its provenance. It stops short of stating permissions or pagination behavior for an ADOM with many devices.

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 is front-loaded in the first line, then a short conceptual sentence, then Args/Returns. The docstring structure makes scanning easy. The Returns block partially duplicates the output schema, which is minor overhead rather than noise.

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?

For a two-parameter read tool with an output schema, this covers purpose, the meaning of each argument, the redaction caveat, and the shape of the response. Nothing essential to a correct invocation is missing; only cross-tool routing guidance is absent.

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: ``device`` is explained with its exact effect on the response (``device_values`` per variable, with source "device" or "default"). ``adom`` gets only "ADOM name", which is thin, but the parameter's role is unambiguous from context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb and resource ("List an ADOM's metadata variables") plus scope ("their per-device values"), and the follow-up explains what the resource *is* by tying it to the ``$(name)`` template syntax. It does not explicitly distinguish itself from the close sibling check_device_variables, which also deals with per-device values, so an agent may still hesitate between the two.

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

Usage Guidelines3/5

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

Usage context is implied through the ``device`` argument: pass it to get effective per-device values, omit it to get the ADOM-wide view. That is real guidance for a key decision, but there is no statement of when this tool is preferable to check_device_variables or when not to use it, and no prerequisites are mentioned.

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