FortiManager MCP Server

Overview Schema Source Related Servers Discussions Admin

find_duplicate_objects

Scans a FortiManager ADOM for objects of a given type that share identical content under different names, comparing specified fields to reveal duplicates.

Instructions

Find objects with identical content configured under different names.

Runs FortiManager's "find duplicates" option against every object of the given type in the ADOM. FortiManager compares the requested fields across all objects of that type and adds a "duplicate entries" list to each object that shares its content with at least one other object -- the field itself, not something computed client-side.

Args: adom: ADOM name object_type: One of "address", "address_group", "service", "service_group" (default: "address") fields: Object fields to compare for duplication (e.g. ["name", "type", "subnet"] for addresses). Omit to let FortiManager use its default field set for the type.

Returns: dict: Duplicate scan result with keys: - status: "success" or "error" - object_type: The object type scanned - objects: Full per-object list FortiManager returned (each entry has a "duplicate entries" list when it has a match) - duplicate_count: Number of objects that have at least one duplicate entry - message: Error message if failed

Example: >>> result = await find_duplicate_objects("root", object_type="address") >>> for obj in result["objects"]: ... if obj.get("duplicate entries"): ... print(obj["name"], "duplicates:", obj["duplicate entries"])

Input Schema

Name	Required	Default
`adom`	Yes
`fields`	No
`object_type`	No	address

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.12.0Oct 25, 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 burden and does well: it explains that the match is FortiManager's own 'duplicate entries' field rather than client-side computation, and that the scan runs across every object of the type. It stops short of stating that the call is read-only with no side effects, or any permission/auth prerequisites.

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 purpose followed by mechanism, Args, Returns and a short example — organized and easy to scan. It is longer than strictly necessary, and the Returns block largely duplicates the output schema, but no section is pure padding.

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?

An output schema exists, so the return-value prose is redundant, but everything an agent needs to invoke it correctly — parameters, defaults, comparison semantics — is present. Only adom identifier format and read-only confirmation are missing.

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 coverage is 0%, and the description fully compensates: 'adom' as ADOM name, 'object_type' with its four permitted values and the 'address' default, and 'fields' with a concrete example plus the semantics of omitting it (FortiManager default field set). This is meaning well beyond the bare schema.

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 line states a specific verb+resource ('Find objects with identical content configured under different names') and scopes it to all objects of a given type in the ADOM, so the operation is unambiguous. It never names a sibling (e.g., search_objects, find_object_usage) to differentiate itself, which keeps it just short of a 5.

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?

The description makes the use case implied and clear ('find duplicates' against an object type), but it offers no explicit when/when-not guidance and does not contrast itself with the many object-listing/search siblings in this server. An agent can infer the fit but gets no routing help.

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

Deploy Server