LabscoMCP early access ↗
riefer02MCP SERVER

Mezmo

Pull Mezmo logs into a debugging conversation, with defaults chosen to protect your query quota.

by riefer02 ↗Observability, Monitoring & Incident ResponseCommunity

LABSCO SUMMARY

One tool, and the defaults are the design.

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.

What it is

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.

What you get

  • 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

Requirements

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.

Setup effort

Run a container — build the image from the repository, then point your client at it