
Umami Mcp
io.github.Asif2BD由 GitHub 帳號 Asif2BD 發布v0.1.3更新於 Oct 24, 2026
Query Umami Analytics v3 — stats, funnels, retention, attribution, UTM. Read-only by default.
概覽
針對 Umami Analytics v3 的 MCP 伺服器,讓助理查詢流量統計、漏斗、留存、路徑、歸因與 UTM 報告,並可選擇性地管理網站。
- 可以做什麼
- 列出並檢視已追蹤的網站,取得可直接貼上的追蹤程式碼片段。讀取整體統計、依時間分組的瀏覽量、依維度排名的熱門值、目前活躍訪客與即時動態。檢視自訂事件彙總、個別訪客工作階段及其依序的造訪路徑。執行 v3 報告:UTM 細分、漏斗、留存、路徑、目標、收益,以及首次點擊或末次點擊歸因。在更高權限模式下建立與更新網站和團隊、管理使用者,並需額外開關才能刪除或重設資料。用 whoami 工具檢查連線狀態與目前權限模式。
- 適用情境
- 當你希望助理回答 Umami 流量問題、建立轉換漏斗或留存 cohort,或在不開啟 Umami 後台的情況下管理被追蹤網站時使用。它針對 Umami v3 執行個體,自架或 Cloud 皆可。
- 執行需求
- 本機 Node.js 20 或更新版本的行程,或 Docker。透過 UMAMI_URL 提供可連線的 Umami v3 執行個體網址。自架需在 UMAMI_USERNAME 與 UMAMI_PASSWORD 提供登入資訊,Cloud 則使用 UMAMI_API_KEY。憑證也可放在使用者設定目錄下的檔案中,而不寫入用戶端設定。僅需連線至該執行個體的網路存取。
安裝
在 SourceWeft 中
- 開啟 儀表板中的 Umami Mcp,將其新增到工作區。
- 為需要使用其工具的對話啟用該服務。
Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。
其他 MCP 客戶端
參照 儲存庫 中的啟動說明。
README
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.
[npm] [npm downloads] [CI] [MCP Registry] [License: MIT] [Node] [Umami]
[umami-mcp answering questions about live traffic]
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:
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
Then set up credentials and register it with your client:
Requires Node 20 or newer.
3. Docker
npm: not published yet. Once it is,
npx -y @asif2bd/umami-mcpwill 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:
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:
$UMAMI_MCP_ENV_FILE, if set~/.config/umami-mcp/env(or$XDG_CONFIG_HOME/umami-mcp/env)./.envin the working directory
Connect your client
Claude Code
With the credentials file above, the registration carries no secrets at all:
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 Desktop / Cursor / VS Code
If you would rather keep everything in one place, environment variables still work and take precedence over the file:
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:
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:
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
Generate the key once and keep it:
Set UMAMI_URL as well to pin every user to one instance instead of letting them choose.
How the credentials are handled
The consent screen verifies the credentials against the Umami instance the user named, then seals them into the access token with AES-256-GCM. The server keeps no session table and stores no credentials: each request decrypts the token, builds an MCP server scoped to that one user, serves the call, and discards it.
The honest trade-off: whoever holds UMAMI_MCP_TOKEN_KEY can decrypt any token they capture.
Treat it as the most sensitive value in the deployment. Rotating it invalidates every issued
token, which is the intended blast-radius control.
Destructive tools are never exposed over OAuth, whatever permission the user picks. Their typed-confirmation guard assumes a local operator who can see what they are about to delete, and a remote caller cannot be shown that.
Running it as a plain HTTP service
Set UMAMI_MCP_TRANSPORT=http without UMAMI_MCP_OAUTH for a single-tenant endpoint at /mcp,
plus /health.
In this mode the server has no authentication of its own. Anyone who can reach the port can use your Umami credentials. Keep it on loopback and tunnel to it:
The server warns at startup when it is bound to anything other than loopback.
Tools
Time ranges
Every analytics tool accepts a period shorthand — 24h, 7d, 30d, 12m, today,
yesterday — instead of epoch milliseconds. Models are reliably good at "last 30 days" and
unreliably good at timestamp arithmetic, and a miscalculated epoch returns data for the wrong
window without erroring. Explicit startAt/endAt in epoch milliseconds still work and take
precedence.
Configuration
See .env.example for every option. The essentials:
Recommended setup
Create a dedicated Umami account for the MCP server rather than reusing your admin login, and give it only the websites it needs. Then, if the credential is ever exposed, the blast radius is one bot account you can delete — not your administrator.
Compatibility
Verified against Umami 3.3.1 and runs in production against 3.4.1 (self-hosted, PostgreSQL).
Umami Cloud works via UMAMI_API_KEY; self-hosted 3.4.0+ accepts it too.
Umami v2 is not supported: the renamed metric types above mean v2 and v3 need different clients,
and this one targets v3.
Development
test/e2e.mjs and test/write-e2e.mjs drive the built server through a real MCP client against
a live instance. The write test creates a throwaway website on a .invalid domain and deletes it
again; point it at a non-production instance.
Contributing
Issues and pull requests welcome. Umami v3 exposes around 127 API routes and this server covers
the most useful ones — session replay, heatmaps, pixels, link tracking, boards and segments are
all still unmapped. If you add tools, keep the tier and destructive flags honest, because the
whole safety model rests on them.
If the Umami team would like to adopt, fork or upstream this, please open an issue — that is the outcome this was built for.
License
MIT © M Asif Rahman
來源:README.md,提交 e618d22
工具
0版本歷史
1- v0.1.3最新Sep 16, 2026
評分
已滿足適用檢查項的 50%
該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。
- 近 30 天內可連通25 分
請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。
- 已宣告認證方式10 分
請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。
- 已列出工具15 分
請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。
- 描述必需15 分
- 圖示10 分
- 文件15 分
- 授權條款10 分