Skip to main content
Glama
microsoft

Clarity Data Export MCP Server

Official
by microsoft

Microsoft Clarity MCP Server

This is a Model Context Protocol (MCP) server for the Microsoft Clarity. It allows you to access your session recordings, project analytics, and documentation from Clarity using Claude for Desktop or other MCP-compatible clients.

Key Features

  • Analytics Data Access: Query your Microsoft Clarity analytics data including traffic metrics, user behavior insights, and performance statistics

  • Session Recording Retrieval: Access and analyze session recordings to understand user interactions and identify optimization opportunities

  • Natural Language Querying: Ask questions in plain English to get insights from your data - no need to learn complex query syntax or API endpoints

  • Flexible Data Filtering: Filter results by various dimensions such as browser, device, country, and many more

  • Real-Time Data Access: Fetch the latest analytics data and insights from your Clarity projects on-demand

  • Documentation Integration: Get quick answers and guidance from Microsoft Clarity documentation directly within your workflow

  • Seamless MCP Integration: Works natively with Claude for Desktop, Visual Studio Code, and other Model Context Protocol (MCP) compatible clients

Related MCP server: CUT Clarity MCP Server

Setup and Installation

Prerequisites

  • Node.js v16 or higher

  • A Microsoft Clarity account and API token

  • Any MCP-compatible client (Claude for Desktop, etc.)

Installation

You can install and run this package directly using npm:

# Install globally
npm install -g @microsoft/clarity-mcp-server

# Run the server
clarity-mcp-server

Option 2: Run with npx without installing

You can run the server directly using npx without installing:

npx @microsoft/clarity-mcp-server

With either option, you can provide your Clarity API token using the --clarity_api_token parameter:

npx @microsoft/clarity-mcp-server --clarity_api_token=your-token-here

Option 3: Manual Installation

  1. Clone or download this repository

  2. Install dependencies:

    npm install
  3. Build the TypeScript code:

    npm run build
  4. Run the server:

    npm run start

Extension/Plugin Installation

Visual Studio Code Extension

Click the button above to install the Microsoft Clarity MCP server directly in Visual Studio Code.

Claude Desktop Plugin

Install from Claude's extension gallery:

  1. Open Claude Desktop

  2. Navigate to File → Settings → Extensions

  3. Search for Microsoft Clarity

  4. Click Install to add the extension

  5. Configure your API Token:

Configuration

You can provide the Clarity data export API token in two ways:

  1. Command Line Arguments:

    npx @microsoft/clarity-mcp-server --clarity_api_token=your-token
  2. Tool Parameters:

Configuring MCP Clients

Generic MCP Client Configuration

MCP clients typically require configuration to connect to the server. Here's a general example of how to configure an MCP client:

{
  "mcpServers": {
    "@microsoft/clarity-mcp-server": {
      "command": "npx",
      "args": [
        "@microsoft/clarity-mcp-server",
        "--clarity_api_token=your-api-token-here"
      ]
    }
  }
}

The specifics of where and how to add this configuration will depend on your specific MCP client.

Claude for Desktop Configuration

To configure Claude for Desktop to use this server:

  1. Open your Claude for Desktop configuration file:

    • Windows: %AppData%\Claude\claude_desktop_config.json

    • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  2. Add the configuration shown in the generic example above

  3. Save the configuration file and restart Claude for Desktop

Server Usage

The server exposes various tools that you can call from any MCP client. Just ask naturally and keep each request focused on one thing.

Query Analytics Dashboard

  • Name: query-analytics-dashboard

  • Description: Retrieves analytics data and metrics from your project's dashboard using a simplified natural language search query.

  • Examples:

    • How many Clarity sessions did we get from Egypt in the past 3 days?

    • What are the most used browsers in my Clarity project?

    • Show me traffic metrics from my Clarity project for the last week

