The five tools map onto the questions people actually ask an analytics tool: how did we do, what changed, which pages, and who is here now. Careful engineering shows in the boring places — one shared connection pool, bounded retries on transient 5xx, and `Retry-After` honoured up to 60 seconds.
A Python MCP server that exposes Umami analytics, covering both the current Umami Cloud API and self-hosted Umami 3.x. Every tool is read-only, and every `website_id`, segment and cohort identifier is validated as a UUID before any HTTP request goes out.
- get_websites — one page of websites; `page >= 1` and `1 <= page_size <= 100`
- get_stats — pageviews, visitors, visits, bounces, total time, and a comparison against the previous period or the year before
- get_pageviews — pageview and session time series, by minute, hour, day, month or year
- get_metrics — compact or expanded breakdowns; `1 <= limit <= 500` and `0 <= offset <= 10000`
- get_active — visitors on the site right now
- Metric types covering path, entry, exit, referrer, query, event, tag, the five UTM fields, browser, os, device, screen, language, country, city, region, channel and more
- Time ranges with sensible defaults: give neither end and you get the last seven days; give one and the other is inferred
Python 3.11+ and `uv`; run it with `uvx umami-mcp-server`. Pick exactly one authentication mode. Umami Cloud uses `UMAMI_API_KEY` against `https://api.umami.is/v1`, which is also the `UMAMI_API_BASE` default. Self-hosted Umami 3.x uses `UMAMI_USERNAME` and `UMAMI_PASSWORD`, with `UMAMI_API_BASE` set to your API root including `/api` — standard self-hosted Umami 3.x does not accept API keys. Umami 2.x and 1.x are not supported. Errors come back as controlled categories, and messages and logs exclude response bodies, credentials, headers and full query URLs.
One command plus a key — uvx umami-mcp-server, then supply credentials