FortiManager MCP Server

Overview Schema Source Related Servers Discussions Admin

diagnose_ipsec_tunnel

Diagnose why an IPsec overlay tunnel is down by checking underlay interface status, IKE/phase2 state, SD-WAN health, and optional hub-side dial-up status.

Instructions

Diagnose why an IPsec overlay tunnel is down, underlay first.

Gathers, in one call, what an engineer checks before comparing IPsec proposals: the underlay interface the gateway is bound to (admin status in the device DB, live link and address), the tunnel's live IKE/phase2 state, its SD-WAN member state and health-check results and, with hub_device, the hub's matching dial-up gateway (matched on network-id) and whether the hub holds an instance from this spoke. Read-only: config comes from the FMG device DB, live state from the device's monitor API through the FMG proxy.

The verdict follows the first failing layer: underlay_admin_down, underlay_link_down, underlay_no_address, hub_underlay_link_down, tunnel_down (underlay fine, IKE not up), health_check_down, sla_not_met, healthy, or undetermined when live state could not be read.

Args: device: Device the tunnel lives on (e.g. "branch2") tunnel: Phase1-interface name (e.g. "HUB1-VPN2") adom: ADOM of the device (default: DEFAULT_ADOM or "root") vdom: VDOM of the tunnel (default "root") hub_device: Optional hub device to check the far side on

Returns: dict: device, tunnel, verdict, explanation, next_steps, evidence (gateway, underlay, tunnel, health_checks, hub) and unverified (sources that could not be read)

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": {
      "device": "<device>",
      "tunnel": "<tunnel>"
    },
    "name": "diagnose_ipsec_tunnel"
  }
}

Input Schema

Name	Required	Default
`adom`	No
`vdom`	No	root
`device`	Yes
`tunnel`	Yes
`hub_device`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.13.1Nov 10, 2026

TDQS

A4.6/5.0

Behavior5/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: it declares the tool read-only, discloses both data sources (FMG device DB for config, device monitor API via the FMG proxy for live state), enumerates every possible verdict including the degraded 'undetermined' case, and warns that some sources may be unreadable via the 'unverified' field. Nothing material about behavior is left to guesswork.

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 purpose and the 'underlay first' principle, then a compact evidence list, then the verdict ladder. The Args/Returns sections are dense but earn their place given 0% schema coverage; the Returns block overlaps with the existing output schema, which is the only real redundancy.

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 multi-source diagnostic tool with five parameters and a structured result, the definition covers the layers probed, the decision order, and the failure verdicts, which is what an agent needs to interpret results. Minor gaps remain: it does not state prerequisites (device must be reachable/adom permissions) or cost/latency of the multi-API fan-out, and the Returns block partly duplicates the output schema.

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 does: each of the five parameters is explained with meaning and example (device 'branch2', tunnel as phase1-interface name 'HUB1-VPN2', adom default 'DEFAULT_ADOM or root', vdom default 'root'), and hub_device's optional behavior is spelled out — it matches the hub's dial-up gateway on network-id and checks for an instance from this spoke. That 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.

Purpose5/5

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

Opens with a specific verb+resource+goal: 'Diagnose why an IPsec overlay tunnel is down, underlay first.' It names exactly what is gathered (underlay interface admin/live state, IKE/phase2 state, SD-WAN member state, health checks, optional hub-side gateway) and clearly separates it from the get_/list_/update_ phase1/phase2 siblings, which read or mutate config rather than render a diagnosis.

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 description establishes the triggering context ('what an engineer checks before comparing IPsec proposals') and the escalation path ('underlay first', verdict follows the first failing layer), which tells the agent when this tool is the right entry point. It stops short of naming an alternative tool or stating exclusions (e.g. when to prefer a plain phase1/phase2 get), so it is clear but not fully routable.

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

Deploy Server