Umami MCP

Umami MCP Server

A Model Context Protocol server for Umami Analytics. Ask Claude, Cursor or any MCP client about your traffic — and let it create and manage websites — while your credentials stay on your own machine.

"Which pages drove the most visitors last month, and where did that traffic come from?"

"Build a funnel from /pricing to /signup to /welcome for the last 30 days." "Add analytics for my new site blog.example.com and give me the tracking snippet."

A throwaway site with generated traffic, on a live Umami 3.3.1 instance, read by a view-only service account — so the counts are small and mean nothing, but every one of them was really collected and really queried. Regenerate with vhs demo/demo.tape.

Why this exists

Umami now ships an official MCP server (since v3.4.0, MCP_ENABLED=1, endpoint /mcp). If read-only analytics is all you need, use that: it runs inside Umami, so there is nothing extra to deploy. See the Umami docs.

This server is for what the official one deliberately leaves out:

Several community servers exist too, and if you just want broad API coverage you should look at 0xtlt/umami-mcp first — it wraps more of the API than this does. Some of the older servers (jakeyShakey, mikusnuz, mittwald, Macawls) were written against the v2 API and break on a modern instance, because v3 renamed things without aliases:

This server exists for two things the others do not do:

1. Complete, verified v3 report coverage. All seven v3 report types — funnel, retention, journey, goal, revenue, attribution and UTM — were exercised against a live Umami 3.3.1 instance. The report envelope is easy to get wrong: dates go in parameters as ISO-8601 strings, not in filters, and not as the epoch milliseconds the rest of the API uses. Attribution takes first-click / last-click, not the camelCase spellings you would guess.

2. A capability model rather than a boolean. See below.

Security model

An analytics MCP server holds a credential that can read every visitor session you have ever recorded — and, if you let it, delete the lot. The design follows from that.

Your credentials never leave your environment. Configuration is read only from the process environment. There is no telemetry, no phone-home, and no hosted relay. The only host this server ever contacts is the UMAMI_URL you set. If you self-host it, nothing about your analytics ever reaches a third party — including the author of this software.

Be wary of any Umami MCP that offers a hosted endpoint you point at your instance. Before

Umami 3.4 a self-hosted instance had no API keys, so "convenient" hosting meant mailing your

admin password to someone else's server. On 3.4+, give such a service a revocable API key

from a dedicated account, never a password.

Least privilege by default. The server starts in read mode. Widening is a deliberate act:

Withheld tools are not registered at all, so they never appear in the model's tool list. This is the part that differs from a READONLY=true flag: a tool that was never advertised cannot be invoked by a prompt-injected instruction hidden in, say, a referrer string or a page title inside your own analytics data. There is no runtime check to forget or bypass, because there is no tool.

Destructive actions need a typed confirmation checked against reality. umami_delete_website takes a confirmDomain argument, fetches the live record, and refuses unless they match. A model that reaches for the wrong website UUID gets an error, not a wiped dataset.

Credentials stay out of client config. Rather than requiring your password inside ~/.claude.json or mcp.json, the server reads it from a file you control at ~/.config/umami-mcp/env, and warns if that file is readable by other users. See Credentials.

Secrets are scrubbed from output. MCP output flows into a model and often into a chat transcript, which cannot be un-said. Passwords, bearer tokens and JWTs are redacted from every error and response before they leave the process.

Refuses to leak credentials over the wire. Plaintext HTTP to a remote host is rejected at startup; it is permitted only for localhost, for local development.

Install

Three ways to run it. Self-hosting is the default and the recommended one — the hosted instance exists so you can try it in two minutes without cloning anything.

If you self-host and want it in Claude web, run it with UMAMI_MCP_OAUTH=true behind your own domain — then nothing of yours touches anyone else's infrastructure.

1. Use the hosted instance (nothing to install)

Add a custom connector in Claude pointing at:

https://umami-mcp.asif.dev/mcp

You will be asked for your own Umami URL and login on a consent screen. See Claude web, Cowork, and Claude Code on web for how the credentials are handled.

2. From source

git clone https://github.com/Asif2BD/umami-mcp.git

