Umami MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation3/5
The tools have some overlap in purpose, particularly 'get_metrics' and 'get_stats', which both seem to cover visitor statistics, and 'get_active' could be confused as part of metrics or stats. However, descriptions help differentiate 'get_pageviews' and 'get_websites' as more specific functions, reducing ambiguity.
Naming Consistency5/5
All tool names follow a consistent 'get_' verb_noun pattern, such as 'get_active', 'get_metrics', 'get_pageviews', 'get_stats', and 'get_websites'. This predictable naming convention makes the set easy to understand and navigate.
Tool Count4/5
With 5 tools, the count is reasonable for a web analytics server, covering core functions like active visitors, metrics, pageviews, stats, and websites. It's slightly thin but well-scoped, as each tool appears to serve a distinct aspect of the domain without being overwhelming.
Completeness3/5
The toolset covers key read operations for web analytics, such as retrieving active visitors, metrics, pageviews, stats, and websites. However, there are notable gaps in CRUD coverage, such as missing create, update, or delete operations for websites or other entities, which could limit agent workflows for managing analytics data.
Average 2/5 across 5 of 5 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but provides none. It doesn't indicate whether this is a read or write operation, what permissions might be required, whether there are rate limits, what the return format looks like, or any other behavioral characteristics. The phrase 'See browsers, countries, devices, and more' gives no insight into how the tool actually behaves when invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is technically concise (one short phrase), it's under-specified rather than appropriately concise. The single sentence 'See browsers, countries, devices, and more' fails to convey essential information about the tool's purpose or usage. This isn't effective conciseness - it's inadequate specification that leaves the agent guessing about fundamental aspects of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters including a nested filters object with 14 sub-properties), zero annotation coverage, and the fact that this appears to be a data retrieval/analytics tool, the description is completely inadequate. While an output schema exists, the description doesn't even establish basic context about what kind of metrics are being retrieved, for what purpose, or how this differs from sibling tools. This leaves the agent with insufficient information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the 8 parameters have descriptions in the schema. The tool description provides absolutely no information about any parameters - not even mentioning the required 'website_id' and 'type' parameters, let alone explaining what they mean or how they should be used. For a tool with 8 parameters including complex nested filters, this is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'See browsers, countries, devices, and more' is vague and tautological - it essentially restates the tool name 'get_metrics' without specifying what action is performed or what resource is accessed. It mentions some example metric categories but doesn't state whether this retrieves, analyzes, or aggregates metrics data. The description fails to distinguish this tool from its siblings like 'get_stats' or 'get_pageviews'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. There's no mention of what makes this tool different from 'get_stats', 'get_pageviews', or other sibling tools. No context about appropriate use cases, prerequisites, or limitations is provided. The agent would have no basis for choosing this tool over similar-sounding alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description 'Current active visitors' gives no insight into behavioral traits such as whether this is a read-only operation, what permissions might be required, how data is returned (e.g., format, pagination), or any rate limits. It fails to provide any meaningful context beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, making it front-loaded and free of unnecessary details. However, this brevity borders on under-specification, as it sacrifices clarity and completeness for conciseness. Every word earns its place, but more content is needed to be helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a data retrieval tool with one parameter) and the presence of an output schema (which might cover return values), the description is incomplete. It lacks purpose clarity, usage guidelines, parameter semantics, and behavioral transparency. While the output schema could mitigate some gaps, the description fails to provide enough context for the agent to understand when and how to use this tool effectively compared to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (website_id) with 0% description coverage in the schema itself. The tool description 'Current active visitors' adds no information about this parameter—it doesn't explain what website_id represents, how to obtain it, or its role in filtering results. With low schema coverage and no compensation in the description, this leaves the parameter's meaning entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Current active visitors' restates the tool name 'get_active' in different words, making it tautological. It doesn't specify what action the tool performs (e.g., 'retrieve', 'fetch', 'list') or what resource it operates on beyond the vague 'visitors'. While it implies reading visitor data, it lacks the specific verb+resource clarity needed to distinguish it from sibling tools like get_metrics or get_pageviews.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_metrics, get_pageviews, get_stats, or get_websites. It doesn't mention any context, prerequisites, or exclusions for usage. This leaves the agent with no information to make an informed choice among the available sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers nothing beyond the basic action. It doesn't indicate whether this is a read-only operation, what permissions might be required, whether it has rate limits, what format the statistics are returned in, or any other behavioral characteristics. This leaves the agent with significant uncertainty about how the tool behaves.
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 extremely concise at just three words, with no wasted language. It's front-loaded with the core action and resource. While this conciseness comes at the cost of completeness, structurally it's efficient with every word serving a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters including a nested filters object with 14 properties), 0% schema description coverage, and no annotations, the description is completely inadequate. While an output schema exists (which might help with understanding returns), the description fails to provide any context about what statistics are retrieved, how parameters affect results, or behavioral characteristics. For a tool with this level of parameter complexity, the description should do much more to help the agent understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the 4 parameters have descriptions in the schema. The tool description provides no information about parameters whatsoever—it doesn't mention 'website_id', date ranges, or filtering options. With 4 parameters (including a complex nested 'filters' object with 14 sub-properties) completely undocumented, this represents a major gap in understanding what inputs are needed and how they affect the results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get visitor statistics' states a basic action and resource but is vague about what specific statistics are retrieved. It doesn't distinguish this tool from sibling tools like 'get_metrics' or 'get_pageviews', leaving ambiguity about what differentiates these tools. While it avoids tautology with the tool name 'get_stats', it lacks specificity about the type of statistics returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_metrics', 'get_pageviews', or 'get_active'. There's no mention of prerequisites, appropriate contexts, or exclusions. The agent must infer usage purely from the tool name and parameters without any descriptive help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'View page traffic over time' implies a read-only operation but doesn't specify whether this requires authentication, has rate limits, returns paginated data, or what the output format looks like. The description is too minimal for a tool with 7 parameters and complex filtering capabilities.
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 maximally concise at 5 words with zero waste. Every word contributes meaning, and it's front-loaded with the core purpose. While more detail would be helpful, what's present is perfectly structured for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 14 filter options, time comparisons, and an output schema), the description is severely inadequate. While the output schema may document return values, the description doesn't prepare the agent for the tool's full capabilities or help navigate the extensive parameter set. This is a data retrieval tool with analytics functionality that deserves more explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. 'View page traffic over time' only hints at time-related parameters (start_at, end_at, unit) but ignores the 14 filter options, compare functionality, timezone handling, and required website_id. The description adds minimal value beyond what's obvious from the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'View page traffic over time' clearly states the verb ('view') and resource ('page traffic'), but it's somewhat vague about scope and doesn't distinguish from sibling tools like 'get_metrics' or 'get_stats' which might also provide traffic-related data. It's functional but lacks specificity about what makes this tool unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_metrics' or 'get_stats'. There's no mention of prerequisites, appropriate contexts, or exclusions. The agent must infer usage purely from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'List all your websites', which implies a read-only operation, but doesn't cover critical behaviors like pagination (implied by 'page' and 'page_size' parameters), search functionality, or whether it includes teams by default. The description misses key operational details needed for effective use.
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 extremely concise at four words, front-loading the core action and resource without any wasted text. It's appropriately sized for a simple listing tool, though this brevity contributes to gaps in other dimensions. Every word earns its place by directly stating the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no annotations, but with an output schema), the description is incomplete. It covers the basic purpose but lacks details on parameter usage, behavioral traits, and differentiation from siblings. The presence of an output schema means return values are documented elsewhere, but the description should still address input handling and context to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description 'List all your websites' doesn't mention any parameters, failing to compensate for this gap. It doesn't explain what 'include_teams', 'search', 'page', or 'page_size' do, leaving their semantics unclear. With 4 parameters and no schema descriptions, this is a significant shortfall.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all your websites' clearly states the verb ('List') and resource ('websites'), making the basic purpose understandable. However, it doesn't differentiate this tool from sibling tools like 'get_active' or 'get_pageviews', leaving ambiguity about what specific aspect of websites it retrieves. The description is functional but lacks specificity about scope or content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_active' or 'get_metrics'. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage based solely on the name. This lack of comparative or contextual advice reduces its effectiveness for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![umami-mcp-server MCP server](https://glama.ai/mcp/servers/Alurith/umami-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Alurith/umami-mcp-server)

Score Badge

Copy to your README.md:

[![umami-mcp-server MCP server](https://glama.ai/mcp/servers/Alurith/umami-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Alurith/umami-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Alurith/umami-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server