Which integrations are available for this server?

Provides tools for querying a self-hosted Plausible Analytics instance, including aggregate stats, top pages, traffic breakdown by source/country/device, timeseries trends, site discovery, and health checks.

How do I use @icjia/plausible-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@icjia/plausible-mcp show me the traffic overview for the past 7 days" 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.

@icjia/plausible-mcp

by ICJIA

Overview Schema Related Servers Score Discussions

JavaScript

Local

@icjia/plausible-mcp

Lightweight MCP server that queries a self-hosted Plausible Analytics instance and returns compressed, actionable results optimized for Claude's context window.

Built for ICJIA's 15+ state agency web properties monitored under a single Plausible CE instance at plausible.icjia.cloud.

Features

6 tools — overview, pages, breakdown, timeseries, site discovery, health check
Compressed output — structured plain text, 10-300 tokens per query instead of raw JSON
Computed deltas — period-over-period comparison on every overview query
Filters — human-readable syntax: "page contains /grants", "source is Google"
Security-first — 12-layer security model including input validation, output sanitization, rate limiting, SSRF prevention, and prompt injection defense
90s response cache — reduces API load during iterative analysis
Zero build step — plain JavaScript ES modules, ships as-is to npm

Related MCP server: Umami MCP Server

Requirements

Node.js >= 22 (see .nvmrc)
A self-hosted Plausible CE instance (uses the v1 Stats API — compatible with all versions)
A Plausible API key with Stats API scope

Getting your Plausible API key

