FortiManager MCP Server

Overview Schema Source Related Servers Discussions Admin

update_firewall_policy

Modify specific fields of an existing firewall policy, such as source/destination addresses, services, or action, while leaving other settings unchanged.

Instructions

Update an existing firewall policy.

Only the specified fields will be updated; other fields remain unchanged.

Args: adom: ADOM name package: Policy package name policyid: Policy ID to update name: New policy name (optional) srcintf: New source interfaces (optional) dstintf: New destination interfaces (optional) srcaddr: New source addresses (optional) dstaddr: New destination addresses (optional) service: New services (optional) action: New action - "accept" or "deny" (optional) schedule: New schedule (optional) nat: Enable/disable NAT (optional) logtraffic: New log mode (optional) status: New status (optional) comments: New comments (optional) global_label: Policy section label (optional) global_label_color: Policy section color ID 0-31 (optional) srcaddr_negate: Match all sources EXCEPT srcaddr (optional; None leaves the field untouched, like every other optional field) dstaddr_negate: Match all destinations EXCEPT dstaddr (optional) service_negate: Match all services EXCEPT service (optional) utm_status: Enable/disable security profile inspection (optional) av_profile: Antivirus profile name (optional) ips_sensor: IPS sensor name (optional) webfilter_profile: Web filter profile name (optional) dnsfilter_profile: DNS filter profile name (optional) application_list: Application control list name (optional) file_filter_profile: File filter profile name (optional) ssl_ssh_profile: SSL/SSH inspection profile name (optional) profile_protocol_options: Protocol options profile name (optional). Mutually exclusive with profile_group in the same call -- it is itself a member of the FortiOS firewall profile-group object profile_group: Security profile group name (optional). Mutually exclusive with av_profile, ips_sensor, webfilter_profile, dnsfilter_profile, application_list, file_filter_profile, ssl_ssh_profile, and profile_protocol_options in the same call

Note: Sending any individual security-profile field (av_profile, ssl_ssh_profile, profile_protocol_options, etc.) on a policy that is currently in group mode flips profile-type to "single" on the appliance. The previously-stored profile-group value becomes dormant (not deleted) rather than staying active alongside the new field -- FortiOS only honors one profile-type at a time.

Returns: dict: Update result with keys: - status: "success" or "error" - policyid: Updated policy ID - message: Status or error message

Example: >>> # Disable a policy >>> result = await update_firewall_policy( ... adom="root", ... package="default", ... policyid=10, ... status="disable" ... )

>>> # Update source addresses
>>> result = await update_firewall_policy(
...     adom="root",
...     package="default",
...     policyid=10,
...     srcaddr=["New-Subnet", "Other-Subnet"]
... )

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>",
      "package": "<package>",
      "policyid": "<policyid>"
    },
    "name": "update_firewall_policy"
  }
}

Input Schema

Name	Required	Description	Default
`nat`	No
`adom`	Yes
`name`	No
`action`	No
`status`	No
`dstaddr`	No
`dstintf`	No
`package`	Yes
`service`	No
`srcaddr`	No
`srcintf`	No
`comments`	No
`policyid`	Yes
`schedule`	No
`av_profile`	No
`ips_sensor`	No
`logtraffic`	No
`utm_status`	No
`global_label`	No
`profile_group`	No
`dstaddr_negate`	No
`service_negate`	No
`srcaddr_negate`	No
`ssl_ssh_profile`	No
`application_list`	No
`dnsfilter_profile`	No
`webfilter_profile`	No
`global_label_color`	No
`file_filter_profile`	No
`profile_protocol_options`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 schema fields changedv1.12.0Oct 25, 2026

addedInput schema / properties / application_list

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Application List"
+}

addedInput schema / properties / av_profile

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Av Profile"
+}

addedInput schema / properties / dnsfilter_profile

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Dnsfilter Profile"
+}

addedInput schema / properties / dstaddr_negate

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Dstaddr Negate"
+}

addedInput schema / properties / file_filter_profile

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "File Filter Profile"
+}

addedInput schema / properties / ips_sensor

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Ips Sensor"
+}

addedInput schema / properties / profile_group

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Profile Group"
+}

addedInput schema / properties / profile_protocol_options

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Profile Protocol Options"
+}

addedInput schema / properties / service_negate

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Service Negate"
+}

addedInput schema / properties / srcaddr_negate

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Srcaddr Negate"
+}

addedInput schema / properties / ssl_ssh_profile

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Ssl Ssh Profile"
+}

addedInput schema / properties / utm_status

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Utm Status"
+}

addedInput schema / properties / webfilter_profile

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Webfilter Profile"
+}

First observedMay 29, 2026

TDQS

A4/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 unusually well: it discloses a non-obvious side effect (sending an individual profile field flips `profile-type` to 'single' on the appliance and leaves the stored `profile-group` dormant, not deleted) and explains that None leaves every optional field untouched. Gaps remain on permissions/ADOM-lock requirements and whether the change only takes effect after install_package/commit_adom, which matter for a firewall mutation.

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?

The core behavior and the partial-update rule are front-loaded in the first two sentences, and the long Args block earns most of its length given 30 undocumented parameters. The 'Returns' block is pure duplication since an output schema already exists, and the examples add bulk beyond the necessary minimum.

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 30-parameter FortiOS mutation with zero annotation coverage, the description supplies partial-update semantics, mutual-exclusion rules, negate-flag behavior, a profile-type side effect, and examples. What is missing is environmental context: ADOM locking, whether a subsequent commit/install is required for changes to take effect, and error conditions — all relevant given the tool's blast radius. Return values need not be here since an output schema exists.

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% across 30 parameters, so the description is the only source of meaning, and it annotates essentially every parameter including value constraints ('accept' or 'deny', 'color ID 0-31') and the negate-flag semantics. Several entries stay terse ('New schedule (optional)', 'New services (optional)') without saying what identifiers are valid or where to look them up, so it is thorough but not complete.

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?

States a specific verb and resource ('Update an existing firewall policy') and immediately clarifies the partial-update semantics ('Only the specified fields will be updated'). An agent can distinguish it from create_firewall_policy or delete_firewall_policy by name alone, but the description never names or contrasts those siblings explicitly.

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?

The partial-update sentence plus two worked examples (disabling a policy, replacing srcaddr) give clear operational context for when this tool is the right call. It also encodes a real usage constraint ('profile_group ... mutually exclusive with av_profile, ips_sensor, ... in the same call'). It stops short of naming alternatives such as move_firewall_policy for reordering or revert_firewall_policy for rollback, and says nothing about the ADOM lock or package-install prerequisite.

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

Deploy Server