Skip to main content
Glama
The-Focus-AI

Plausible MCP

by The-Focus-AI
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Plausible MCP

Hey there! Let's talk about bringing analytics data right into your conversations — because that's what this project is all about. It's a Model Context Protocol (MCP) server that lets you chat with your Plausible Analytics data as naturally as asking a colleague "how's the website doing?"

The hardest thing about analytics dashboards is that they're stuck in the old paradigm of clicking through filters and dimensions. We're living in the future now — let's make our analytics data as accessible as asking a question.

What's This All About?

This MCP server bridges the gap between Plausible's powerful analytics API and the way we naturally think about our website stats. Want to know your most visited pages? Or where your traffic is coming from? Just ask!

Key Features

  • 🤝 Natural interaction with your Plausible Analytics data

  • 📊 Get insights about traffic, visitors, and engagement

  • 🌍 Break down stats by country, device, or any dimension you care about

  • 🔒 Secure API key handling with 1Password integration

  • 🎯 Type-safe implementation with TypeScript and Zod

Related MCP server: Plausible Analytics MCP Server

Real-World Examples

Here's what you can do — and yes, these are actual queries that work:

# Basic Questions
> What were my most visited pages last week?
{
  "site_id": "example.com",
  "metrics": ["pageviews"],
  "dimensions": ["event:page"],
  "date_range": "7d",
  "limit": 10
}

> Where's my traffic coming from?
{
  "site_id": "example.com",
  "metrics": ["visitors"],
  "dimensions": ["visit:source"],
  "date_range": "30d"
}

> Show me visitor trends by country
{
  "site_id": "example.com",
  "metrics": ["visitors"],
  "dimensions": ["visit:country"],
  "date_range": "month"
}

# Content Performance
> Which blog posts have the highest bounce rate?
{
  "site_id": "example.com",
  "metrics": ["bounce_rate"],
  "dimensions": ["event:page"],
  "filters": [["contains", "event:page", ["/blog"]]],
  "date_range": "30d"
}

> What's the average time spent on documentation pages?
{
  "site_id": "example.com",
  "metrics": ["visit_duration"],
  "dimensions": ["event:page"],
  "filters": [["contains", "event:page", ["/docs"]]],
  "date_range": "7d"
}

# Traffic Analysis
> Show me mobile vs desktop traffic trends
{
  "site_id": "example.com",
  "metrics": ["visitors", "pageviews"],
  "dimensions": ["visit:device"],
  "date_range": "30d"
}

> Which browsers do my visitors use?
{
  "site_id": "example.com",
  "metrics": ["visitors"],
  "dimensions": ["visit:browser"],
  "date_range": "30d"
}

# Marketing Insights
> How's our social media traffic performing?
{
  "site_id": "example.com",
  "metrics": ["visitors", "bounce_rate"],
  "dimensions": ["visit:source"],
  "filters": [["is", "visit:source", ["Twitter", "LinkedIn", "Facebook"]]],
  "date_range": "30d"
}

> Which UTM campaigns are driving the most engagement?
{
  "site_id": "example.com",
  "metrics": ["visitors", "visit_duration"],
  "dimensions": ["visit:utm_campaign"],
  "date_range": "month"
}

# Geographic Analysis
> Show me traffic from European cities
{
  "site_id": "example.com",
  "metrics": ["visitors"],
  "dimensions": ["visit:city"],
  "filters": [["is", "visit:country", ["GB", "DE", "FR", "ES", "IT"]]],
  "date_range": "30d"
}

# Time-Based Analysis
> How does traffic vary throughout the day?
{
  "site_id": "example.com",
  "metrics": ["visitors"],
  "dimensions": ["hour"],
  "date_range": "day"
}

# Complex Queries
> Show me popular blog posts from mobile users in the US
{
  "site_id": "example.com",
  "metrics": ["pageviews", "visit_duration"],
  "dimensions": ["event:page"],
  "filters": [["and", [
    ["contains", "event:page", ["/blog"]],
    ["is", "visit:device", ["mobile"]],
    ["is", "visit:country", ["US"]]
  ]]],
  "date_range": "30d"
}

> Which pages have high engagement from social media?
{
  "site_id": "example.com",
  "metrics": ["visit_duration", "views_per_visit"],
  "dimensions": ["event:page"],
  "filters": [["is", "visit:source", ["Twitter", "LinkedIn", "Facebook"]]],
  "date_range": "30d"
}

