Plausible Analytics를 위한 MCP 상호 작용 서버
Plausible Analytics API와 상호 작용하기 위한 모델 컨텍스트 프로토콜(MCP) 서버 구현입니다. 이 서버를 통해 AI 모델이 Plausible에서 분석 데이터를 쿼리할 수 있습니다.
이 클라이언트를 로컬로 실행하려면 Claude Desktop MCP Server 구성 파일에 다음 구성을 추가하세요.
지엑스피1
그런 다음, 다음과 같은 예제 프롬프트를 사용하여 Claude Desktop App에서 이 구현을 테스트할 수 있어야 합니다.
"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.
