Log APIs charge by what you pull, which makes a naive agent expensive fast — asking for a wide window with no filter is exactly what a model does unprompted. Capping the default window at six hours and the count at ten forces the useful order of operations: find out which apps are logging, filter to the one you care about, add a level filter, then raise the count. Widen the time range only when the default genuinely does not reach the incident.
A single-tool MCP server for retrieving logs from Mezmo. The design is built around quota: it defaults to a six-hour window and ten log lines, and the documented workflow is to discover which apps exist with a handful of lines before filtering and scaling up.
- `get_logs` returns log lines from Mezmo, defaulting to the last 6 hours with a count of 10
- `apps` narrows to specific applications, taking a comma-separated list — the single biggest reduction in results
- `levels` filters by severity, so a noisy app can be cut down to errors and warnings
- `query` searches within the matching lines for a phrase
- `from_ts` and `to_ts` set an explicit time range when the default window is not enough
- All log levels are returned unless you filter, so the noise reduction is yours to choose
A Mezmo Service API key, set as `MEZMO_API_KEY` in a local `.env`. The server runs in Docker through `docker-compose up -d`. Cursor connects over Streamable HTTP at `http://localhost:18080/mcp`; Claude Desktop can instead exec into the running container. Optional MCP-level authentication is available through `MCP_ENABLE_AUTH` and `MCP_API_TOKEN`. The Python package is `mezmo-mcp`, version 2.0.0.
One command plus a key — docker-compose up -d, then supply credentials