FortiManager MCP Server

Overview Schema Source Related Servers Discussions Admin

create_local_in_policy6

Creates a new IPv6 local-in policy to control traffic destined to the FortiGate itself, using interface, IPv6 source/destination addresses, services, and accept/deny action.

Instructions

Create a new IPv6 local-in policy.

IPv6 counterpart of create_local_in_policy -- see that tool's docstring for the local-in-policy concept. srcaddr/dstaddr reference IPv6 address objects here. There is no ha_mgmt_intf_only field on this object type (it is IPv4-only on the appliance).

Args: adom: ADOM name package: Policy package name intf: Incoming interface(s) this policy applies to, e.g. ["port1"] srcaddr: Source IPv6 addresses this policy matches dstaddr: Destination IPv6 addresses on the FortiGate itself (e.g. ["all"]) service: Services this policy matches, e.g. ["HTTPS", "SSH"] action: Policy action - "accept" or "deny" (default: "deny", the FortiOS field default) schedule: Schedule object name(s) (default: ["always"] if omitted) status: Policy status - "enable" or "disable" (default: "enable") logtraffic: Local-in traffic logging - "enable" or "disable" (optional) comments: Policy comments (optional) policyid: Specific policy ID (optional, auto-assigned if not set) srcaddr_negate: Match all sources EXCEPT srcaddr (optional) dstaddr_negate: Match all destinations EXCEPT dstaddr (optional) service_negate: Match all services EXCEPT service (optional) virtual_patch: Enable/disable virtual patching on this policy (optional)

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

Example: >>> result = await create_local_in_policy6( ... adom="root", ... package="default", ... intf=["port1"], ... srcaddr=["Admin-Subnet-v6"], ... dstaddr=["all"], ... service=["HTTPS", "SSH"], ... action="accept", ... )

Input Schema

Name	Required	Default
`adom`	Yes
`intf`	Yes
`action`	No	deny
`status`	No	enable
`dstaddr`	Yes
`package`	Yes
`service`	Yes
`srcaddr`	Yes
`comments`	No
`policyid`	No
`schedule`	No
`logtraffic`	No
`virtual_patch`	No
`dstaddr_negate`	No
`service_negate`	No
`srcaddr_negate`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.12.0Oct 25, 2026

TDQS

A4.2/5.0

Behavior3/5

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

No annotations, so the description carries the full burden. It usefully discloses field defaults (action="deny" as the FortiOS default, schedule defaults to ["always"], status="enable") and that policyid is auto-assigned, but says nothing about required permissions, ADOM locking, or whether a commit is needed for the policy to take effect.

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?

Front-loaded with the one-line purpose and sibling reference, then a well-formed Args block whose length is justified by 16 parameters. The Returns section and example are somewhat redundant padding given an output schema exists, but nothing is misleading or wasted enough to hurt.

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?

All 16 parameters are described and the IPv4/IPv6 delta is called out, which is more than most sibling tools offer. The return-value section duplicates the existing output schema, while the deployment lifecycle (lock, commit) is left unaddressed.

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% and no enums are defined, yet the description documents every one of the 16 parameters with types, accepted values ("accept"/"deny", "enable"/"disable") and examples such as ["port1"] and ["HTTPS", "SSH"]. The negate flags and the meaning of dstaddr (addresses on the FortiGate itself) are explained rather than just named.

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 new IPv6 local-in policy") and immediately positions it against the IPv4 sibling create_local_in_policy. The note that srcaddr/dstaddr reference IPv6 address objects removes the main ambiguity an agent could have between the two tools.

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?

Tells the agent this is the IPv6 counterpart and to consult create_local_in_policy for the underlying concept, and flags that ha_mgmt_intf_only does not exist here because it is IPv4-only on the appliance. It gives clear context but stops short of explicit when-not-to-use or prerequisites (e.g. whether an ADOM lock or commit_adom is needed).

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

Deploy Server