How do I use Measure.events MCP Server?

1. Click on "Deploy 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., "@Measure.events MCP Server What's my traffic looking like this week?" 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.

Measure.events MCP Server

by Le-Circus

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

Measure.events MCP Server

MCP License: MIT

A Model Context Protocol (MCP) server for Measure.events — privacy-first web analytics that AI agents can use natively.

Connect your AI coding assistant (Claude Desktop, Cursor, Windsurf, etc.) to your web analytics. Ask questions like "how's my traffic this week?" or "what are my top pages?" and get real answers from real data.

Why?

Every analytics platform has a dashboard. None of them talk to your AI tools.

Measure.events is the first analytics platform with a native MCP server. Your AI assistant can check traffic, find top content, identify referrers, and track events — all without you opening a browser.

Related MCP server: Google Analytics MCP Server

Tools

Tool	Description
`list_sites`	List all tracked sites in your account
`get_pageviews`	Pageview counts with daily time series
`get_top_pages`	Most viewed pages on a site
`get_referrers`	Traffic sources and referring domains
`get_site_summary`	AI-friendly natural language analytics summary
`track_event`	Track custom events (signups, purchases, etc.)

Setup

1. Get your API key

2. Install

npm install @turbo-puffin/measure-mcp-server

Or run directly with npx:

npx @turbo-puffin/measure-mcp-server

3. Configure your MCP client

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "measure": {
      "command": "npx",
      "args": ["-y", "@turbo-puffin/measure-mcp-server"],
      "env": {
        "MEASURE_API_KEY": "your_api_key_here"
      }
    }
  }
}

Cursor

Add to your Cursor MCP settings:

{
  "mcpServers": {
    "measure": {
      "command": "npx",
      "args": ["-y", "@turbo-puffin/measure-mcp-server"],
      "env": {
        "MEASURE_API_KEY": "your_api_key_here"
      }
    }
  }
}

Windsurf

Add to your Windsurf MCP configuration:

{
  "mcpServers": {
    "measure": {
      "command": "npx",
      "args": ["-y", "@turbo-puffin/measure-mcp-server"],
      "env": {
        "MEASURE_API_KEY": "your_api_key_here"
      }
    }
  }
}

Environment Variables

Variable	Required	Description
`MEASURE_API_KEY`	Yes	Your Measure.events API key
`MEASURE_API_URL`	No	Custom API base URL (default: `https://lets.measure.events/api/v1`)

Example Usage

Once configured, ask your AI assistant:

"What's my traffic looking like this week?"
"Which pages are getting the most views on propfirmdeck.com?"
"Where is my traffic coming from?"
"Give me a summary of my analytics"
"Track a signup event for my site"

Hosted MCP Endpoint

Measure.events also provides a hosted MCP endpoint for server-to-server integration:

POST https://lets.measure.events/mcp
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{"jsonrpc": "2.0", "method": "initialize", "id": 1, "params": {"protocolVersion": "2024-11-05", "capabilities": {}, "clientInfo": {"name": "test", "version": "1.0"}}}

About Measure.events

Measure.events is privacy-first web analytics built for the AI era. No cookies, no personal data, GDPR/CCPA compliant out of the box. The only analytics platform where AI agents are first-class citizens.

🔒 Privacy-first — no cookies, no fingerprinting
🤖 Agent-native — MCP server + REST API
⚡ Lightweight — single script tag, <1KB
📊 Real-time — see traffic as it happens

License

MIT — see LICENSE for details.

Available Tools

6 tools

get_pageviewsAInspect

Get pageview counts for a site over a time period. Returns total pageviews and a daily time series.

ParametersJSON Schema

Name	Required	Description	Default
`site_id`	Yes	Site ID (get from list_sites)
`period`	No	Time period: 'day', '7d', '30d', or '90d'	7d

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided. Description only mentions output behavior; lacks details on data freshness, authorization, rate limits, or whether today's partial data is included.

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, front-loaded with essential information, no unnecessary words.

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

Completeness4/5

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

Adequately covers what the tool does and returns for a simple 2-parameter query with no output schema, though missing sibling differentiation and behavioral details.

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?

