Clarity MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CLARITY_API_TOKEN | Yes | Your JWT token for Microsoft Clarity API |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_clarity_insightsA | Fetch Microsoft Clarity dashboard insights (traffic, scroll depth, engagement time, rage/dead clicks, script errors, etc.) for the last 1-3 days, optionally broken down by up to 3 dimensions. IMPORTANT: Clarity's API only supports a rolling 1-3 day lookback (no custom date ranges), and this project is limited to 10 requests per day total, so batch dimensions thoughtfully rather than making repeated calls. Optional urlFilter applies a case-insensitive substring match on the URL field AFTER Clarity returns its response (post-processing only) — results are still capped at Clarity's 1,000-row response limit, so a very broad urlFilter on a large site can still be affected by rows Clarity already dropped before filtering ever sees them. If urlFilter is set and none of dimension1-3 is 'URL', it's auto-added to the first open slot; if all 3 are already used by other dimensions, the call fails with an error asking you to free a slot. |
| capture_clarity_snapshotA | Capture today's Clarity insights (numOfDays=1, broken down by URL) and save them to a local file (data/YYYY-MM-DD.json, UTC calendar day) so a future get_clarity_historical_insights call can retrieve this day even after it ages out of Clarity's 3-day live window. This must be triggered manually — there is no background schedule — so run it yourself whenever you want today preserved. Uses 1 of your 10 daily Clarity API requests. Safe to re-run any time today: re-running overwrites today's saved file rather than erroring or creating duplicates. |
| get_clarity_historical_insightsA | Return locally-captured Clarity snapshots for each day from startDate to endDate (inclusive, YYYY-MM-DD, UTC). This reads ONLY local files previously written by capture_clarity_snapshot — it never calls the Clarity API and cannot retrieve any day that wasn't explicitly captured, because Clarity's own API has no historical endpoint and only ever exposes the last 1-3 days. The result explicitly lists which requested dates were found locally and which are missing, so gaps are visible rather than silently dropped. There is no way to backfill a missing date after the fact. Optional urlFilter post-filters each found day's rows by URL substring, same as on get_clarity_insights. For wide date ranges, passing urlFilter is recommended to avoid returning many uncompressed days at once. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a clearly distinct role: live API retrieval, historical local retrieval, and snapshot capture. The contexts (live vs. historical vs. capture) are unambiguously described, and despite some overlap in 'insights' wording, the source and behavior are distinctly defined.
The naming follows a consistent pattern: 'get_clarity_*' for retrieval variants and 'capture_clarity_snapshot' for the write operation. The verb-noun structure is uniform and intuitive, with the only variation being the descriptor between 'insights' and 'historical_insights'.
Three tools fully cover the intended workflow: live query, snapshot capture, and historical retrieval. This is a well-scoped set for a specialized server, with no unnecessary extras and no missing core functions.
The tool set forms a complete lifecycle for Clarity data access: capture today's data, retrieve live insights, and retrieve previously captured historical data. The known limitations (API lookback and manual capture) are explicitly documented, and there are no operational dead ends within the server's stated role.