mcp-syslog-crunchtools

# mcp-syslog-crunchtools MCP server for the logs collected by [`crunchtools/syslog`](https://github.com/crunchtools/syslog). Built for RT #1460, to close a specific gap: Hermes gets paged by Nagios and can restart a service, but it cannot read the service's logs — so every remediation is a blind restart. This turns that into an informed one. ## Capabilities | Tool | What it answers | |---|---| | `syslog_sources_tool` | What can I query? | | `syslog_search_tool` | Show me ERRs from this service in the last 15 minutes | | `syslog_grep_tool` | Where does this string appear across the whole fleet? | | `syslog_tail_tool` | What are this service's most recent lines? | | `syslog_context_tool` | What was *everything* saying around 03:14? | | `syslog_stats_tool` | Which service is loudest, and which is actually unhealthy? | ## The triage loop ``` nagios_current_problems_tool → what is broken syslog_search_tool(source=…, → why it broke severity="ERR", since="15m") syslog_context_tool(timestamp=…) → what else was happening at that moment nagios_schedule_check_tool → confirm the fix ``` `syslog_context_tool` without a `source` is the one that earns its keep. It spans every source at once, which is how "the app died" gets connected to "the database container OOMed four seconds earlier". ## Design notes **Every result is bounded, and says when it is.** Logs are unbounded and this output lands in a model's context window. Each tool caps its results, caps how many lines it will scan, and annotates the answer when either limit is hit: ``` [!] Stopped after the 2,000,000-line scan limit, so this result is INCOMPLETE and an empty or short result does not mean nothing happened. ``` That annotation is load-bearing. A caller that cannot distinguish "no errors occurred" from "I stopped looking" will draw the wrong conclusion from an empty result — and this server exists to inform remediation decisions.…