mcp-nagios-crunchtools
# mcp-nagios-crunchtools
Secure MCP server for Nagios Core monitoring. Query host and service status, acknowledge problems, add comments, schedule forced checks, and read notification history.
## Installation
```bash
uvx mcp-nagios-crunchtools
```
## Configuration
| Variable | Required | Description |
|----------|----------|-------------|
| `NAGIOS_URL` | Yes | Base URL (e.g., `https://nagios.example.com`) |
| `NAGIOS_USER` | Yes | HTTP Basic Auth username |
| `NAGIOS_PASS` | Yes | HTTP Basic Auth password |
| `NAGIOS_COMMENT_AUTHOR` | No | Author recorded on acknowledgements and comments. Defaults to `NAGIOS_USER`. Not a tool parameter. |
| `NAGIOS_CGI_PREFIX` | No | Path under `NAGIOS_URL` where the CGI scripts are served. Defaults to `/nagios/cgi-bin`. Set to `/cgi-bin` for a Nagios served at the web root. A trailing slash is ignored. |
| `TZ` | Effectively yes | The container's local timezone. Must match the Nagios server's own timezone. |
### Why `TZ` matters
`schedule_check` submits a `start_time` to `cmd.cgi`, which parses it as naive
wall-clock time in the Nagios server's local timezone — there is no offset field
to send. The value is therefore built with `time.localtime()`, so this container
must run in the same timezone as the Nagios server.
When it does not, forced checks are silently scheduled into the future by the
offset between the two — four hours against an EDT server — and "check now"
appears to do nothing at all. No error is raised. This was a real defect, fixed
in 0.1.2 by switching from `gmtime()` to `localtime()`; the timezone assumption
it introduced is why `TZ` belongs in this table rather than being left implicit.
## Tools
| Tool | Description |
|------|-------------|
| `nagios_host_status` | Query a single host's status |
| `nagios_service_status` | Query a single service's status |
| `nagios_current_problems` | All hosts/services not in OK state, with duration, attempt, acknowledgement and plugin output |
| `nagios_program_status` | Health check on the monitoring path itself (wedged daemon, disabled notifications, stale status) -- not the same as no current problems |
| `nagios_acknowledge` | Acknowledge a host or service problem |
| `nagios_add_comment` | Add a comment to a host or service |
| `nagios_schedule_check` | Force an immediate re-check |
| `nagios_notification_history` | Recent notifications |
| `nagios_alert_history` | State changes rolled up per host/service, including warnings and problems that recovered by themselves |
## License
AGPL-3.0-or-later
TDQS
Scored across 9 tools
Each tool targets a distinct Nagios concept or action: current problems vs. daemon health (explicitly contrasted), host status vs. service status, notification history vs. alert history (differentiated by scope). The descriptions actively call out the tricky overlaps, leaving little room for misselection.
Every tool follows the same nagios_<concept>_tool snake_case pattern with a uniform prefix and suffix. Action tools (acknowledge, add_comment, schedule_check) and query tools are all rendered in the identical convention.
Nine tools is well-scoped for a Nagios monitoring/inspection surface, with each tool earning its place covering distinct read and light-action operations. No redundancy or filler.
Core monitoring workflows are covered: problem listing, daemon health, host/service status, acknowledgement, comments, forced checks, and two history views. Minor gaps exist around scheduled downtime and enable/disable notifications, but agents can work around these.