用于合理分析的 MCP 交互服务器
用于与 Plausible Analytics API 交互的模型上下文协议 (MCP) 服务器实现。该服务器允许 AI 模型从 Plausible 查询分析数据。
为了在本地运行此客户端，请将以下配置添加到您的 Claude Desktop MCP Server 配置文件中：
{
"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"
}
},
}
}在此之后，您应该能够使用以下示例提示在 Claude 桌面应用程序中测试此实现：
“您能提供我对 avimbu.com 的每日分析概览吗？”
“您能从我的 Plausible 帐户为域名 avimbu.com 生成相关的分析报告吗？”
在本地运行服务器：
node dist/index.js在另一个终端中构建
npm run watchRelated MCP server: plausible-mcp
如果您有任何疑问，请随时通过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.
v1.0.0plausible_queryScored across 1 tool
With 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.
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.
Privacy-first, cookie-free web analytics. Read stats and manage sites from your AI.
