Skip to main content
Glama
arttus

umami-mcp-server

by arttus
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Onboard a client: website, team, and access in one call

umami_onboard_client

Provision complete Umami tracking for a new client or project in one call: register the website, create an optional team, grant user access, and enable replay or heatmap. Avoids piecemeal setup.

Instructions

Set up everything Umami needs for a new client or project in a single call: register the website, optionally create a dedicated team for it, and optionally grant an existing internal user access to that team.

This is the fast path for "get this new site tracked and set up properly." For anything more custom, for example multiple websites under one team, use umami_create_website, umami_create_team, and umami_add_team_user individually.

Args:

  • website_name (string, required): Display name for the website.

  • domain (string, required): Domain being tracked, e.g. 'example.com'. No protocol.

  • team_name (string, optional): If given, creates a new team with this name and puts the website under it. Omit to create the website under your personal account instead.

  • grant_user_id (string, optional): An existing internal user (from umami_list_users) to add to the new team.

  • grant_role ('team-manager' | 'team-member' | 'team-view-only'): Role for grant_user_id on the new team (default: 'team-manager'). Ignored if grant_user_id or team_name is omitted.

  • replay_enabled (boolean, optional): Turn on session replay recording for the new website.

  • heatmap_enabled (boolean, optional): Turn on heatmap collection for the new website.

  • sample_rate (number, optional): Fraction of sessions to record for replay, 0 to 1. Only applied if replay_enabled or heatmap_enabled is set.

  • mask_level ('strict' | 'moderate', optional): PII masking strictness for replay recordings.

Returns: JSON shape: { "website": { "id": string, "name": string, "domain": string }, "team": { "id": string, "name": string, "access_code": string } | null, "granted_user": { "id": string, "username": string, "role": string } | null, "replay_config": { "replayEnabled": boolean, "heatmapEnabled": boolean, "sampleRate": number, "maskLevel": string } | null, "tracking_snippet": string }

Examples:

  • "Set up tracking for the new Walker's Land Services site, its own team, and add jordan to it" -> website_name="Walker's Land Services", domain="walkerslandservices.com", team_name="Walker's Land Services", grant_user_id="<jordan's user id>"

  • "Just get this client tracked, no team needed" -> website_name="...", domain="..."

  • "Set it up with replay on at 15% from day one" -> website_name="...", domain="...", replay_enabled=true, sample_rate=0.15

Error handling:

  • If website creation succeeds but team creation fails, the website still exists; the response reports the partial result rather than leaving it unclear.

  • If the website is created but the replay/heatmap follow-up update fails, the website and team (if any) still exist; use umami_update_website to finish that step manually.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainYesDomain being tracked, e.g. 'example.com'. No protocol or path.
team_nameNoCreate a new team with this name and put the website under it.
grant_roleNoRole for grant_user_id on the new team.team-manager
mask_levelNoPII masking strictness for replay recordings.
sample_rateNoFraction of sessions to record for replay, 0 to 1.
website_nameYesDisplay name for the website.
grant_user_idNoExisting internal user to add to the new team.
replay_enabledNoTurn on session replay recording for the new website.
heatmap_enabledNoTurn on heatmap collection for the new website.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the annotations by disclosing partial-failure behavior: 'If website creation succeeds but team creation fails, the website still exists; the response reports the partial result rather than leaving it unclear.' It also explains recovery steps after replay/heatmap update failure. This is meaningful behavioral context that the annotations alone do not provide, and it does not contradict readOnlyHint=false or idempotentHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured into Args, Returns, Examples, and Error handling, with the core purpose and routing statement front-loaded. Every section earns its place given the tool's complexity: nine parameters, conditional behavior, return shape, and failure semantics all need explanation. Nothing feels redundant or decorative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description provides a complete return JSON shape, which is essential for an agent interpreting results. It also covers examples, parameter dependencies, and several partial-failure scenarios. For a tool that creates multiple related resources and has follow-up recovery paths, this is more than sufficient for correct invocation and interpretation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema covers 100% of parameters, the description adds substantial meaning beyond the schema: 'Omit to create the website under your personal account instead,' 'Ignored if grant_user_id or team_name is omitted,' and 'Only applied if replay_enabled or heatmap_enabled is set.' It also tells the agent where to source grant_user_id ('from umami_list_users') and includes real-world examples mapping intent to parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action: 'Set up everything Umami needs for a new client or project in a single call: register the website, optionally create a dedicated team for it, and optionally grant an existing internal user access to that team.' This clearly identifies the resource, the verb, and the scope. It also distinguishes itself from sibling tools by explicitly positioning itself as the 'fast path' versus separate creation tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use this tool: 'This is the fast path for "get this new site tracked and set up properly."' It also gives a concrete when-not-to-use rule: 'For anything more custom, for example multiple websites under one team, use umami_create_website, umami_create_team, and umami_add_team_user individually.' This is clear routing guidance with named alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools