Most vendor-adjacent servers pick twenty operations and call it done; this one maps the API. That makes it capable of the awkward jobs — extending a maintenance window mid-incident, reshuffling an on-call rotation, exporting an availability report — that a curated subset always seems to miss. The cost is context: a tool surface this size is a lot for a model to hold, so scoping the key and disabling what you do not need is part of setting it up well, not an afterthought.
An unofficial community MCP server for FortiMonitor and Panopta's v2 API. It is not a curated subset: 241 tools across 33 modules cover the monitoring platform close to end to end, from server CRUD and outage handling to on-call rotations, cloud discovery and CSV exports. It is not affiliated with or supported by Fortinet.
- Servers: list, detail, CRUD, attributes, tagging, logs, DNS flush and path monitoring — 21 tools
- Outages: query, health check, acknowledge, escalate, broadcast, delay and historical incidents — 22 tools, plus 6 bulk operations for acknowledging and tagging at scale
- Maintenance: status management and maintenance-window create, extend, pause, resume and terminate — 12 tools
- Notifications and contacts: schedules, contacts, contact groups and rotating on-call rotations — 14 and 18 tools
- Groups and templates: group CRUD, membership, policies, compound services and child groups, plus template apply and reapply — 12 and 8 tools
- Cloud monitoring: providers, credentials, discovery, regions and services — 15 tools; DEM applications, instances and locations — 10 tools
- Reporting: health summary, outage statistics, top alerting, availability reports and exports — 10 tools
- Also covered: compound services, dashboards, status pages, network services, monitoring nodes, SNMP, OnSight, fabric connections, countermeasures, users and reference data
- API schemas discovered and cached automatically for validation, exposed at `/schema/resources`
A FortiMonitor account and an API key: `FORTIMONITOR_API_KEY`, with `FORTIMONITOR_BASE_URL` pointing at the v2 API endpoint and `LOG_LEVEL` optional. Docker is the recommended path — run the published image with the key in the environment, or use the compose file. Locally: a virtualenv, `pip install -r requirements.txt`, a connectivity test script, then `python -m src.server`. Two configuration notes that will otherwise cost you an hour: Claude Desktop does not reliably set the working directory, so give the full path to the entrypoint and set `PYTHONPATH` explicitly; and set `ENABLE_SCHEMA_CACHE=false`, or point `SCHEMA_CACHE_DIR` at a writable absolute path, to avoid read-only filesystem errors from the default cache location.
Build from source — clone the repository and build it, then point your client at the binary