Skip to main content
Glama
Sign In
FortiManager MCP Server

FortiManager MCP Server

by rstierli
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

update_bgp_template

Modify neighbor-group settings in a BGP provisioning template, including route-reflector-client, next-hop-self, and soft-reconfiguration, to prepare FortiManager changes for device install.

Instructions

Change neighbor-group options inside a BGP provisioning template.

Only FortiManager changes here: the devices follow at the next install, so run preview_install(package=None) first. BGP then needs a route refresh, for example execute router clear bgp all soft out, before peers receive what a new route-reflector client should get.

The neighbor-group path is not in the bundled FNDN specs; it is verified live on FortiManager 8.0.2 only.

Args: adom: ADOM name name: BGP template name (list_templates entries whose template setting.stype is router_bgp) neighbor_group: Neighbor group name, e.g. "EDGE" settings: Options to change: route-reflector-client, next-hop-self, next-hop-self-rr, soft-reconfiguration ("enable"/"disable") and advertisement-interval (seconds). Anything else is refused.

Returns: dict: adom, name, neighbor_group, before, after (values read back from FortiManager, 1/0 for enable/disable), or 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>",
      "neighbor_group": "<neighbor_group>",
      "settings": "<settings>"
    },
    "name": "update_bgp_template"
  }
}

Input Schema

NameRequiredDescriptionDefault
adomYes
nameYes
settingsYes
neighbor_groupYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.13.1

TDQS

A4.3/5.0
Behavior3/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 a lot: it discloses that only FortiManager state changes, that devices update only at install, that a route refresh is needed, and that unsupported settings are refused. However, it omits mutation-safety information an agent would want for a write tool, such as permissions required, whether prior values can be restored, and whether the edit conflicts with pending installs; the before/after return does mitigate this partly.

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?

It is front-loaded correctly: scope first, then operational caveats, then arguments and returns. The FNDN-spec caveat and the sample CLI command are slightly niche, but both are actionable for an agent; nothing is padding, though the prose could be tightened.

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 four-parameter mutation tool with no annotations, the definition covers the operational sequence, the value domain, the version-support caveat, and the failure shape. The return section is useful even though an output schema exists, and the main residual gap is permission/rollback behavior rather than anything structural.

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 coverage is 0% (bare titles only), so the description must compensate, and it largely does: all four parameters are explained, including the exact allowed keys for 'settings' (route-reflector-client, next-hop-self, next-hop-self-rr, soft-reconfiguration, advertisement-interval) with value types and units. The 'adom' and 'name' entries are minimally defined, and the neighbor_group format is given only via an example.

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?

The opening sentence gives a specific verb (change) and a precisely scoped resource (neighbor-group options inside a BGP provisioning template), not a tautology. It makes clear this is a template-level edit rather than a device-level BGP change, which separates it from the get_device_bgp* siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states an explicit prerequisite ordering (run preview_install(package=None) first, since devices only follow at the next install) and a required follow-up action (route refresh via 'execute router clear bgp all soft out'). It also points to list_templates and describes how to identify the right template entry, so the agent knows how to gather inputs.

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