Log into your Plausible instance (e.g., https://plausible.icjia.cloud)
Go to Settings (your user settings, not site settings)
Scroll down to API Keys
Click + New API Key
Give it a name like "MCP Server"
Copy the key — you'll need it for configuration below

Your Plausible instance uses a single API key that covers all sites. There are no per-site keys.

Setup

Claude Code (terminal / CLI)

This is the easiest way to get started. Run this single command:

claude mcp add plausible-mcp -s user \
  -e PLAUSIBLE_BASE_URL=https://plausible.icjia.cloud \
  -e PLAUSIBLE_API_KEY=your-api-key-here \
  -e PLAUSIBLE_DEFAULT_SITE=icjia.illinois.gov \
  -- npx -y @icjia/plausible-mcp

Replace:

https://plausible.icjia.cloud with your Plausible instance URL
your-api-key-here with your actual API key
icjia.illinois.gov with your most-used site domain (optional but recommended)

To verify it worked:

claude mcp list

You should see plausible-mcp in the list. Then in a Claude Code session, ask:

"What's the status of my Plausible connection?"

Claude will call the get_status tool and confirm connectivity.

Claude Code (Desktop App / claude.ai/code)

If you're using the Claude Code desktop app or web app, add the server through Settings > MCP Servers or edit your Claude Code config file directly.

Config file location:

macOS: ~/.claude/settings.json
Windows: %USERPROFILE%\.claude\settings.json
Linux: ~/.claude/settings.json

Add this to your settings.json:

{
  "mcpServers": {
    "plausible-mcp": {
      "command": "npx",
      "args": ["-y", "@icjia/plausible-mcp"],
      "env": {
        "PLAUSIBLE_BASE_URL": "https://plausible.icjia.cloud",
        "PLAUSIBLE_API_KEY": "your-api-key-here",
        "PLAUSIBLE_DEFAULT_SITE": "icjia.illinois.gov"
      }
    }
  }
}

If you already have other MCP servers configured, add the "plausible-mcp" block inside the existing "mcpServers" object — don't create a second one.

Cursor

Open Cursor's MCP settings:

Open Cursor Settings (Cmd+Shift+P → "Cursor Settings" or Cursor > Settings > Cursor Settings)
Click MCP in the left sidebar
Click + Add new MCP server
Enter:
- Name: plausible-mcp
- Type: command
- Command: npx -y @icjia/plausible-mcp

Then add the environment variables. You can also edit the config file directly:

Config file location:

macOS: ~/.cursor/mcp.json
Windows: %USERPROFILE%\.cursor\mcp.json
Linux: ~/.cursor/mcp.json

{
  "mcpServers": {
    "plausible-mcp": {
      "command": "npx",
      "args": ["-y", "@icjia/plausible-mcp"],
      "env": {
        "PLAUSIBLE_BASE_URL": "https://plausible.icjia.cloud",
        "PLAUSIBLE_API_KEY": "your-api-key-here",
        "PLAUSIBLE_DEFAULT_SITE": "icjia.illinois.gov"
      }
    }
  }
}

VS Code (Copilot / Continue / other MCP clients)

Most VS Code MCP extensions use a .vscode/mcp.json file in your project root, or a global settings file.

Project-level — create .vscode/mcp.json:

{
  "servers": {
    "plausible-mcp": {
      "command": "npx",
      "args": ["-y", "@icjia/plausible-mcp"],
      "env": {
        "PLAUSIBLE_BASE_URL": "https://plausible.icjia.cloud",
        "PLAUSIBLE_API_KEY": "your-api-key-here",
        "PLAUSIBLE_DEFAULT_SITE": "icjia.illinois.gov"
      }
    }
  }
}

Windsurf

Windsurf uses a ~/.windsurf/mcp.json config file:

{
  "mcpServers": {
    "plausible-mcp": {
      "command": "npx",
      "args": ["-y", "@icjia/plausible-mcp"],
      "env": {
        "PLAUSIBLE_BASE_URL": "https://plausible.icjia.cloud",
        "PLAUSIBLE_API_KEY": "your-api-key-here",
        "PLAUSIBLE_DEFAULT_SITE": "icjia.illinois.gov"
      }
    }
  }
}

Any MCP-compatible client

The server uses stdio transport (standard input/output). Any MCP client that can spawn a process and communicate via JSON-RPC over stdio will work. The configuration is always the same:

Command: npx
Args: ["-y", "@icjia/plausible-mcp"]
Environment variables:

Variable	Required	Description
`PLAUSIBLE_BASE_URL`	Yes	Your Plausible instance URL (e.g., `https://plausible.icjia.cloud`)
`PLAUSIBLE_API_KEY`	Yes	Your Plausible Stats API key
`PLAUSIBLE_DEFAULT_SITE`	No	Default site domain so you don't have to specify it every query

Tools

Once configured, your AI assistant will have access to these 6 tools:

Tool	Purpose	Example question
`query_overview`	Aggregate stats with computed deltas	"How's icjia.illinois.gov doing?"
`query_pages`	Top or bottom pages by any metric	"What pages get the most traffic?"
`query_breakdown`	Traffic by source, country, device, etc.	"Where's our traffic coming from?"
`query_timeseries`	Trends over time	"Is traffic going up or down?"
`list_sites`	Discover all sites on the instance	"What sites are we tracking?"
`get_status`	Server version + connectivity check	"Is the Plausible connection working?"

Example output

icjia.illinois.gov [30d] Vis:12.4K(+8%) Sess:15.8K(+3%) PV:42.1K(-2%) Bounce:58.3%(+1.2pp) Dur:2m14s(+12%)

Filters

All query tools support a human-readable filter string:

"page contains /grants" — pages with /grants in the path
"source is Google" — traffic from Google only
"device is Mobile" — mobile visitors only
"country is US" — US visitors only
"page is_not /" — exclude the homepage
"source contains_not Direct" — exclude direct traffic

CLI

All tools are also available as standalone CLI commands (useful for scripting or testing):

# Set env vars first
export PLAUSIBLE_BASE_URL=https://plausible.icjia.cloud
export PLAUSIBLE_API_KEY=your-api-key-here

# Then run commands
npx @icjia/plausible-mcp overview icjia.illinois.gov
npx @icjia/plausible-mcp pages icjia.illinois.gov --sort asc --limit 5
npx @icjia/plausible-mcp breakdown icjia.illinois.gov --dimension visit:source
npx @icjia/plausible-mcp timeseries icjia.illinois.gov --period 6mo
npx @icjia/plausible-mcp list-sites
npx @icjia/plausible-mcp status

Running without a subcommand starts the MCP server (stdio mode).

Security

12-layer security model. See docs/doc-00-master-design.md for full details.

Input validation — allowlists and length caps on all parameters
Output sanitization — prompt injection prevention on all Plausible-sourced strings
Rate limiting — 600/hr, 3 concurrent, 15s timeout
Response safety — 5MB body cap, schema validation
Error sanitization — actionable messages, no key leakage
Base URL validation — SSRF prevention
Content-Type validation — catches DNS rebinding / proxy misconfiguration
Cache integrity — only validated responses cached
Static code constraints — no eval, no dynamic import
API key protection — masked everywhere, never in output
Dependency pinning — exact versions, lockfile committed
Transport isolation — stdio only, no open ports

Troubleshooting

"Authentication failed"

Your API key is wrong or missing. Double-check PLAUSIBLE_API_KEY.

"Endpoint not found (404)"

The API endpoint wasn't found. Verify PLAUSIBLE_BASE_URL is correct.

"Cannot connect to Plausible"

Check that PLAUSIBLE_BASE_URL is correct and the instance is running. Try opening the URL in a browser.

"Sites API not available (403)"

The list_sites tool requires the Sites API scope. Other tools will still work. You can list your sites manually.

Server not showing up in Claude Code

Run claude mcp list to verify registration. If missing, re-run the claude mcp add command.

Development

git clone https://github.com/ICJIA/plausible-mcp.git
cd plausible-mcp
nvm use
npm install
npm test

License

MIT - see LICENSE.

Available Tools

6 tools

get_statusA

Server info, version, and Plausible instance health check.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

Describes output (server info, version, health check). No annotations provided, but description sufficiently discloses read-only behavior.

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 waste, front-loading the purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless tool with no output schema, the description fully informs the agent of its purpose and return value.

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 in schema; description adds no param info, which is acceptable as schema coverage is 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?

Clearly states the tool returns server info, version, and Plausible instance health check. Distinguishes from sibling tools that focus on analytics queries.

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 for checking system status. No explicit when-not or alternatives, but appropriate for a status endpoint.

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

list_sitesA

Discover all sites tracked by the Plausible instance.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as pagination, rate limits, or whether the result is a list or array. The description is too sparse to inform the agent about side effects or 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler. Every word is necessary and front-loaded.

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?

For a list tool with no output schema, the description should mention what the response contains (e.g., site names, IDs) or any limitations (e.g., max results). It lacks completeness for effective agent decision-making.

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?

The tool has no parameters, and schema description coverage is 100% trivially. Baseline score for 0 parameters is 4, and the description adds no additional parameter info, which is acceptable.

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 uses a specific verb 'Discover' and clearly identifies the resource 'all sites' tracked by the Plausible instance. It distinguishes from sibling tools like query_breakdown or get_status, which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when you need to see all sites, but it does not provide 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.

query_breakdownA

Break down traffic by any dimension: source, country, device, browser, OS, UTMs, etc.

ParametersJSON Schema

Name	Required	Description	Default
`sort`	No	Sort order	desc
`limit`	No	Number of results (1-50)
`filter`	No	Filter string
`period`	No	Time period	30d
`siteId`	No	Plausible site domain
`metrics`	No	Metrics to return
`dateRange`	No	Required when period=custom
`dimension`	Yes	Dimension to break down by (e.g., visit:source, visit:country_name, visit:device)

TDQS

A3.5/5.0

Behavior2/5

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

No annotations provided; the description does not disclose what data is returned (e.g., aggregated metrics per dimension value), nor any behavioral details like authentication requirements or rate limits.

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?

A single sentence, clear and to the point, but it omits important behavioral details that could be included without becoming verbose.

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?

Given 8 parameters and no output schema, the description does not explain the structure of the response or how filters work, leaving the agent with incomplete guidance for correct usage.

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 coverage is 100%, so baseline is 3. The description adds no parameter-specific meaning beyond the schema's own descriptions.

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 breaks down traffic by any dimension (source, country, device, etc.), distinguishing it from sibling tools that focus on overviews, pages, or timeseries.

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?

The description implies use when a dimensional breakdown is needed, but it does not explicitly explain when to prefer this over alternatives like query_overview or query_pages.

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

query_overviewA

Aggregate stats for a site with period-over-period deltas. Answers "How is this site doing?"

ParametersJSON Schema

Name	Required	Description	Default
`filter`	No	Filter string, e.g. "page contains /grants", "source is Google"
`period`	No	Time period: day, 7d, 30d, month, 6mo, 12mo, all, custom	30d
`siteId`	No	Plausible site domain (defaults to PLAUSIBLE_DEFAULT_SITE env var)
`metrics`	No	Metrics to return
`dateRange`	No	Required when period=custom: "YYYY-MM-DD,YYYY-MM-DD"

TDQS

A3.7/5.0

Behavior3/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 discloses that the tool computes period-over-period deltas, which is a key behavioral trait. However, it does not mention whether it's read-only, any side effects, or response format expectations.

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?

The description is two concise sentences, front-loaded with the core functionality. 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.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters and no output schema, the description could be more complete. It doesn't hint at the return structure or clarify which siblings to prefer in specific scenarios. However, for a relatively straightforward aggregation tool, it is minimally adequate.

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 coverage is 100%, so baseline is 3. The description adds no additional meaning beyond what the input schema already provides (e.g., filter, period, metrics). It does not compensate with extra context for any parameters.

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 aggregates stats for a site with period-over-period deltas, answering 'How is this site doing?'. The verb 'aggregate' and resource 'stats for a site' are specific, and it distinguishes from siblings like query_breakdown (breakdown by dimension) or query_timeseries (raw time series).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for high-level site performance overview, but does not explicitly state when to use this tool versus alternatives like query_timeseries or query_pages. No when-not or alternatives are mentioned.

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

query_pagesA

Top or bottom pages by traffic. Answers "What pages are popular?" or "What pages get no traffic?"

ParametersJSON Schema

Name	Required	Description	Default
`sort`	No	desc=most popular, asc=least popular	desc
`limit`	No	Number of results (1-50)
`filter`	No	Filter string, e.g. "page contains /grants"
`period`	No	Time period	30d
`siteId`	No	Plausible site domain
`metrics`	No	Metrics to return
`dateRange`	No	Required when period=custom

TDQS

A3.6/5.0

Behavior2/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 does not disclose read-only nature, error conditions, rate limits, or any side effects, relying solely on parameter schema for behavioral cues.

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?

Two sentences, front-loaded with purpose, no wasted words. Every sentence earns its place.

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?

Given 7 parameters, no output schema, and no annotations, the description is too sparse. It omits return format, error handling, prerequisites (e.g., siteId), and relationship between period and dateRange.

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 baseline is 3. The description does not add parameter meaning beyond what the schema already provides, which is adequate.

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 the action (query pages by traffic) and resource (pages), and explicitly answers two common questions, distinguishing it from siblings like query_timeseries or query_overview.

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 clear use cases ('What pages are popular?' or 'What pages get no traffic?'), implying when to use it, but lacks explicit exclusions or comparisons to sibling tools.

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

query_timeseriesC

Trend data over time. Answers "Is traffic going up or down?"

ParametersJSON Schema

Name	Required	Description	Default
`filter`	No	Filter string
`period`	No	Time period	6mo
`siteId`	No	Plausible site domain
`metrics`	No	Metrics to return
`interval`	No	Granularity: day, week, month	month
`dateRange`	No	Required when period=custom

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations provided, the description must disclose behavioral traits. It fails to mention data freshness, pagination, limitations, or security aspects. The minimal description does not compensate for the lack of annotations.

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?

The description is very short and to the point, with no unnecessary words. However, the extreme brevity sacrifices informativeness, but it is not verbose.

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?

Given the tool has 6 parameters, no output schema, and no annotations, the description is insufficient. It does not explain the return format, how to interpret the time series data, or address edge cases like empty periods or missing metrics.

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 coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions (e.g., filter, period, metrics). It does not explain how parameters interact, such as the custom period requiring dateRange.

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

Purpose3/5

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

The description states the tool provides trend data over time and addresses traffic direction, which gives a general purpose. However, it lacks specificity about the type of data (website analytics) and does not differentiate from sibling tools like query_overview or query_breakdown.

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 is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or specific scenarios where query_timeseries is preferred.

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

A3.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: server info, site listing, dimension breakdown, aggregate stats, page rankings, and time trends. No overlap.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (get_status, list_sites, query_breakdown, etc.), making the API predictable.

Tool Count5/5

Six tools is appropriate for a Plausible analytics client, covering all essential read operations without excess.

Completeness5/5

The tool surface covers server health, site listing, and all major query types (dimension breakdown, overview with deltas, pages, timeseries). No obvious gaps for a read-only analytics tool.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

plausible-analytics A
io.usefulapi
Query site stats, realtime visitors, breakdowns and goals from Plausible Analytics.
Monitoring Marketing
81
Measure.events Analytics A
io.github.meetclawdius
Privacy-first web analytics. Query pageviews, referrers, trends, and AI insights.
Monitoring Search Data Platforms
622
Chad Analytics
com.chadanalytics
Read-only website analytics, AI referrals, crawlers, goals, revenue, and funnels.
Monitoring Marketing
2
Nexly Analytics
to.nexly
Read-only access to your Nexly web analytics: traffic, pages, acquisition, events, and reports.
Monitoring Observability
2

Related MCP Servers

Plausible MCP Server
Monitoring Search
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.
Updated a year ago (2025-03-19 12:51 UTC)
1
8
Umami MCP Server
Monitoring Search Web Scraping
lukasschmit
A
license
A
quality
F
maintenance
Enables AI assistants to interact with Umami Analytics for both Cloud and self-hosted instances. It provides tools to retrieve website statistics, visitor metrics, pageview trends, and real-time active user counts.
Updated 6 months ago (2026-02-21 03:32 UTC)
5
1
MIT
Plausible Analytics MCP Server
Monitoring Search
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.
Updated 6 months ago (2026-03-08 03:00 UTC)
6
33
1
MIT
plausible-mcp
Monitoring Observability
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.
Updated 7 months ago (2026-02-09 04:01 UTC)
6

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/ICJIA/plausible-mcp'

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