Skip to main content
Glama
eneskoruzh
colintoh

Clicky MCP Server

by colintoh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Clicky MCP Server

A Model Context Protocol (MCP) server that exposes Clicky web analytics as 12 tools for AI assistants — visitor counts, top pages, traffic sources, campaigns, bounce rate, search terms, real-time visitors, and more. See the Tool reference for the full list.

Quick start

You need:

  • Node.js 20+ installed (node --version)

  • A Clicky Site ID and Site Key — find both at https://clicky.com/user/preferences/site under "Info" (you'll paste these into a local .env file, never into the chat)

  • An MCP-capable AI agent — Claude Code, Claude Desktop, Codex, opencode, Cursor, Cline, …

MCP servers are installed by your agent, not started by hand — so the fastest setup is to hand the job over. Copy the block below and paste it to your agent:

Install the Clicky MCP server for me. It's a stdio MCP server, so the same definition works in any MCP host (Claude Code, Claude Desktop, Codex, opencode, Cursor, Cline, …) — register it using your host's own mechanism; only the config format differs, and you know your host better than this doc does.

1. Clone and build:
     git clone https://github.com/colintoh/clicky-mcp.git
     cd clicky-mcp && npm install && npm run build
   Confirm the build produced dist/index.js. If it's missing, stop and show me
   the build output instead of continuing.

2. Set up credentials WITHOUT putting them in this chat:
     cp .env.example .env
   Then tell me to open clicky-mcp/.env in my editor and paste my Clicky Site ID
   and Site Key there myself (from https://clicky.com/user/preferences/site,
   under "Info"). Do NOT ask me to paste the keys here, and do NOT read or print
   .env — the server loads it at startup; the keys must never enter this chat.

3. Register it with this stdio server definition (no credentials in the host
   config — the server reads them from .env):
     command:   absolute path to node — run `which node`; a bare "node" or a
                relative path will fail
     args:      ["<absolute-path>/clicky-mcp/dist/index.js"]
     transport: stdio
   Add it with your host's own mechanism. One-line references if helpful:
     - Claude Code: `claude mcp add clicky-analytics -- <node> <path>/clicky-mcp/dist/index.js`
     - JSON hosts (Claude Desktop, Cursor, Cline, …): a "clicky-analytics"
       entry under "mcpServers" with command + args (no env block needed)
     - Codex (~/.codex/config.toml): [mcp_servers.clicky-analytics] with the
       same command + args
   If the host needs a restart to load new servers (Claude Desktop needs a full
   Cmd-Q quit, not just closing the window), tell me to do that.

4. Verify: confirm your host lists a "clicky-analytics" server exposing 12 tools.

Why no npm start? MCP stdio servers aren't standalone daemons — your agent's MCP host spawns the server as a subprocess on demand and talks to it over stdin/stdout. There's nothing to "start" yourself, which is also why setup is "tell your agent" rather than "run a command."

Related MCP server: Plausible MCP Server

Date parameters

Every date-aware tool accepts either an explicit date range or a Clicky relative-date keyword — but not both:

  • Explicit: start_date + end_date, both YYYY-MM-DD, range ≤ 31 days.

  • Keyword: date_range, one of today, yesterday, last-7-days, last-30-days, this-week, last-week, this-month, last-month, this-year, last-year.

Example:

{ "date_range": "last-7-days" }

Tool reference

All 12 tools, alphabetical-ish by use case.

get_total_visitors

Total visitor counts for a period.

  • start_date / end_date or date_range

get_actions

Total pageviews/actions for a period.

  • start_date / end_date or date_range

  • limit (number, optional, max 1000)

get_bounce_rate

Bounce rate and average time-on-site for a period.

  • start_date / end_date or date_range

get_visitors_online

Real-time visitor count and segmentation. Takes no parameters.

get_top_pages

Most popular pages for a period.

  • start_date / end_date or date_range

  • limit (number, optional, max 1000)

get_page_traffic

Traffic data for a specific page URL.

  • url (string, required)

  • start_date / end_date or date_range

get_traffic_sources

Traffic sources breakdown — optionally filter by page URL.

  • start_date / end_date or date_range

  • page_url (string, optional) — full URL or path

get_referring_domains

Top referring domains sending traffic.

  • start_date / end_date or date_range

  • limit (number, optional, max 1000)

get_campaigns

Traffic grouped by campaign tag (utm_campaign or Clicky campaign tracking). Only tagged inbound traffic appears here — untagged organic/direct traffic does not.

  • start_date / end_date or date_range

  • limit (number, optional, max 1000)

  • include_keywords (boolean, optional) — also return campaign keyword/term tags

