Skip to main content
Glama
Sign In
FortiManager MCP Server

FortiManager MCP Server

by rstierli
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_sdwan_template_config

Reads the SD-WAN configuration a wanprof template pushes: members, zones, health-checks with SLA thresholds, and service steering rules. Use it to inspect template settings beyond basic metadata.

Instructions

Get the SD-WAN configuration inside a wanprof (SD-WAN) template.

get_sdwan_template returns only the template's metadata (name, type, scope). This reads the configuration the template pushes -- members, zones, health-checks with their SLA thresholds, and service (steering) rules -- from the template's own config subtree.

Args: adom: ADOM name name: SD-WAN template name (as listed by list_sdwan_templates)

Returns: dict with keys: - adom, name - sdwan: raw system/sdwan config object (health-check password stripped -- see _SDWAN_SECRET_FIELDS) - summary: condensed members/zones/health-checks/service rules - error / error_code: on failure

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

Input Schema

NameRequiredDescriptionDefault
adomYes
nameYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.13.1

TDQS

A4.3/5.0
Behavior4/5

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

No annotations exist, so the description carries the full burden, and it does disclose a non-obvious behavior: the health-check 'password' is stripped from the raw sdwan object, plus the error/error_code keys on failure. Read-only semantics are implied by 'Get'/'reads' but not stated outright, and there is no mention of permissions or what happens when the template has no config subtree, so it falls short of exhaustive.

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 the sibling contrast before the Args/Returns blocks, which are cleanly delimited. A few clauses are mildly redundant (the Returns section partially restates the intro), but nothing is padding and the structure is easy to scan.

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 two-parameter read tool this covers purpose, sibling differentiation, both parameters, secret redaction, and the failure shape; the presence of an output schema means the return-value detail is bonus rather than required. The only real gap is behavior when the template name is invalid or the template has no SD-WAN config, which an agent would have to discover at call time.

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%, so the description must compensate, and it documents both parameters: 'adom' as the ADOM name and 'name' as the SD-WAN template name with a pointer to 'list_sdwan_templates' as the canonical source of valid values. The 'adom' entry remains bare ('ADOM name') with no format or scoping detail, keeping it below a 5.

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?

States a specific verb and resource ('Get the SD-WAN configuration inside a wanprof template') and explicitly distinguishes the result from the sibling 'get_sdwan_template', which 'returns only the template's metadata'. The description even enumerates what the config contains (members, zones, health-checks, service rules), so an agent can pick this over the metadata sibling without inspecting either 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?

Gives a clear selection rule: use 'get_sdwan_template' for name/type/scope metadata, use this tool when the pushed configuration itself is needed. It also points at 'list_sdwan_templates' as the source of valid template names. It stops short of stating exclusions such as device-level config (e.g. 'get_device_sdwan'), which would have made it a 5.

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

Deploy Server

Other Tools