Input schema provides 100% coverage with descriptions for both parameters (site_id and period). Description adds no additional value beyond the schema, so baseline score of 3 applies.

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 verb 'get', resource 'pageview counts', scope 'for a site over a time period', and specifies output 'total pageviews and a daily time series', distinguishing it from sibling tools like get_referrers and get_top_pages.

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?

No explicit guidance on when to use this tool vs. siblings such as get_top_pages or get_site_summary. Usage is implied by the description but not explicitly clarified.

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

get_referrersBInspect

Get traffic sources (referrers) for a site. Shows where visitors are coming from.

ParametersJSON Schema

Name	Required	Description	Default
`site_id`	Yes	Site ID (get from list_sites)
`period`	No	Time period: 'day', '7d', '30d', or '90d'	7d

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral traits. It only states a read operation implicitly, but fails to disclose any potential side effects, authentication needs, rate limits, or response characteristics.

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 clear, concise sentences with no redundant information. Every word contributes to understanding the tool's purpose.

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 output schema, the description should hint at the return format (e.g., list of referrers with counts). It does not, but the tool is simple enough that the minimal description is 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 description coverage is 100%, so the baseline is 3. The description adds no extra parameter meaning beyond the schema's own descriptions of site_id and period.

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 retrieves traffic sources (referrers) for a site, using specific verbs and resources. It distinguishes itself from sibling tools like get_pageviews and get_top_pages by targeting referrers specifically.

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 prerequisites, exclusions, or context for selection among sibling tools.

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

get_site_summaryAInspect

Get a natural-language summary of a site's analytics. AI-friendly overview of traffic trends, top content, and referrers.

ParametersJSON Schema

Name	Required	Description	Default
`site_id`	Yes	Site ID (get from list_sites)

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 must convey behavioral traits. It states it returns a natural-language summary, but does not disclose whether the tool is read-only, requires any permissions, or has performance implications. The absence of destructive hint or read-only annotation makes the lack of clarity more significant.

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 concise with two sentences, front-loading the purpose and briefly mentioning what the summary includes. Every sentence adds value; no filler.

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

Completeness4/5

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

For a simple one-parameter tool, the description covers the main purpose and output nature (natural-language summary). However, with no output schema, mentioning the output format more explicitly (e.g., 'returns a text string') would improve completeness. Still, it is largely 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% (one parameter described). The description adds no additional meaning beyond the schema, which already explains that site_id is required and should be obtained from list_sites. Baseline 3 is appropriate.

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 it gets a natural-language summary of a site's analytics, covering traffic trends, top content, and referrers. This distinguishes it from sibling tools that provide raw data (e.g., get_pageviews, get_referrers) by offering a synthesized overview.

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 use when an AI-friendly overview is needed, but does not explicitly state when to use this tool over alternatives like get_pageviews or get_top_pages. No when-not guidance or alternative suggestions are provided.

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

get_top_pagesBInspect

Get the most viewed pages on a site. Shows which content is performing best.

ParametersJSON Schema

Name	Required	Description	Default
`site_id`	Yes	Site ID (get from list_sites)
`period`	No	Time period: 'day', '7d', '30d', or '90d'	7d

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits, but it only states the basic function. It fails to mention important details like data freshness, sorting order, pagination, or whether results are based on unique visitors.

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 concise sentences with no unnecessary words. The description is front-loaded and gets straight to the point.

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?

The description is minimal for a simple tool with two parameters and no output schema. While it covers the core purpose, it lacks details about expected response format or edge cases, making it adequate but not comprehensive.

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 description adds limited value. It only provides a general statement about 'performing best' without elaborating on how parameters affect results. Baseline of 3 is appropriate.

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 'Get' and resource 'most viewed pages on a site', clearly indicating the tool's function. It also explains the purpose 'Shows which content is performing best', which distinguishes it from sibling tools like get_pageviews.

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 such as get_pageviews or get_referrers. The description does not mention context or exclusions, leaving the agent to infer usage from the name alone.

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

list_sitesAInspect

List all sites tracked in your Measure.events account. Returns site IDs, domains, and tracking keys.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states that the tool returns site IDs, domains, and tracking keys, but does not mention any important traits such as authorization requirements, rate limits, pagination, or whether the list is exhaustive. Basic information is present, but not enough for full transparency.

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 concise with two sentences, front-loading the verb and resource. It avoids unnecessary detail while still providing key return fields. However, it could be slightly more structured by separating the purpose from the returns.

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

