Allows AI models to query analytics data from Plausible, enabling access to website traffic statistics and generating analytics reports for specified domains.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Plausible MCP Server show me yesterday's traffic for avimbu.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP Interaction Server for Plausible Analytics
A Model Context Protocol (MCP) server implementation for interacting with the Plausible Analytics API. This server allows AI models to query analytics data from Plausible.
In order to run this client locally, add the following configuration to your Claude Desktop MCP Server config file:
{
"mcpServers": {
"mcp-plausible-local": {
"command": "node",
"args": ["/path/to/project/dist/index.js"], <---- replace this with your project path
"env": {
"PLAUSIBLE_API_URL": "https://plausible.io/api/v2",
"PLAUSIBLE_API_KEY": "test_api_key"
}
},
}
}After this, you should be able to test this implementation in your Claude Desktop App using example prompts like:
"Can you provide a daily overview of my analytics for avimbu.com?"
"Can you generate relevant analytics reports from my Plausible account for the domain avimbu.com?"
Running the server locally:
node dist/index.jsWith the build in another terminal
npm run watchRelated MCP server: Umami MCP Server
If you have questions, feel free to contact us via AVIMBU.
Query analytics data from Plausible
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes | The domain of the site to query data for | |
| metrics | Yes | String list of metrics to query with the following options: 'visitors' 'int' The number of unique visitors | 'visits' 'int' The number of visits/sessions | 'pageviews' 'int' The number of pageview events | 'views_per_visit' 'float' The number of pageviews divided by the number of visits. | 'bounce_rate' 'float' Bounce rate percentage | 'visit_duration' 'int' Visit duration in seconds | 'events' 'int' The number of events (pageviews + custom events). When filtering by a goal, this metric corresponds to 'Total Conversions' in the dashboard. | 'scroll_depth' 'int' Page scroll depth averaged per session Requires event:page filter or dimension being set | 'percentage' 'float' The percentage of visitors of total who fall into this category Requires non-empty dimensions | 'conversion_rate' 'float' The percentage of visitors who completed the goal. Requires non-empty dimensions, event:goal filter or dimension being set | 'group_conversion_rate' 'float' The percentage of visitors who completed the goal with the same dimension. Requires: dimension list passed, an event:goal filter or event:goal dimension Requires non-empty dimensions, event:goal filter or dimension being set | 'average_revenue' 'Revenue' or null Average revenue per revenue goal conversion Requires revenue goals, event:goal filter or dimension for a relevant revenue goal. | 'total_revenue' 'Revenue' or null Total revenue from revenue goal conversions Requires revenue goals, event:goal filter or dimension for a relevant revenue goal. | |
| date_range | Yes | Date range for the query, with the following options: ["2024-01-01", "2024-07-01"] Custom date range (ISO8601) | ["2024-01-01T12:00:00+02:00", "2024-01-01T15:59:59+02:00"] Custom date-time range (ISO8601) | "day" Current day (e.g. 2024-07-01) | "7d" Last 7 days relative to today | "30d" Last 30 days relative to today | "month" Since the start of the current month | "6mo" Last 6 months relative to start of this month | "12mo" Last 12 months relative to start of this month | "year" Since the start of this year | "all" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It doesn't disclose whether this is a read-only query, requires authentication, has rate limits, or what the output format might be. 'Query' implies read-only, but this isn't explicitly stated, leaving gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 required parameters, no output schema, no annotations), the description is insufficient. It doesn't explain what the query returns, error conditions, or usage constraints, leaving the agent with incomplete context for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, providing detailed documentation for all parameters (site_id, metrics, date_range). The description adds no additional parameter semantics beyond what's already in the schema, so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Query') and resource ('analytics data from Plausible'), making the purpose evident. It doesn't need sibling differentiation since there are no sibling tools, but it could be more specific about what type of analytics data (e.g., metrics, dimensions, filters).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, prerequisites, or typical use cases. It's a generic statement that doesn't help an agent understand the appropriate context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0plausible_queryWith only one tool, there is no possibility of ambiguity or overlap between tools. The single tool has a distinct and clear purpose.
A single tool inherently has perfect naming consistency as there are no other tools to compare it against. The name 'plausible_query' follows a clear verb_noun pattern.
One tool is too few for a server intended to interact with an analytics platform like Plausible, which typically involves multiple operations such as fetching metrics, listing sites, or managing settings. This severely limits functionality.
The tool set is severely incomplete for a Plausible analytics server. It only provides querying capability, missing essential operations like listing sites, getting site details, managing goals, or accessing other analytics endpoints, which will cause significant agent failures.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Query site stats, realtime visitors, breakdowns and goals from Plausible Analytics.
Privacy-first web analytics. Query pageviews, referrers, trends, and AI insights.
Query your Betterlytics web analytics from AI agents: traffic, funnels, journeys, errors, uptime.
SEO & marketing toolkit for AI agents: GA4, Search Console, AdSense, GTM, PageSpeed, Trends.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AVIMBU/plausible-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
