Skip to main content
Glama
go-ai-now

Plausible Analytics MCP Server

by go-ai-now

Plausible: aggregate stats

plausible_get_aggregate
Read-onlyIdempotent

Get headline totals like visitors, pageviews, and bounce rate for a site over a date range. Useful for quick overviews of key metrics.

Instructions

Get headline totals for a site over a date range (one number per metric, no grouping).

Use this for questions like "how many visitors last week?" or "what was the bounce rate in March for /pricing?". Use plausible_get_timeseries for trends over time and plausible_get_breakdown for top-N lists.

Examples:

  • Last 7 days overview: {"site_id": "example.com", "date_range": "7d"}

  • Conversions of a goal: {"date_range": "30d", "metrics": ["visitors", "events", "conversion_rate"], "filters": [{"dimension": "event:goal", "operator": "is", "values": ["Signup"]}]}

  • Custom range for one page: {"date_range": {"from": "2024-03-01", "to": "2024-03-31"}, "filters": [{"dimension": "event:page", "operator": "is", "values": ["/pricing"]}]}

Notes: scroll_depth/time_on_page need an event:page filter; conversion_rate and revenue metrics need an event:goal filter; percentage is not available here (it needs a dimension).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filtersNoFilters combined with logical AND. Each filter matches if any of its values match.
metricsNoMetrics to compute. Default: visitors, visits, pageviews, bounce_rate, visit_duration
site_idNoSite domain exactly as registered in Plausible, e.g. "example.com". Optional when PLAUSIBLE_DEFAULT_SITE_ID is set.
date_rangeNoEither a preset ("day", "24h", "7d", "28d", "30d", "91d", "month", "6mo", "12mo", "year", "all") or a custom range {"from": "2024-01-01", "to": "2024-01-31"}30d
response_formatNo"markdown" (default) for a readable table, "json" for machine-readable rowsmarkdown
include_importedNoInclude data imported from Google Analytics / CSV where Plausible supports it

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark the tool as read-only and idempotent, and the description adds valuable behavioral constraints: results are ungrouped headliners, and specific metrics have prerequisites such as 'scroll_depth/time_on_page need an event:page filter' and 'conversion_rate and revenue metrics need an event:goal filter.' It also notes percentage is unavailable because it requires a dimension.

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 front-loaded with the core purpose, followed by usage guidance, examples, and caveats. Every section earns its place given the six parameters and the need to disambiguate from sibling tools.

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?

With no output schema present, the description defines the result shape ('one number per metric, no grouping') and mentions the response_format parameter. It covers parameter combinations, metric constraints, and sibling differentiation, making it complete for an agent to select and invoke 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?

Schema description coverage is 100%, so the schema already documents all six parameters. The description still adds value with realistic examples showing parameter composition, and the Notes section clarifies metric-filter dependencies that the schema enum alone does not convey.

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 opens with a specific verb and resource: 'Get headline totals for a site over a date range (one number per metric, no grouping).' This clearly distinguishes the tool from the timeseries and breakdown siblings by highlighting the absence of grouping.

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?

It explicitly says to use this tool for 'how many visitors last week?' type questions and explicitly directs agents to plausible_get_timeseries for trends and plausible_get_breakdown for top-N lists. This gives unambiguous selection guidance.

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