Skip to main content
Glama
Sign In
umami-mcp-server

umami-mcp-server

by MurkyPuma
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_website_stats

Retrieve website analytics metrics such as pageviews, unique visitors, visits, bounces, and total time for a specified date range.

Instructions

Get overview metrics for a website over a date range.

Returns pageviews, unique visitors, visits, bounces, and total time. If you get no data, double-check the date range before assuming there is none.

Args: website_id: The website id (from get_websites). start_at: Range start, 'YYYY-MM-DD' or 'YYYY-MM-DD HH:MM:SS' (UTC). end_at: Range end, same formats (a bare date includes the whole day).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "website_id": "<website_id>",
      "start_at": "<start_at>",
      "end_at": "<end_at>"
    },
    "name": "get_website_stats"
  }
}

Input Schema

NameRequiredDescriptionDefault
website_idYes
start_atYes
end_atYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4/5.0
Behavior3/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. It mentions the date range formats and a common pitfall (no data), but does not disclose whether the operation is read-only, any authentication requirements, rate limits, or side effects. The description is adequate but lacks depth.

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 concise (4 sentences plus an args block), front-loads the purpose, and structures parameter docs clearly. No superfluous content, though the hint sentence could be more precise.

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

Completeness4/5

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

Given three parameters and no annotations, the description covers the function, parameter semantics, and a usage tip. It does not detail the output structure (but an output schema exists), and could mention pagination or error handling. Still largely sufficient.

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?

Despite 0% schema description coverage, the description provides detailed docstrings for all three parameters: website_id comes from get_websites, start_at/end_at have clear format specifications including timezone and whole-day handling. This adds significant meaning beyond the bare JSON schema.

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 clearly states 'Get overview metrics for a website over a date range' and lists the specific metrics (pageviews, unique visitors, visits, bounces, total time). This is a specific verb+resource combination that differentiates from sibling tools like get_active_visitors or get_website_metrics.

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

Usage Guidelines3/5

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

The description includes a useful hint about checking the date range when no data is returned, but it does not provide explicit guidance on when to use this tool versus alternatives like get_website_metrics or get_pageview_series. Usage context is implied but not clearly defined.

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