get_domain_visitors

Visitor data filtered by referrer domain, with optional segmentation.

  • domain (string, required)

  • start_date / end_date or date_range

  • segments (array, optional) — ["pages", "visitors"]. Defaults to ["visitors"].

  • limit (number, optional, max 1000)

get_searches

Top search terms that brought visitors.

  • start_date / end_date or date_range

  • limit (number, optional, max 1000)

get_countries

Visitor breakdown by country.

  • start_date / end_date or date_range

  • limit (number, optional, max 1000)

API limits

Imposed by Clicky, not by this server:

  • Maximum explicit date range: 31 days

  • Maximum results per request: 1,000 items

  • One simultaneous request per IP per site ID

Troubleshooting

"Claude Desktop doesn't see the server." Check the spawn log at ~/Library/Logs/Claude/mcp-server-clicky-analytics.log. The most common cause is node not being on Claude Desktop's launchd PATH — fix by replacing "command": "node" with the absolute path from which node. The second-most-common cause is forgetting to fully quit Claude Desktop (⌘Q, not just close the window).

"Date range cannot exceed 31 days." That's a Clicky API limit, not us. Either narrow the range or use a date_range keyword like last-30-days.

Local development

For working on the server, not just using it.

npm install         # install deps
npm run dev         # run with tsx, watching for changes (used for local testing only)
npm run build       # compile TS to dist/
npm test            # 46 unit tests, offline, no credentials needed
npm run test:integration  # live API smoke test (requires .env or env vars)

Credentials come from a .env file in the project root — copy the template and fill in your values:

cp .env.example .env
CLICKY_SITE_ID=your_site_id
CLICKY_SITE_KEY=your_site_key

.env is gitignored, and it's the recommended way to supply credentials for both local dev and MCP hosts: it keeps your keys out of host config files and out of any agent chat. The server resolves .env relative to its own location, so it's found no matter what working directory the host launches it from, and it only loads .env when the credentials aren't already in the environment. You can still pass CLICKY_SITE_ID/CLICKY_SITE_KEY via the host's env block or --site-id/--site-key args if you prefer.

A pre-push git hook in .githooks/pre-push auto-runs npm test before any push that updates the remote main branch, so a regression can't slip out unnoticed. It's installed automatically by the prepare npm script after npm install. Pushes to feature branches are not gated. Bypass in an emergency with git push --no-verify.

Project structure

clicky-mcp/
├── src/
│   ├── index.ts              # MCP server + tool dispatcher
│   ├── clicky-client.ts      # Clicky HTTP API client
│   ├── date-utils.ts         # Shared date param builder
│   └── tools/                # One file per tool
├── test/                     # node:test unit tests
├── scripts/verify.mjs        # Live API smoke runner
├── .githooks/pre-push        # Auto-installed test gate for main
├── package.json
├── tsconfig.json
└── README.md

License

MIT

Available Tools

5 tools
get_domain_visitorsC

Get visitors filtered by domain from Clicky analytics with optional segmentation data

ParametersJSON Schema
NameRequiredDescriptionDefault
domainYesDomain name to filter by (e.g., "facebook.com", "google.com")
start_dateYesStart date in YYYY-MM-DD format
end_dateYesEnd date in YYYY-MM-DD format
segmentsNoOptional array of segments to include (pages, visitors). Defaults to visitors only. "visitors" gets the total number of visitors from the domain. "pages" get the list of pages and its visited count from the domain.
limitNoOptional limit for results (max 1000)

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but only states it 'gets' data, implying a read-only operation without confirming safety or permissions. It mentions optional segmentation but doesn't disclose behavioral traits like rate limits, authentication needs, or what happens if parameters are invalid. This leaves significant gaps for a tool with 5 parameters.

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, efficient sentence that front-loads the core purpose ('Get visitors filtered by domain') and adds a useful detail ('with optional segmentation data'). There is zero waste, and every word 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 no annotations and no output schema, the description is incomplete for a tool with 5 parameters. It doesn't explain return values, error conditions, or behavioral constraints like rate limits or authentication requirements. For a data retrieval tool in analytics, more context is needed to use it effectively.

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 the schema fully documents all 5 parameters. The description adds minimal value beyond the schema by mentioning 'optional segmentation data', which loosely relates to the 'segments' parameter but doesn't provide additional meaning or context. Baseline 3 is appropriate as the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the verb ('Get') and resource ('visitors filtered by domain from Clicky analytics'), specifying the filtering mechanism. It distinguishes from siblings like 'get_total_visitors' by mentioning domain filtering, but doesn't explicitly contrast with 'get_traffic_sources' or 'get_page_traffic' which might also involve visitor data.

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 on when to use this tool versus alternatives like 'get_total_visitors' or 'get_traffic_sources' is provided. The description mentions optional segmentation data but doesn't clarify when segmentation is beneficial or when other tools might be more appropriate.

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

