Skip to main content
Glama
arttus

umami-mcp-server

by arttus

Get an Umami user's details

umami_get_user
Read-onlyIdempotent

Retrieve a Umami user's profile, including role, websites, and teams. Specify the user ID; admins can look up others, users can look up themselves.

Instructions

Get a login account's details, plus the websites and teams it has access to.

Admin access required for other users; any authenticated user can look up themselves. Not available on Umami Cloud.

Args:

  • user_id (string, required): User UUID. Get this from umami_list_users.

  • response_format ('markdown' | 'json'): Output format (default: 'markdown').

Returns: JSON shape: { "id": string, "username": string, "role": string, "created_at": string, "websites": [ { "id": string, "name": string, "domain": string } ], "teams": [ { "id": string, "name": string } ] }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
user_idYesUser UUID.
response_formatNoOutput format: 'markdown' for a readable summary, 'json' for raw structured data.markdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already signal readOnly, idempotent, and non-destructive behavior, but the description adds meaningful context: access control requirements, platform restrictions, and the exact return shape. Since there is no output schema, including the JSON structure provides valuable transparency beyond the annotations.

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 well-organized with a one-sentence summary, prerequisite note, Args section, and Returns section. Every element earns its place; there is no filler or redundant restating of the title.

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?

For a simple read-only lookup with two parameters and no output schema, the description is complete: it covers what the tool returns, who can use it, where it is available, and how to obtain the required argument. An agent has everything needed to invoke it correctly.

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

Parameters4/5

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

The schema covers 100% of parameters, so the baseline is 3. The description adds useful guidance beyond the schema by telling the agent to source user_id from umami_list_users and by reiterating the response_format default. This extra context justifies a slightly higher score.

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 uses a specific verb ('Get') and clearly identifies the resource: a login account's details plus the websites and teams it can access. This distinguishes it from sibling tools like umami_list_users (list) or umami_get_team (team details), even without explicitly naming them.

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

Usage Guidelines4/5

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

It states prerequisites: admin access for other users, self-lookup for authenticated users, and unavailability on Umami Cloud. It also points to umami_list_users for obtaining the user_id. It does not explicitly contrast with alternative getters like umami_get_website or umami_get_team, so the guidance is clear but lacks direct exclusions.

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