List Session Recordings

  • Name: list-session-recordings

  • Description: Lists your project's session recordings based on a specified filtering criteria. The filters allow you to narrow down the recordings by various fields such as URLs, device types, browser, OS, country, city, and more.

  • Examples:

    • List the most recent Clarity sessions from mobile devices

    • Show the top 5 Clarity sessions with the highest number of user clicks

    • Get Clarity recordings where users encountered JavaScript errors

Query Documentation Resources

  • Name: query-documentation-resources

  • Description: Retrieves snippets from Microsoft Clarity documentation to find answers to user questions including step-by-step screenshots for setup guides, features, usage, troubleshooting, and integration instructions.

  • Examples:

    • How to track custom events using Microsoft Clarity?

    • How many labels can I add to a recording in Microsoft Clarity?

API Token

Getting Your API Token

To generate an API token:

  1. Go to your Clarity project

  2. Select Settings → Data Export → Generate new API token

  3. Provide a descriptive name for the token

  4. Save the generated token securely

Privacy Policy

For information about data privacy and usage, please refer to the Microsoft Clarity Privacy Policy.

License

This project is licensed under the MIT License.

Available Tools

3 tools
list-session-recordingsA
Read-only

List Microsoft Clarity session recordings based on specified filters. The filters allow you to narrow down the recordings by various criteria such as URLs, device types, browser, OS, country, city, and more. The date filter is required and must be in UTC ISO 8601 format.

ParametersJSON Schema
NameRequiredDescriptionDefault
filtersYesA set of filters that can be applied to the Microsoft Clarity to session recordings. This allows you to filter recordings based on various criteria such as URLs, device types, browser, OS, country, city, and more. The date filter is required and must be in UTC ISO 8601 format.
sortByNoSort option for session recordings. Default is SessionStart_DESC (newest first).SessionStart_DESC
countNoThe number of sample session recordings to return. Default is 100. Maximum is 250.

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds context by detailing that it lists recordings based on filters and specifies the required date filter format. No contradiction with annotations. Could mention pagination or rate limits, but the schema covers return structure partially.

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 sentences, concise and front-loaded with the core purpose. No wasted words, and it efficiently communicates the tool's function and key constraint (date format).

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 the tool's complexity (many filters, nested objects) and the absence of an output schema, the description should explain what the listing returns. It does not mention return format or pagination details beyond the count parameter. This gap reduces completeness.

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 provides detailed parameter meanings. The description adds minimal extra value beyond a brief overview of filter capabilities. For a tool with such rich schema descriptions, this is adequate but not exceptional.

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 verb 'List' and the resource 'Microsoft Clarity session recordings', with explicit mention of filtering. The tool name and description distinguish it from sibling tools like 'clarity_clienti' and 'query-analytics-dashboard'.

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 indicates when to use the tool (to list recordings with filters) and highlights the required date filter format. However, it does not provide explicit guidance on when not to use it or mention alternatives, which would improve score further.

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

query-analytics-dashboardA
Read-only

Fetch Microsoft Clarity analytics data using a simplified natural language search query. The query should be focused on one specific data retrieval or aggregation task. Avoid complex multi-purpose queries. Time ranges should be explicitly specified when possible. If no time range is provided, prompt the user to specify one.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesA natural language search query string for filtering and shaping analytics data. The query should be specific and include temporal constraints when available. (e.g., 'Top browsers last 3 days', 'The active time duration for mobile devices in United States last week'). Time ranges should be explicitly specified when possible. If no time range is provided, prompt the user to specify one.

TDQS

A4/5.0
Behavior4/5

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

Annotations declare readOnlyHint true and destructiveHint false, so safety is clear. The description adds behavioral context about natural language querying and prompting for time ranges, which goes beyond the structured annotations.

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 very concise with two focused sentences plus a short note. Information is front-loaded and every sentence adds value without redundancy.

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?

