Summary

Two tools, and they are the two you want.

Triage is a search followed by a drill-down, and that is the whole surface here: find the faults matching a term or a time window, then read the notices behind the one that matters. Sorting by frequency rather than recency is what turns "something is broken" into "this is broken most often", and the 25-result ceiling keeps a busy project from swamping the conversation.

What it is

A read-side bridge to Honeybadger error monitoring. It lists and filters the faults in a project and pulls the notices behind any one of them, so an assistant can work from real error data instead of a pasted stack trace.

What you get

`list_faults` searches by text and filters on creation or occurrence timestamps
Ordering by `recent` or `frequent`, so "what is happening now" and "what happens most" are different questions
`get_fault_details` returns the notices for one fault, newest first
Time windows on both — `created_after`, `created_before`, `occurred_after` — as Unix timestamps
Pagination with a `limit` of at most 25 per call, which keeps a noisy project from flooding the context

Requirements

Python 3.10+ or the Docker image. A Honeybadger API key and project ID, given either as `HONEYBADGER_API_KEY` and `HONEYBADGER_PROJECT_ID` or as `--api-key` and `--project-id`. Transport defaults to SSE on 127.0.0.1 port 8050; pass `--transport stdio` to let the client launch it instead. Read-only against Honeybadger — nothing here resolves or deletes a fault. Version 0.2.1.

Setup effort

One command plus a key — docker run --rm -i honeybadger/mcp --transport stdio --api-key YOUR-API-KEY --project-id YOUR-PROJECT-ID, then supply credentials