Provides tools for querying traffic, conversions, sources, device breakdowns, real-time visitors, and other analytics from Plausible Analytics, supporting various metrics, dimensions, filters, and date ranges.
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 top traffic sources for this month"
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 server for Plausible Analytics — privacy-friendly web analytics. Query traffic, conversions, sources, and device breakdowns from any MCP-compatible AI assistant.
Flexible stats queries — metrics, dimensions, filters, date ranges
Real-time visitors — live visitor count
Traffic breakdowns — sources, countries, browsers, UTM campaigns
Time-series data — daily, weekly, monthly, hourly intervals
Custom events — event tracking and conversion rates
Entry/exit pages — where visitors land and leave
Device analytics — browser, OS, screen size breakdowns
Goal tracking — conversion stats for all configured goals
Site management — list and inspect sites
Related MCP server: plausible-mcp
Tool | Description |
| Full flexible stats query (the main endpoint) |
| Current real-time visitor count |
| Breakdown by any dimension (source, page, country, etc.) |
| Metrics over time with configurable intervals |
| List all sites in your account |
| Get site details |
| Custom event breakdown |
| Top landing pages |
| Top exit pages |
| UTM campaign/source/medium breakdowns |
| Browser, OS, screen size breakdowns |
| Conversion stats for all goals |
A Plausible Analytics account (cloud or self-hosted)
An API key — generate one at Site Settings → API Keys in your Plausible dashboard
Add to your MCP client config (e.g. Claude Desktop, Cursor):
{
"mcpServers": {
"plausible": {
"command": "node",
"args": ["/path/to/plausible-mcp-server/dist/index.js"],
"env": {
"PLAUSIBLE_API_KEY": "your-api-key-here"
}
}
}
}For self-hosted Plausible, also set:
"env": {
"PLAUSIBLE_API_KEY": "your-api-key",
"PLAUSIBLE_API_BASE": "https://your-plausible-instance.com"
}git clone https://github.com/friendlygeorge/plausible-mcp-server.git
cd plausible-mcp-server
npm install
npx tscOnce configured, ask your AI assistant:
"Show me the top traffic sources for my site this month"
"How many visitors did I get today?"
"What's the time-series of pageviews for the last 30 days?"
"Which pages have the highest bounce rate?"
"Show me UTM campaign performance"
"What are my top entry pages?"
"Show conversion rates for all goals"
"Break down visitors by country for the last week"
Variable | Required | Default | Description |
| Yes | — | Your Plausible API key |
| No |
| API base URL (change for self-hosted) |
visitors, visits, pageviews, views_per_visit, visit_duration, events, bounce_rate, scroll_depth, conversion_rate
visit:source, visit:referrer, visit:utm_source, visit:utm_medium, visit:utm_campaign, visit:utm_content, visit:utm_term, visit:country_name, visit:city_name, visit:screen, visit:browser, visit:browser_version, visit:os, visit:os_version, visit:entry_page, visit:exit_page, event:page, event:name, event:goal, event:props:<key>
MIT
Get a breakdown of visitors by a specific dimension (top sources, pages, countries, browsers, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 100) | |
| filters | No | Additional filters | |
| site_id | Yes | The site ID (domain) | |
| property | Yes | Dimension to break down: 'visit:source', 'visit:referrer', 'visit:utm_source', 'visit:country_name', 'visit:city_name', 'visit:browser', 'visit:os', 'visit:screen', 'event:page', 'event:goal' | |
| date_range | Yes | Date range: 'today', '7d', '30d', 'month', 'year', or 'YYYY-MM-DD,YYYY-MM-DD' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Get a breakdown' without mentioning side effects, rate limits, auth needs, or pagination behavior. The schema's default limit is mentioned but not in description.
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?
Single sentence, no fluff, efficiently conveys the tool's purpose.
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?
With 5 parameters (3 required) and no output schema or annotations, the description is too brief. It does not explain date_range formats, filter usage, or return format, leaving gaps for correct 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?
Schema coverage is 100%, so baseline is 3. The description lists example dimensions but adds no extra meaning beyond the schema's property enum values or other parameters.
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 uses a specific verb ('Get') and resource ('breakdown of visitors'), and lists example dimensions (sources, pages, countries, browsers). This clearly distinguishes it from sibling tools like query_stats or get_timeseries.
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 implies usage for breakdown by dimension, but provides no explicit guidance on when to use over alternatives like query_stats or get_timeseries, nor 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 custom event breakdown — see which events fire most, conversion rates, and revenue.
| Name | Required | Description | Default |
|---|---|---|---|
| filters | No | Filters like 'event:name==signup' | |
| site_id | Yes | The site ID (domain) | |
| date_range | Yes | Date range: '7d', '30d', 'month', 'year' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as data freshness, permissions, pagination, or whether the operation is read-only. Only output hints are given.
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 sentence, concise and front-loaded. It could be more structured but is efficient.
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?
No output schema exists, so the description should explain return values. It mentions 'events fire most, conversion rates, and revenue', which provides some context but lacks detail on structure. Adequate but not thorough.
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?
Schema coverage is 100% with all parameters described. The description does not add new meaning beyond the schema, but the schema itself is clear. Baseline 3 is appropriate.
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 verb 'Get', the resource 'custom event breakdown', and the specific outputs: events fire most, conversion rates, revenue. It distinguishes itself from siblings like 'get_breakdown' or 'get_goals' by focusing on custom events.
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 a basic purpose but does not explicitly guide when to use this tool versus alternatives like 'get_breakdown' or 'get_timeseries'. Usage is implied but not clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get breakdown by device type, browser, OS, and screen size.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes | The site ID (domain) | |
| dimension | No | Device dimension (default: browser) | |
| date_range | Yes | Date range: '7d', '30d', 'month', 'year' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states what is returned, but omits details about pagination, rate limits, permissions, or how the breakdown is structured.
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 concise sentence that front-loads the core purpose. No fluff, but could benefit from slight restructuring to mention parameters.
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 no output schema and no annotations, the description is insufficient. It does not explain the return format, any limits, or how to interpret the breakdown, leaving gaps for a tool with 3 parameters.
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?
Schema coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond listing the dimensions. Baseline of 3 is appropriate.
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 tool returns breakdowns by device type, browser, OS, and screen size, specifying the resource and dimensions. However, it does not differentiate from siblings like get_breakdown, which might serve a similar purpose.
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?
No guidance on when to use this tool versus alternatives such as get_breakdown or query_stats. Lacks any context about prerequisites or recommended scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get top entry pages — where visitors land on your site.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 100) | |
| site_id | Yes | The site ID (domain) | |
| date_range | Yes | Date range: '7d', '30d', 'month', 'year' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It lacks details on what 'top' means, pagination, authentication needs, or return format. The agent cannot infer behavioral traits beyond basic retrieval.
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?
Single sentence, front-loaded, no unnecessary words. Earns its place efficiently.
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 no output schema and no annotations, the description is too brief. It does not explain how results are sorted, the meaning of 'entry pages', or limitations. Agent may have incomplete understanding.
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?
Schema coverage is 100% with each parameter described. The description adds no further parameter semantics beyond what the schema provides, meeting the baseline.
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?
Clear verb+resource: 'Get top entry pages' is specific and distinguishes from sibling 'get_exit_pages'. The phrase 'where visitors land on your site' adds context.
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?
Usage is implied from name and description, but no explicit when-to-use or when-not-to-use guidance is provided. No mention of alternatives like 'get_breakdown' for more detailed analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get top exit pages — where visitors leave your site.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 100) | |
| site_id | Yes | The site ID (domain) | |
| date_range | Yes | Date range: '7d', '30d', 'month', 'year' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose any behavioral traits such as data recency, pagination, aggregation, or whether results are ordered. It only states the basic function without safety or performance implications.
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, well-structured sentence that immediately conveys the main purpose. Every word is meaningful, with no redundancy.
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 lack of output schema, the description should hint at the response structure (e.g., ordered list of pages with counts). It does not, but the tool is simple enough that an agent might infer basic behavior.
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?
Schema description coverage is 100%, so the parameters are already documented. The tool description adds no extra semantic value beyond the schema, meeting the baseline for high coverage.
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 tool retrieves top exit pages, with a clarifying phrase 'where visitors leave your site.' It directly contrasts with its sibling 'get_entry_pages,' making the purpose unambiguous.
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?
No guidance is provided on when to use this tool versus alternatives like 'get_entry_pages' or other analytics tools. The description lacks context for optimal usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get conversion stats for all configured goals on a site.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes | The site ID (domain) | |
| date_range | Yes | Date range: '7d', '30d', 'month', 'year' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool gets stats but does not disclose whether it is read-only, what the return format looks like, or any potential side effects. It lacks behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action. It has no filler, but its brevity may sacrifice clarity. A bit more context could be added without hurting conciseness.
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 no output schema and limited sibling distinction, the description is incomplete. It does not clarify what 'conversion stats' includes, how the date range affects results, or how this differs from other stats tools. An agent may need additional information to use it correctly.
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?
Schema coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond what is in the schema. Baseline 3 is appropriate.
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 it retrieves conversion stats for all goals on a site. It uses a specific verb (Get) and resource (conversion stats for goals), which distinguishes it from siblings like get_custom_events. However, it could be more precise about the scope (e.g., 'all configured goals').
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?
No guidance is provided on when to use this tool versus alternatives like query_stats or get_custom_events. The description does not mention prerequisites, context, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific site.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes | The site ID (domain) to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as authentication requirements, rate limits, side effects, or what 'detailed information' entails. For a sensitive resource lookup, this is insufficient.
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, front-loaded sentence with no unnecessary words. It efficiently conveys the tool's purpose.
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 lack of output schema and annotations, the description fails to specify what 'detailed information' includes. The agent cannot infer the response structure, making the tool's full capabilities unclear.
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?
Schema coverage is 100% for the single parameter site_id, which is well-described in the schema. The description adds no additional meaning beyond the schema, so it meets the baseline but does not exceed it.
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 tool retrieves detailed information for a specific site, using a specific verb and resource. It distinguishes from siblings like list_sites (which lists all sites) and various analytics tools (which return specific metrics).
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?
No guidance on when to use this tool versus alternatives like list_sites or get_breakdown. No context about prerequisites, common usage patterns, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get time-series data for one or more metrics — daily, hourly, weekly, or monthly intervals.
| Name | Required | Description | Default |
|---|---|---|---|
| filters | No | Filters to apply | |
| metrics | Yes | Metrics: visitors, visits, pageviews, events, bounce_rate, visit_duration | |
| site_id | Yes | The site ID (domain) | |
| interval | No | Interval: 'date' (default), 'month', 'week', 'hour' (last 24h only) | |
| date_range | Yes | Date range: '7d', '30d', 'month', 'year', or 'YYYY-MM-DD,YYYY-MM-DD' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'Get time-series data', implying a read operation, but omits details like rate limits, data freshness, maximum metrics, or response format.
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 concise sentence that front-loads the purpose and key functionality. No filler or redundant information.
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 has 5 parameters and no output schema, the description is too sparse. It does not explain the return format, date range syntax details, or filtering capabilities, leaving significant gaps for an agent.
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?
Schema coverage is 100%, so the schema already documents all parameters. The description adds 'daily, hourly, weekly, or monthly intervals' which mirrors the schema but does not provide additional meaning. Baseline 3 is appropriate.
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 tool retrieves time-series data for metrics with various intervals, specifying verb and resource. However, it does not explicitly distinguish from sibling tools like query_stats or get_breakdown, leaving the agent to infer differentiation.
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?
No guidance is provided on when to use this tool versus alternatives like query_stats or realtime_visitors. The description lacks context for optimal usage, making it hard for an agent to select appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get UTM campaign, source, and medium breakdowns — see which campaigns drive traffic.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes | The site ID (domain) | |
| dimension | No | Which UTM dimension (default: utm_campaign) | |
| date_range | Yes | Date range: '7d', '30d', 'month', 'year' |
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. It only states it returns breakdowns but does not mention whether the tool is read-only, any required permissions, rate limits, or side effects. The behavior is assumed non-destructive but not explicit.
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 sentence that is concise and front-loaded with the core purpose. It could benefit from slightly more structure (e.g., listing parameters) but remains efficient.
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 three parameters, no output schema, and moderate complexity, the description is insufficient. It does not explain the return format (e.g., counts, percentages, date ranges) or provide examples. For a stats tool, more context on output structure is needed.
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?
Schema coverage is 100% with all three parameters described. The description adds context by listing 'campaign, source, and medium' as example breakdowns, but does not provide additional meaning for each parameter beyond what the schema already offers. Baseline score of 3 due to full schema coverage.
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 uses a specific verb ('Get') and clearly identifies the resource ('UTM campaign, source, and medium breakdowns'). It also states the benefit ('see which campaigns drive traffic'), which distinguishes it from sibling tools like query_stats or get_breakdown.
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 such as get_breakdown or get_device_stats. It implies usage for UTM analysis but does not mention exclusions, prerequisites, or compare with similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all sites in your Plausible account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'list' without disclosing whether results are paginated, sorted, or limited to user-accessible sites. The behavior beyond listing is opaque.
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, concise sentence that efficiently communicates the tool's purpose with no wasted words.
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 no output schema and no annotations, the description fails to inform the agent about the return value structure (e.g., an array of site objects with properties). This is a gap for a tool whose output is not self-evident.
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?
There are zero parameters, so baseline is 4. The description does not need to add parameter semantics since none exist.
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 'List all sites in your Plausible account' clearly states the verb 'List' and the resource 'sites', making the tool's purpose distinct from siblings like 'query_stats' or 'get_site'.
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?
No guidance is provided on when to use this tool versus alternatives. For example, it could mention that it is useful for retrieving site IDs before using other site-specific tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query Plausible analytics with full flexibility — metrics, dimensions, filters, date ranges. The main stats endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default: 100, max: 10000) | |
| filters | No | Filters like 'visit:source==Google', 'event:page==/blog', 'visit:country_name==United States' | |
| include | No | Include extra fields: 'events', 'page', 'custom_props' | |
| metrics | Yes | Metrics to calculate: visitors, visits, pageviews, views_per_visit, visit_duration, events, bounce_rate, scroll_depth, conversion_rate | |
| site_id | Yes | The site ID (domain) to query, e.g. 'example.com' | |
| order_by | No | Order results, e.g. [['visitors', 'desc']] | |
| date_range | Yes | Date range: 'today', 'yesterday', '7d', '30d', 'month', 'year', 'all', or 'YYYY-MM-DD,YYYY-MM-DD' | |
| dimensions | No | Group by dimensions: visit:source, visit:referrer, visit:utm_source, visit:utm_medium, visit:utm_campaign, visit:utm_content, visit:utm_term, visit:country_name, visit:city_name, visit:screen, visit:browser, visit:browser_version, visit:os, visit:os_version, visit:entry_page, visit:exit_page, event:page, event:name, event:goal, event:props:<key> |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors like auth requirements, rate limits, or error handling. It only states flexibility and endpoints, omitting critical operational details.
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 concise sentence that conveys the core purpose and capabilities without unnecessary words.
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?
For an 8-parameter tool with no output schema, the description is too brief. It lacks details on return format, pagination, or behavior with many parameters, leaving the agent underinformed.
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?
Schema coverage is 100%, so the description adds little beyond summarizing the params. It provides a high-level overview but no new semantic details beyond the schema's already thorough descriptions.
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 it queries Plausible analytics with full flexibility and explicitly calls it 'the main stats endpoint', distinguishing it from more specific sibling tools like get_breakdown or get_timeseries.
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 implies it is the go-to tool for flexible stats queries but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current number of real-time visitors on a site.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes | The site ID (domain) to query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It accurately identifies the operation as a read (getting current count). However, it omits details like whether the count is cached, latency, or authentication requirements. The behavioral disclosure is adequate but minimal.
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, clear sentence with no extraneous information. It is front-loaded and efficient.
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 has only one parameter, no output schema, and straightforward purpose, the description is nearly complete. It could be improved by specifying the return format (e.g., a number) but is sufficient for an AI agent.
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?
Schema description coverage is 100% for the single parameter site_id. The tool description does not add any additional meaning beyond the schema's description. Baseline of 3 is appropriate.
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 verb 'Get', the resource 'number of real-time visitors', and the scope 'on a site'. It distinguishes from sibling tools like query_stats or get_timeseries which are not specifically for real-time current count.
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?
No guidance is provided on when to use this tool versus alternatives such as query_stats for historical data or get_breakdown for segmented data. The description does not mention any prerequisites or context.
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.0get_breakdownget_custom_eventsget_device_statsget_entry_pagesget_exit_pagesget_goalsget_siteget_timeseriesget_utm_statslist_sitesquery_statsrealtime_visitorsMost tools have clearly distinct purposes (e.g., realtime_visitors, list_sites, get_utm_stats). However, query_stats is a flexible endpoint that could overlap with specialized tools like get_breakdown or get_timeseries, potentially causing confusion.
The majority use a get_* pattern, but query_stats and realtime_visitors deviate. The mix of verb-based and descriptive names is inconsistent but still readable.
12 tools cover the Plausible analytics domain well—neither too few nor too many. Each tool serves a distinct purpose without redundancy.
The tool set covers all major analytics dimensions (traffic, sources, pages, devices, goals, UTM). A minor gap is the lack of site CRUD, but this server focuses on querying, not management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Clamp Analytics MCP server: traffic, revenue, funnels, cohorts, errors, and search, for AI agents.
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/friendlygeorge/plausible-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