get_page_trafficC

Get traffic data for a specific page by filtering with its URL

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesFull URL or path of the page to get traffic for (e.g., https://example.com/path or /path)
start_dateYesStart date in YYYY-MM-DD format
end_dateYesEnd date in YYYY-MM-DD format

TDQS

C2.9/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 of behavioral disclosure. It states the tool retrieves traffic data but doesn't mention any behavioral traits such as rate limits, authentication requirements, data freshness, or what the output format looks like (e.g., metrics like pageviews, sessions). This is a significant gap for a tool with no annotation coverage.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and every part earns its place, making it easy to parse quickly.

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 complexity of a traffic data tool with no annotations and no output schema, the description is incomplete. It lacks details on what traffic data is returned (e.g., metrics, format), behavioral aspects like permissions or limits, and differentiation from sibling tools, leaving the agent with insufficient context for effective use.

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?

The description adds minimal value beyond the input schema, which has 100% coverage with clear descriptions for all three parameters (url, start_date, end_date). It implies URL-based filtering but doesn't provide additional context like URL format constraints or date range implications. Baseline 3 is appropriate as the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('traffic data for a specific page'), and it specifies the filtering mechanism ('by filtering with its URL'). However, it doesn't explicitly differentiate this tool from its siblings like 'get_top_pages' or 'get_total_visitors', which likely provide different scopes or aggregations of traffic data.

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?

The description provides no guidance on when to use this tool versus its siblings (e.g., 'get_domain_visitors', 'get_top_pages', 'get_total_visitors', 'get_traffic_sources'). It mentions filtering by URL but doesn't explain alternative scenarios or exclusions, leaving the agent to infer usage from tool names alone.

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

get_top_pagesC

Get top pages for a date range from Clicky analytics

ParametersJSON Schema
NameRequiredDescriptionDefault
start_dateYesStart date in YYYY-MM-DD format
end_dateYesEnd date in YYYY-MM-DD format
limitNoMaximum number of pages to return (default: API default, max: 1000)

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions retrieving 'top pages' but doesn't specify what 'top' means (e.g., by views, visits, or other metrics), how results are ordered, if there's pagination, rate limits, authentication needs, or error handling. This leaves significant gaps in understanding the tool's behavior beyond basic functionality.

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, efficient sentence that directly states the tool's purpose without unnecessary words or fluff. It's front-loaded with the core action and resource, making it easy to parse quickly, which is ideal for conciseness in tool definitions.

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 lack of annotations and output schema, and the description's minimal detail, it's incomplete for a tool that likely returns complex analytics data. It doesn't explain what 'top pages' entails, the structure of the output, or behavioral aspects like data freshness or limitations, leaving the agent with insufficient context to use the tool effectively beyond basic parameter input.

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%, with clear documentation for each parameter (start_date, end_date, limit) including formats, constraints, and defaults. The description adds no additional semantic details beyond implying date-range usage, so it meets the baseline of 3 where the schema handles most of the parameter explanation without extra value from the description.

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

Purpose4/5

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

The description clearly states the action ('Get') and resource ('top pages') with the source ('from Clicky analytics') and scope ('for a date range'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_page_traffic' or 'get_total_visitors', which might also involve date ranges or page-related data, leaving some ambiguity about uniqueness.

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?

The description provides no guidance on when to use this tool versus alternatives like 'get_page_traffic' or 'get_traffic_sources', nor does it mention any prerequisites, exclusions, or specific contexts. It only states what the tool does, without indicating appropriate scenarios or comparisons with siblings.

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

get_total_visitorsC

Get total visitors for a date range from Clicky analytics

ParametersJSON Schema
NameRequiredDescriptionDefault
start_dateYesStart date in YYYY-MM-DD format
end_dateYesEnd date in YYYY-MM-DD format

TDQS

C2.9/5.0
Behavior2/5

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 states what the tool does but doesn't describe how it behaves: no information about authentication requirements, rate limits, error handling, or what the return value looks like (e.g., is it a single number, a structured object?). For a data retrieval tool with zero annotation coverage, this leaves significant gaps in understanding operational 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?

The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the essential information ('Get total visitors'). Every word 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 the lack of annotations and output schema, the description is incomplete for effective tool use. While the purpose is clear, it doesn't address key contextual elements: what format the result returns, whether authentication is needed, any rate limits, or how it differs from sibling tools. For a data retrieval tool in an analytics context, more operational context would be helpful.

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 the input schema fully documents both parameters (start_date and end_date) with format patterns. The description adds no additional parameter semantics beyond implying date-range filtering. This meets the baseline expectation when schema does the heavy lifting, but doesn't provide extra context like date range constraints or timezone handling.

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

Purpose4/5

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

The description clearly states the verb ('Get') and resource ('total visitors'), and specifies the data source ('from Clicky analytics'). It distinguishes itself from siblings by focusing on total visitor counts rather than domain-specific, page-level, or source-level metrics. However, it doesn't explicitly contrast with sibling tools like 'get_domain_visitors' which might also provide visitor counts.

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?

The description provides no guidance on when to use this tool versus alternatives like 'get_domain_visitors' or 'get_traffic_sources'. It doesn't mention prerequisites, limitations, or specific use cases. The agent must infer usage from the tool name alone, which is insufficient for optimal tool selection.

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

get_traffic_sourcesB

Get traffic sources breakdown from Clicky analytics. Optionally filter by specific page URL.

ParametersJSON Schema
NameRequiredDescriptionDefault
start_dateYesStart date in YYYY-MM-DD format
end_dateYesEnd date in YYYY-MM-DD format
page_urlNoOptional: Full URL or path of the page to get traffic sources for (e.g., https://example.com/path or /path)

TDQS

B3.3/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 of behavioral disclosure. It mentions an optional filter but does not describe the return format, pagination, rate limits, authentication needs, or whether this is a read-only operation. For a tool with no annotations, this leaves significant gaps in understanding its 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?

The description is a single, efficient sentence that front-loads the main purpose and includes the optional filter. There is no wasted language, and it is appropriately sized for the tool's complexity.

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 no annotations and no output schema, the description is incomplete for a tool with three parameters. It covers the basic purpose and optional filtering but lacks details on return values, error handling, or behavioral traits. This is adequate as a minimum but has clear gaps in providing a full context for the agent.

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 the schema already documents all parameters (start_date, end_date, page_url) with descriptions and formats. The description adds marginal value by mentioning the optional filter by page URL, but does not provide additional semantics beyond what the schema specifies, such as examples or constraints.

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

Purpose4/5

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

The description clearly states the verb ('Get') and resource ('traffic sources breakdown from Clicky analytics'), making the purpose evident. It distinguishes from siblings by focusing on traffic sources rather than visitors, page traffic, or top pages. However, it doesn't explicitly contrast with sibling tools like 'get_domain_visitors' or 'get_page_traffic' beyond the resource type.

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 through the optional filter by page URL, suggesting it can be used for overall traffic sources or per-page analysis. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_page_traffic' or 'get_domain_visitors', and does not mention prerequisites or exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updates
    • First observedget_domain_visitors
    • First observedget_page_traffic
    • First observedget_top_pages
    • First observedget_total_visitors
    • First observedget_traffic_sources
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose targeting different analytics dimensions: domain visitors, page traffic, top pages, total visitors, and traffic sources. There is no overlap in functionality, making it easy for an agent to select the correct tool without confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with 'get_' prefix and descriptive nouns (e.g., get_domain_visitors, get_page_traffic). This uniformity enhances readability and predictability across the toolset.

Tool Count5/5

With 5 tools, the server is well-scoped for analytics retrieval, covering key metrics like visitors, pages, and traffic sources. Each tool earns its place without being overly sparse or bloated, fitting typical use cases effectively.

Completeness4/5

The toolset provides comprehensive read-only coverage for analytics data, including filtering and segmentation options. A minor gap exists in lacking write or configuration tools (e.g., setting up analytics), but this is reasonable for a data retrieval-focused server, and agents can work around this limitation.

Maintenance

ActivityInactive
ResponsivenessSlow

Resources

Related MCP Connectors

Related MCP Servers

  • Umami Analytics MCP Server

    jakeyShakey
    A
    license
    Not graded
    quality
    D
    maintenance
    Enhances Claude's capabilities by providing access to website analytics data from Umami, enabling analysis of user behavior, website performance tracking, and data-driven insights generation.
    9
    MIT

  • Plausible MCP Server

    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.
    1
    8
    -

  • Umami MCP Server

    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.
    5
    1
    MIT

  • plausible-mcp

    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.
    6
    -

Appeared in Searches