Skip to main content
Glama
Sign In
FortiManager MCP Server

FortiManager MCP Server

by rstierli
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_device_bgp_status

Retrieves a device's live BGP state through the FortiManager proxy, showing peer establishment, learned paths, and BGP routes in the routing table to verify whether neighbors are up and what they advertised.

Instructions

Read a device's LIVE BGP state through the FortiManager proxy.

Unlike get_device_bgp (which reads the device-DB BGP config), this proxies the device's monitor API to answer "are the peers established and which routes did they bring":

  • peer state (router/bgp/neighbors)

  • local and learned paths (router/bgp/paths)

  • BGP routes in the routing table (router/ipv4)

Dynamic peers from a neighbor-range are not configured neighbors: a hub lists none until a spoke connects, so an empty list there means no spoke is up, not that BGP is unconfigured. Check the spoke's state too.

Args: adom: ADOM name (defaults to DEFAULT_ADOM / "root" when omitted) device: Managed device name (e.g. "FGT-HQ"). Defaults to DEFAULT_DEVICE when omitted; required if that is not configured.

Returns: dict with keys: - adom, device - summary: neighbors with state, established_count, learned paths, BGP routes in the routing table - unverified: sources that could not be read - error / error_code: on failure

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_device_bgp_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
adomNo
deviceNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.13.1

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it discloses read-only behavior, the three underlying monitor endpoints, the return structure including a partial-failure field ('unverified: sources that could not be read'), and error/error_code on failure. It does not mention permissions or device-reachability preconditions, which leaves a modest gap.

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 core distinction, then a bulleted enumeration of sources and a short Args/Returns block. Well organized, though the neighbor-range paragraph is somewhat lengthy for the point it makes.

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-optional-parameter read tool, the definition covers purpose, alternatives, data sources, return keys, and failure handling, and an output schema exists so return values need not be exhaustively restated (the Returns block is a helpful redundant summary). Missing only auth/permission and reachability context, which are the last pieces an agent might need.

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%, so the description must compensate, and it does: both optional params get documented fallbacks (adom defaults to DEFAULT_ADOM/'root'; device defaults to DEFAULT_DEVICE and becomes required if unset). It omits any format guidance for device names beyond the example, so it falls short of fully compensating.

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 ('Read a device's LIVE BGP state through the FortiManager proxy') and explicitly contrasts with the sibling get_device_bgp, which reads device-DB config rather than live state. The enumerated data sources (neighbors, paths, ipv4 routes) pin down scope precisely.

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?

Gives the exact question this tool answers ('are the peers established and which routes did they bring') and names the alternative for config reads. It also adds a genuine usage caveat: dynamic peers from a neighbor-range show empty until a spoke connects, so an empty list does not mean unconfigured BGP — and it tells the agent to check the spoke's state too.

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