Completeness4/5

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

The tool is simple (0 parameters, no output schema, no nested objects). The description is sufficient for its low complexity, clearly stating what and where it lists. It could be improved by specifying if all sites are returned or if there are any limitations.

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 input schema has zero parameters and 100% schema description coverage, so the baseline is 4. The description does not need to explain parameters since there are none, and it correctly focuses on what the tool returns.

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 the specific verb 'list' combined with the resource 'sites' and includes the scope 'in your Measure.events account'. It clearly explains what the tool does and distinguishes it from siblings like get_pageviews, which focus on specific metrics rather than a general list.

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 when to use the tool (to list all sites), but it does not explicitly state when not to use it or mention alternative tools. Given the sibling tools have different purposes, the usage is clear enough, but lacks explicit exclusions or context.

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

track_eventAInspect

Track a custom event on a site. Use for conversions, signups, button clicks, or any custom metric.

ParametersJSON Schema

Name	Required	Description
`site_key`	Yes	Site tracking key (get from list_sites)
`name`	Yes	Event name (e.g., 'signup', 'purchase', 'download')
`url`	No	Page URL where the event occurred
`metadata`	No	Optional key-value metadata for the event

TDQS

A3.9/5.0

Behavior2/5

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

No annotations are provided, and the description lacks behavioral details such as idempotency, rate limits, authentication requirements, or what happens on duplicate events. For a mutation tool, this is a significant gap.

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, clear sentence that is front-loaded with the key action and purpose. No unnecessary words.

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?

Adequate for a simple event tracking tool, but lacks details on return values, error handling, or limitations. Since there is no output schema, the description should hint at what to expect after a successful track.

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?

Schema coverage is 100%, but the description adds value by providing examples for the name parameter (e.g., 'signup', 'purchase') and advising to get site_key from list_sites, which aids correct usage.

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 tracks custom events on a site with specific examples (conversions, signups, button clicks). This distinguishes it from sibling read-only tools like get_pageviews.

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 (conversions, signups, etc.) but does not explicitly exclude scenarios or compare to alternatives. Since siblings are all read-only, this is the only write tool, so context is sufficient.

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.

6 tool updatesv1.0.0Jun 10, 2026
- First observedget_pageviews
- First observedget_referrers
- First observedget_site_summary
- First observedget_top_pages
- First observedlist_sites
- First observedtrack_event

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.9/5.0

Scored 2026-06-10 07:40 across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: pageviews, referrers, summary, top pages, site listing, and event tracking. No overlap in functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with 'get_' for data retrieval and 'track_' for event recording. No mixing of conventions.

Tool Count5/5

6 tools is well-scoped for an analytics server. Each tool earns its place, covering core analytics operations without bloat.

Completeness4/5

Covers essential analytics: pageviews, referrers, top pages, site summary, site listing, and event tracking. Missing retrieval of custom events but still sufficient for most tasks.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Betterlytics
io.betterlytics
Query your Betterlytics web analytics from AI agents: traffic, funnels, journeys, errors, uptime.
Monitoring Observability
1170
Flowsery AOAuth
com.flowsery
Privacy-first web analytics for AI agents: visitors, revenue, funnels, visitor profiles.
Customer Data Platforms Data Visualization
271
Google Analytics (unofficial)A
com.safe-mcp
Connect Google Analytics to ChatGPT. Query GA4 data in plain English and get instant insights.
Search Marketing Monitoring
52
analytics
com.zenovay
Real-time web analytics for AI agents: query traffic, funnels, revenue, and manage your sites.
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
-
Google Analytics MCP Server
Search Marketing
surendranb
A
license
A
quality
B
maintenance
Connects Google Analytics 4 data to Claude, Cursor and other MCP clients, enabling natural language queries of website traffic, user behavior, and analytics data with access to 200+ GA4 dimensions and metrics.
Updated 7 days ago (2026-09-10 00:27 UTC)
10
1,020 PyPI
241
MIT
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 7 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
26 npm
1
MIT