These examples just scratch the surface — you can combine metrics, dimensions, and filters in countless ways to get exactly the insights you need. The beauty is in how natural it feels to ask these questions and get immediate answers.

Getting Started

First things first, let's get you set up:

pnpm install

Configuration

You've got two ways to handle your Plausible API key — choose what works for you:

  1. Create a .env file:

PLAUSIBLE_API_KEY=your_api_key_here
PLAUSIBLE_API_URL=https://plausible.io/api/v2

  1. Or use 1Password (my preferred way): Store your key at "op://Development/plausible api/notesPlain"

The Tools at Your Disposal

list_sites

Gets you a list of all your Plausible sites. Simple but useful when you're just getting started.

get_breakdown

This is where the magic happens. Think of it as your analytics Swiss Army knife:

Metrics You Can Track

  • visitors - Unique visitors (the real people)

  • pageviews - Total page loads

  • bounce_rate - One-and-done visits

  • visit_duration - How long people stick around

  • views_per_visit - Pages per session

  • And more!

Ways to Slice the Data

Break it down by:

  • Pages (event:page)

  • Traffic sources (visit:source)

  • Countries (visit:country)

  • Devices (visit:device)

  • Time periods (minute, hour, day, week, month)

Time Ranges

Look at:

  • Last 24 hours (day)

  • Last N days (7d, 30d)

  • This month (month)

  • Last N months (6mo, 12mo)

  • Custom date ranges

Smart Filtering

Filter your data like a pro:

// Just Chrome users
{"filters": [["is", "visit:browser", ["Chrome"]]]}

// Blog traffic only
{"filters": [["contains", "event:page", ["/blog"]]]}

// Traffic from specific countries
{"filters": [["is", "visit:country", ["US", "GB", "CA"]]]}

// Complex stuff - Chrome users from the US
{"filters": [["and", [
  ["is", "visit:browser", ["Chrome"]],
  ["is", "visit:country", ["US"]]
]]]}

What's Next?

We're pushing this to the next level. On the roadmap:

  • Even smarter query handling

  • Better response formatting

  • More examples of common analytics questions

  • Comprehensive error handling

  • Performance optimizations

Development

Jump in and help us figure it out:

# Build it
pnpm build

# Run it
pnpm start