cd umami-mcp npm install && npm run build

Then set up credentials and register it with your client:

claude mcp add umami --scope user -- node "$PWD/dist/index.js"

Requires Node 20 or newer.

3. Docker

git clone https://github.com/Asif2BD/umami-mcp.git

cd umami-mcp cp .env.example .env # then edit .env docker compose up -d

npm: not published yet. Once it is, npx -y @asif2bd/umami-mcp will replace the

clone-and-build step above. Until then use source or Docker.

Credentials

On Umami 3.4.0 or later, prefer an API key (Settings → API keys) in UMAMI_API_KEY: it can be revoked on its own without changing a password. It is sent as Authorization: Bearer to a self-hosted instance and as x-umami-api-key to Umami Cloud. Older instances have no API keys, so the credential is a real account password. Either way, MCP clients normally want that embedded in their config JSON — ~/.claude.json, mcp.json and friends — which are widely readable, get pasted into issues and screen-shares, and are synced between machines by some clients.

So this server reads credentials from a file you control instead. Create it once:

mkdir -p ~/.config/umami-mcp

cat > ~/.config/umami-mcp/env <<'EOF' UMAMI_URL=https://analytics.example.com UMAMI_USERNAME=mcp-bot UMAMI_PASSWORD=your-password UMAMI_MCP_MODE=read EOF chmod 600 ~/.config/umami-mcp/env

The server loads it automatically. It warns on startup if the file is readable by other users.

Lookup order — the first file found wins, and real environment variables always override the file, so you can still pass settings from the client config when you want to:

1. $UMAMI_MCP_ENV_FILE, if set
2. ~/.config/umami-mcp/env (or $XDG_CONFIG_HOME/umami-mcp/env)
3. ./.env in the working directory

Connect your client

Claude Code

With the credentials file above, the registration carries no secrets at all:

claude mcp add umami --scope user -- node ~/umami-mcp/dist/index.js

Use the absolute path to your checkout. If your Node lives under nvm, give the full interpreter path too, since MCP clients do not load your shell profile:

claude mcp add umami --scope user -- ~/.nvm/versions/node/v22.22.0/bin/node ~/umami-mcp/dist/index.js

Claude Desktop / Cursor / VS Code

{

"mcpServers": { "umami": { "command": "node", "args": ["/absolute/path/to/umami-mcp/dist/index.js"] } } }

If you would rather keep everything in one place, environment variables still work and take precedence over the file:

{

"mcpServers": { "umami": { "command": "node", "args": ["/absolute/path/to/umami-mcp/dist/index.js"], "env": { "UMAMI_URL": "https://analytics.example.com", "UMAMI_USERNAME": "mcp-bot", "UMAMI_PASSWORD": "your-password" } } } }

Check it works

Ask your client to run umami_whoami. It reports the instance, the account, and the permission mode — the fastest way to confirm the connection and see how much the server is allowed to do:

{

"instance": "https://analytics.example.com", "authenticatedAs": "mcp-bot", "role": "admin", "serverMode": "read", "destructiveOperations": "disabled" }

Then try: *"List my Umami websites"*, or *"What were my top pages last week?"*

Claude web, Cowork, and Claude Code on web

Those clients cannot launch a local process, so they need a public HTTPS MCP server — and their connector UI accepts OAuth only, with no field for a static bearer token or custom header.

Hosting the obvious way, with one set of Umami credentials baked in and no authentication, turns the URL into an open proxy to that Umami. So this server does OAuth instead, and does it without becoming a credential store.

Use the hosted instance

Add a custom connector in Claude with this URL:

https://umami-mcp.asif.dev/mcp

Claude registers itself, sends you to a consent screen, and asks for your own Umami URL, username and password. Nothing is shared with other users of the host.

Host your own

UMAMI_MCP_OAUTH=true

UMAMI_MCP_TRANSPORT=http UMAMI_MCP_ISSUER=https://mcp.example.com # public HTTPS URL of this server UMAMI_MCP_TOKEN_KEY=<32 random bytes> # keep stable; see below UMAMI_MCP_TOKEN_TTL=2592000