Prefixing the mutating tools' descriptions with a warning is a small thing that changes model behaviour — it makes cancelling a run a deliberate act rather than a plausible next step. The pairing that earns its keep is a failed run and its logs in two calls, then a replay in a third, without switching to the dashboard to do it.
A wrapper over the Hatchet API. Seven tools read state — definitions, runs, logs, workers, queue health — and three change it, each labelled as mutating so nobody calls one by accident.
- list_workflows and list_runs, the latter with a lookback window and filters
- get_run — one run in full: status, its tasks, and the errors
- get_run_logs for a task's log lines by its external id
- list_workers and get_queue_metrics for whether anything is actually picking work up
- whoami, which confirms the token works and shows which tenant and server it resolved to
- trigger_workflow to start a run by name with a JSON payload
- cancel_runs and replay_runs across one or more ids at a time
HATCHET_CLIENT_TOKEN, a JWT from the dashboard that encodes both the server URL and the tenant — normally the only setting needed. HATCHET_API_BASE points it at a self-hosted instance, and HATCHET_TENANT_ID overrides what the token decoded. Runs from npx. The token grants full tenant access, so treat it accordingly.
One command plus a key — npx -y hatchet-mcp, then supply credentials