Rate Limits & Performance

  • 600 requests per hour (that's the Plausible limit)

  • Real-time data, no caching

  • Snappy response times

License

MIT - because sharing is caring!

The analytics world is transforming from dashboards and SQL queries to natural conversations about your data. We're figuring it out as we go, but that's what makes it exciting. Let's make analytics as accessible as asking a question — because that's where this is all heading.

Available Tools

4 tools
analyze_pageC

Get detailed analytics for a specific page

ParametersJSON Schema
NameRequiredDescriptionDefault
site_idYesYour website domain
pageYesPage path (e.g. '/blog/post-1')
timeRangeYes
includeNo

TDQS

C2.8/5.0
Behavior2/5

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

No annotations provided, so description must carry full behavioral burden. It only says 'Get detailed analytics' with no mention of side effects, data granularity, or whether it returns aggregated or raw data. Fails to disclose traits beyond the basic action.

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?

Single sentence with no redundant words. All information is front-loaded and efficient.

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?

No output schema, 4 parameters (3 required), no annotations. Description is minimal and does not explain return values, error conditions, or performance implications. Incomplete for a tool that likely returns complex analytics data.

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 50%, meaning half of parameters (e.g., include) lack descriptions in the schema. The tool description adds no additional meaning to parameters beyond what the schema provides, failing to compensate for the coverage gap.

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

Purpose4/5

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

Description clearly states verb 'Get' and resource 'detailed analytics for a specific page', distinguishing it from siblings like get_traffic (overall) and list_sites (list sites). It lacks specificity on what 'detailed' entails, but purpose is clear.

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?

No guidance on when to use this tool vs alternatives like get_traffic or get_breakdown. Context of use is purely implied by the name and description, with no explicit exclusions or prerequisites.

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

get_breakdownA

Get detailed analytics breakdown for a site.

COMMON QUERIES:

  1. Most visited pages in last 7 days: {"site_id": "example.com", "metrics": ["visitors", "pageviews"], "dimensions": ["event:page"], "date_range": "7d"}

  2. Traffic sources with bounce rates: {"site_id": "example.com", "metrics": ["visitors", "bounce_rate"], "dimensions": ["visit:source"], "date_range": "30d"}

  3. Geographic breakdown: {"site_id": "example.com", "metrics": ["visitors", "visit_duration"], "dimensions": ["visit:country", "visit:city"], "date_range": "month"}

  4. Hourly visitor trends for today: {"site_id": "example.com", "metrics": ["visitors", "pageviews"], "dimensions": ["time:hour"], "date_range": "day"}

  5. Device and browser analysis: {"site_id": "example.com", "metrics": ["visitors", "bounce_rate"], "dimensions": ["visit:device", "visit:browser"], "date_range": "7d"}

  6. Campaign performance: {"site_id": "example.com", "metrics": ["visitors", "views_per_visit"], "dimensions": ["visit:utm_campaign", "visit:utm_source"], "date_range": "month"}

AVAILABLE METRICS:

  • visitors: Number of unique visitors

  • visits: Number of visits/sessions

  • pageviews: Number of pageview events

  • views_per_visit: Average number of pages viewed per visit

  • bounce_rate: Percentage of visits with only one page view

  • visit_duration: Average visit duration in seconds

  • events: Total number of events (pageviews + custom events)

AVAILABLE DIMENSIONS: Event dimensions (page/content related):

  • event:name - Event name (e.g., 'pageview', 'download', etc.)

  • event:page - Full page URL including UTM parameters

  • event:page.pathname - Page path without query parameters

  • event:props:* - Custom event properties (e.g., event:props:author)

Visit dimensions (visitor/session related):

  • visit:source - Traffic source (e.g., 'Google', 'Twitter')

  • visit:referrer - Full referrer URL

  • visit:utm_medium - Marketing medium (e.g., 'cpc', 'social')

  • visit:utm_source - UTM source parameter

  • visit:utm_campaign - UTM campaign name

  • visit:utm_content - UTM content parameter

  • visit:utm_term - UTM term parameter

  • visit:device - Device type (desktop, mobile, tablet)

  • visit:browser - Browser name

  • visit:browser_version - Browser version

  • visit:os - Operating system

  • visit:os_version - OS version

  • visit:country - Country of visitor

  • visit:country_name - Full country name

  • visit:region - Region/state of visitor

  • visit:region_name - Full region/state name

  • visit:city - City of visitor

  • visit:city_name - Full city name

Time dimensions (for trends and patterns):

  • time:minute - Group by minute (only available with 'day' time:day range)

  • time:hour - Group by hour (only available with 'day' time:day range)

  • time:day - Group by day (available with any time:day range)

  • time:week - Group by week (available with 'month', '6mo', '12mo', or custom ranges)

  • time:month - Group by month (available with '6mo', '12mo', or custom ranges)

Note: Time dimensions are mutually exclusive - only one can be used at a time. When using time dimensions, results are automatically sorted chronologically.

FILTERING EXAMPLES:

  1. Only Chrome users: {"filters": [["is", "visit:browser", ["Chrome"]]]}

  2. Blog pages only: {"filters": [["contains", "event:page", ["/blog"]]]}

  3. Multiple countries: {"filters": [["is", "visit:country", ["US", "GB", "CA"]]]}

  4. Exclude certain pages: {"filters": [["is_not", "event:page", ["/admin", "/login"]]]}

  5. Complex filter (Chrome users from US): {"filters": [["and", [["is", "visit:browser", ["Chrome"]], ["is", "visit:country", ["US"]]]]]}

ParametersJSON Schema
NameRequiredDescriptionDefault
site_idYesYour website domain as configured in Plausible (e.g., 'example.com')
metricsNoList of metrics to calculate. Default: ['visitors']. See AVAILABLE METRICS above for options.
dimensionsNoProperties to group results by. Default: ['time:day']. See AVAILABLE DIMENSIONS above for options. 'date' is not a valid dimension
date_rangeNoTime period to analyze. Options: - 'day': Last 24 hours - '7d', '30d': Last N days - 'month': Current month - '6mo', '12mo': Last N months - Custom ISO dates: ['2024-01-01', '2024-01-31'] Default: '7d'
filtersNoFilter conditions to apply. See FILTERING EXAMPLES above. Operators: is, is_not, contains, contains_not, matches, matches_not
limitNoMaximum number of results to return. Default: 10000
pageNoPage number for pagination. Default: 1

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are provided, so the description bears full burden. It details available metrics, dimensions, filtering operators, and constraints like time dimension mutual exclusivity. It could mention rate limits or data freshness but is otherwise transparent.

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?

Well-structured with clear sections (COMMON QUERIES, AVAILABLE METRICS, etc.) and front-loaded purpose. However, it is somewhat lengthy due to many examples; could be slightly more concise.

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 the tool's complexity (7 parameters, no output schema), the description covers parameters, filtering, and available values comprehensively. Missing explicit return structure but still very complete.

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 coverage is 100% with good descriptions. The description adds significant value by listing available metrics/dimensions, providing filtering examples, and explaining parameters beyond the 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?

Description clearly states 'Get detailed analytics breakdown for a site' with specific verb and resource. It distinguishes from siblings like get_traffic by focusing on breakdowns with dimensions and metrics.

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?

Provides extensive examples and common queries that implicitly guide usage. However, it does not explicitly state when to use alternatives or exclude inappropriate use cases.

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

get_trafficB

Get traffic analytics for a site using structured parameters

ParametersJSON Schema
NameRequiredDescriptionDefault
site_idYesThe website domain to analyze (e.g., 'example.com')
time_rangeNoTime period to analyze7d
metricsNoMetrics to calculate
dimensionsNoProperties to group results by
filtersNoFilter conditions to apply (e.g., [['is', 'visit:country', ['US']]])

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only status, rate limits, or authentication requirements.

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?

Single sentence, concise and to the point with no unnecessary words.

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?

Despite having 5 parameters and no output schema, the description is too brief. It does not explain what the tool returns or provide usage context beyond the schema.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond what is already in the 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 the tool retrieves traffic analytics for a site using structured parameters. 'Get' and 'traffic analytics' are specific, and it distinguishes from sibling tools like analyze_page or list_sites.

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?

No guidance on when to use this tool versus alternatives. Sibling tools are listed but no comparative context is provided.

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

list_sitesA

List all sites in your Plausible account

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior2/5

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

No annotations provided; description lacks behavioral details such as authentication requirements, rate limits, or pagination. Simple operation but minimal disclosure.

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?

Single sentence, front-loaded, every word earns its place. No unnecessary information.

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?

Adequate for a simple list with no parameters. Does not describe return format, but tool complexity is low.

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?

No parameters, baseline score of 4 per rules. Schema coverage is trivial 100%.

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?

Clear verb 'List' and resource 'sites', with scope 'all sites in your Plausible account'. Distinct from sibling tools that analyze or retrieve traffic data.

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?

Implied usage is straightforward: when you need a list of sites. No explicit when-not or alternatives, but tool purpose is self-evident.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0
Disambiguation2/5

analyze_page and list_sites are distinct, but get_breakdown and get_traffic both provide site analytics with unclear differentiation, causing potential for confusion.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (e.g., analyze_page, get_breakdown), making naming predictable and clear.

Tool Count3/5

4 tools is slightly thin for an analytics server; while it covers basic operations, two overlapping tools suggest the count could be reduced or expanded.

Completeness3/5

Core analytics queries are covered, but missing functionality like managing goals or real-time data means agents may encounter dead ends.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Plausible MCP Server

    AVIMBU
    F
    license
    B
    quality
    D
    maintenance
    Allows AI models to query and retrieve analytics data from Plausible Analytics through the Plausible API, enabling natural language interactions with website statistics.
    1
    8

  • Plausible Analytics MCP Server

    Defilan
    A
    license
    A
    quality
    C
    maintenance
    Enables AI assistants to query website statistics from Plausible Analytics, providing access to metrics like real-time visitors, traffic trends, and page performance. It supports both Plausible Cloud and self-hosted instances through the Stats API v2.
    6
    33
    1
    MIT

  • plausible-mcp

    alexanderop
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables querying Plausible Analytics data for website statistics, traffic, engagement, and conversions through natural language, with support for filters, dimensions, and time-series.
    6

  • Pirsch Analytics MCP Server

    verygoodplugins
    A
    license
    A
    quality
    A
    maintenance
    Enables natural language analytics queries for Pirsch Analytics, providing comprehensive website traffic statistics, period comparisons, and trend analysis through an MCP interface.
    4
    241
    1
    MIT

Latest Blog Posts

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/The-Focus-AI/plausible-mcp'

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