Given the tool's simplicity (one parameter, no output schema), the description covers the core behavior and usage guidance adequately. It does not detail return format or error handling, but these are less critical for a natural language query tool.

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% and the parameter description in the schema largely mirrors the tool description. The description adds minimal extra meaning beyond what the schema already provides, so it meets but does not exceed the baseline of 3.

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 it fetches Microsoft Clarity analytics data using a natural language query. It is specific about the resource and action, but does not explicitly differentiate from sibling tools like clarity_clienti or list-session-recordings.

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 provides guidance to focus on one task, avoid complex multi-purpose queries, and specify time ranges. It also instructs to prompt the user if no time range is provided, indicating appropriate usage context. However, it does not compare to alternative tools.

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

query-documentation-resourcesA
Read-only

Retrieve Microsoft Clarity documentation snippets for finding answers to user questions including step-by-step screenshots for setup guides, features, usage, troubleshooting, and integration instructions. The query should be focused on one specific documentation topic or question. Avoid complex multi-purpose queries.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesA natural language search query string for filtering and shaping analytics data. The query should be specific and include temporal constraints when available. (e.g., 'Top browsers last 3 days', 'The active time duration for mobile devices in United States last week'). Time ranges should be explicitly specified when possible. If no time range is provided, prompt the user to specify one.

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds context about the content returned (snippets, screenshots) but does not disclose additional behavioral traits like pagination, rate limits, or response structure beyond what annotations imply.

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, well-structured sentence that front-loads the core purpose and immediately follows with usage guidance. Every word earns its place, with no redundancy or unnecessary detail.

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, read-only tool with one parameter and no output schema, the description adequately covers purpose, query guidance, and safety. It could optionally mention the expected return format (e.g., text snippets), but given the annotations and simplicity, it is sufficiently complete.

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 single parameter 'query' has 100% schema description coverage with a detailed description including examples and guidance for temporal constraints. The description adds value by providing concrete examples and instructing the user to prompt for missing time ranges, exceeding what the schema alone provides.

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 retrieves Microsoft Clarity documentation snippets for answering user questions, including specific content types like step-by-step screenshots for setup, features, and troubleshooting. It distinguishes well from sibling tools like query-analytics-dashboard and list-session-recordings, which serve 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 provides some guidance: queries should be focused on one specific topic and avoid complexity. However, it does not explicitly state when to use this tool versus alternatives, nor does it specify prerequisites or cases where the tool is not appropriate.

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. 4 tool updatesv1.0.0
    • Removedget-clarity-data
    • Addedlist-session-recordings
    • Addedquery-analytics-dashboard
    • Addedquery-documentation-resources
  2. 1 tool update
    • First observedget-clarity-data

TDQS

A3.7/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: list-session-recordings retrieves session data with filters, query-analytics-dashboard fetches analytics via natural language queries, and query-documentation-resources retrieves documentation snippets. There is no overlap in functionality, making it easy for an agent to select the correct tool.

Naming Consistency5/5

All tool names follow a consistent verb-noun pattern with hyphens (list-session-recordings, query-analytics-dashboard, query-documentation-resources). The naming is predictable and readable, with no deviations in style or convention.

Tool Count3/5

With only 3 tools, the server feels thin for a data export domain that might benefit from more granular operations like exporting specific data formats or managing exports. However, the tools cover core areas, so it's borderline but not severely lacking.

Completeness4/5

The tools provide good coverage for listing, querying analytics, and accessing documentation, but there are minor gaps such as missing explicit export or download functionality for data, which could limit agent workflows. Overall, it supports key tasks without major dead ends.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    A powerful Model Context Protocol (MCP) server that provides comprehensive Google Analytics 4 (GA4), Google Search Console (GSC), and Google Merchant Center (GMC) integration for Claude Desktop and other MCP clients.
    Apache 2.0
  • A
    license
    Not graded
    quality
    C
    maintenance
    MCP server for Microsoft Clarity Data Export API, providing tools to retrieve traffic, popular pages, engagement metrics, and user behavior insights such as dead clicks, rage clicks, and script errors. Supports multiple projects with daily quota management and shared caching.
    MIT
  • A
    license
    A
    quality
    C
    maintenance
    Bridges Microsoft Clarity's analytics API with Claude, enabling custom date ranges and page-level filtering on top of Clarity's native limitations.
    3
    12 npm
    MIT