FortiManager MCP Server

Overview Schema Source Related Servers Discussions Admin

check_device_policy_sync

Compare a device's firewall policies with its assigned FortiManager policy package and report per-policy differences to identify policy drift and uninstalled changes.

Instructions

Compare a device's firewall policies with its assigned policy package.

Reports, policy by policy, what differs between the package FortiManager has assigned to the device and what the device has. Read-only.

Two views of "what the device has", chosen with source:

revision: the latest device DB revision -- the configuration last retrieved from or installed to the device, i.e. what it runs.
device_db: FortiManager's current device DB, which also holds changes staged in FortiManager but not installed yet.
both (default): both comparisons, plus device DB vs revision -- a difference there is staged in FortiManager and not installed.

Only policies the package installs on this device count: install-on targets (devices and nested device groups) are resolved, and policy blocks are expanded in place. Policies only on the device side can be global header/footer policies or edits made on the device.

Args: adom: ADOM name device: Managed device name vdom: VDOM (default "root") package: Package to compare with (default: the one assigned to the device/VDOM) source: "revision", "device_db" or "both" (default) revision: Device DB revision to use (default -1, the latest; see list_device_revisions). Ignored for source="device_db".

Returns: dict: status, in_sync (all comparisons run), package, install_status, revision (number, time, comment), interface_mapping (normalized interfaces this device names differently), comparisons: {"package_vs_revision", "package_vs_device_db", "device_db_vs_revision"} as requested -- each with in_sync, summary, only_in_ lists, modified (field -> value per side) and order_matches -- and not_targeted (package policies scoped to other devices).

Example: >>> result = await check_device_policy_sync("demo", "branch1") >>> for p in result["comparisons"]["package_vs_revision"]["modified"]: ... print(p["policyid"], p["differences"])

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>",
      "device": "<device>"
    },
    "name": "check_device_policy_sync"
  }
}

Input Schema

Name	Required	Default
`adom`	Yes
`vdom`	No	root
`device`	Yes
`source`	No	both
`package`	No
`revision`	No

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 declares the operation read-only, explains how install-on targets and nested device groups are resolved, that policy blocks are expanded in place, and how interface_mapping normalizes differently named interfaces. It also discloses why device-only policies may appear (global header/footer policies or on-device edits).

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?

It is front-loaded with a one-line purpose and the read-only marker, then organized into source views, Args, Returns, and an example, which makes it easy to scan. The Returns block largely restates the existing output schema, so a chunk of it is redundant padding rather than added meaning.

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 six-parameter read-only comparison tool with no annotations, the description covers intent, all parameter meanings, resolution rules, and what each comparison view represents. An output schema exists, so the extra Returns detail is surplus rather than a missing piece.

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 compensate, and it documents every one of the six parameters. `source` gets its three values spelled out, `revision` explains the -1 default plus the ignored-for-device_db case, `package` describes its default (the assigned package), and adom/device/vdom are identified.

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 opening sentence names a specific verb and resource: compare a device's firewall policies against its assigned policy package. The scope constraint that 'only policies the package installs on this device count' further separates it from package-level or policy-list tools, so 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?

It clearly explains the three `source` modes and when each is meaningful, including the default `both` and what a device_db_vs_revision difference implies (staged, not installed). It also notes that `revision` is ignored for source="device_db" and points to list_device_revisions for revision selection. It does not explicitly name an alternative comparison tool or state when not to use this one.

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

Deploy Server