The KrystalView MCP Server gives AI agents direct access to website analytics data, enabling querying, investigation, and analysis of visitor behavior and site performance.
Session Analysis: Search and filter visitor sessions by device type, country, friction score, duration, rage clicks, or entry/exit URLs. Deep-dive into individual sessions for a full event timeline, navigation path, device/browser info, friction breakdown, errors, and geographic location.
Site Statistics: Get aggregate metrics including total sessions, bounce rate, average friction score, device/browser breakdowns, top pages, and daily session trends over a configurable time period.
Funnel Analysis: List all defined conversion funnels and analyze step-by-step conversion rates and drop-off points (e.g., landing → signup → checkout → payment).
Anomaly Detection: Access AI-detected anomalies (traffic spikes/drops, friction surges, bounce spikes) with severity levels, deviation percentages, and AI-generated explanations.
Live Visitors: Check the currently active visitor count and recent live sessions.
Campaign Insights: Get UTM campaign summaries, campaign-specific sessions, and ROAS for paid campaigns.
Error Monitoring: Access aggregated client-side browser errors.
Notifications: View recent KrystalView notifications and insights.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@KrystalView MCP Server Show me frustrated mobile users from the last 24 hours"
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.
Give your AI agents direct access to website analytics. Query visitor sessions, investigate UX friction, analyze conversion funnels, review campaigns and errors, and get anomaly alerts — all from Claude, Cursor, or any MCP-compatible client.
Use this when your client supports remote MCP servers or connector-style OAuth. No local package install is required.
Field | Value |
Endpoint |
|
Transport |
|
Authentication | OAuth authorization code + PKCE |
OAuth metadata |
|
Protected resource metadata |
|
During OAuth, KrystalView asks the signed-in user to choose the site the MCP client can read. The issued token is read-only and scoped to that site. The hosted OAuth server supports dynamic client registration, authorization code + PKCE, resource indicators, refresh-token rotation, and token revocation.
For clients that support custom headers instead of OAuth, the hosted endpoint also accepts a KrystalView read API key as either:
Authorization: Bearer kv_live_...or:
X-API-Key: kv_live_...Use this when your MCP client runs local stdio servers, such as Claude Desktop, Claude Code, Cursor, or similar developer tools.
pip install krystalview-mcpGenerate an API key in your KrystalView console under Settings > API Keys.
Add to your claude_desktop_config.json:
{
"mcpServers": {
"krystalview": {
"command": "krystalview-mcp",
"env": {
"KRYSTALVIEW_API_KEY": "your-api-key-here"
}
}
}
}claude mcp add krystalview -- krystalview-mcp
# Then set your API key:
export KRYSTALVIEW_API_KEY="your-api-key-here"Add to your MCP settings:
{
"krystalview": {
"command": "krystalview-mcp",
"env": {
"KRYSTALVIEW_API_KEY": "your-api-key-here"
}
}
}Related MCP server: @pulspeed/mcp-server
Tool | Description |
| List/search visitor sessions with filters (device, location, friction, rage clicks) |
| Deep dive into a specific session — full timeline, events, navigation path |
| Aggregate performance metrics — sessions, friction, devices, top pages |
| Scroll-depth buckets for a specific page path |
| Currently active visitor count and recent live sessions |
| AI-detected anomalies with explanations (traffic spikes/drops, friction surges) |
| List defined conversion funnels |
| Step-by-step funnel conversion rates and drop-off analysis |
| UTM campaign attribution summary |
| Visitor sessions from a specific campaign |
| Paid campaign spend, conversions, and ROAS where connected |
| Aggregated client-side browser errors |
| Recent KrystalView notifications and insights |
Once connected, try asking your AI assistant:
"How's my site performing this week?"
"Show me frustrated mobile users from the last 24 hours"
"Why did our traffic drop yesterday?"
"Where are users dropping off in the checkout funnel?"
"Find sessions with rage clicks on the pricing page"
"Which campaigns are driving the most high-friction sessions?"
"Show me unresolved browser errors with sample session IDs"
"Are there any anomalies I should know about?"
Variable | Required | Default | Description |
| Yes | — | Your KrystalView API key |
| No |
| API base URL |
| No |
| Request timeout in seconds |
API keys have configurable rate limits (default: 60 requests per minute). Rate limit headers are included in every response. If you hit the limit, the server returns a clear error with retry timing.
API keys are scoped to a single site — agents can only access data for the site the key was created for
OAuth tokens issued by the hosted MCP endpoint are read-only and scoped to the selected site
Hosted OAuth supports refresh-token rotation and token revocation
Browser-originating MCP/OAuth requests are checked against explicit trusted origins
Tools are read-only
All requests use HTTPS
Keys can be rotated or revoked in the KrystalView console
The local stdio package stores no data — it proxies directly to the KrystalView API
MIT
Get detected anomalies for the site.
Anomalies are automatically detected when metrics deviate significantly from their 7-day rolling average (>2 standard deviations). Types include: traffic_spike, traffic_drop, friction_surge, and bounce_spike.
Each anomaly includes: type, severity (warning/critical), metric name, expected vs actual values, deviation percentage, and an AI-generated explanation of what likely caused it.
Args: limit: Max results (1-200, default 20) unacknowledged_only: Only show unacknowledged anomalies
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| unacknowledged_only | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must provide behavioral transparency. It explains the output structure and the anomaly detection logic, which is helpful. However, it does not explicitly state that this is a read-only operation or any potential side effects, leaving some uncertainty about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by explanatory details and parameter descriptions. It is efficient, though the explanation of anomaly types could be considered extraneous for the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, output structure, and parameter details comprehensively. It could be improved with usage guidelines relative to siblings, but given the tool's simplicity and the presence of an output schema, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides parameter names and types. The description adds constraints (1-200 range for limit), default values, and functional meaning for unacknowledged_only. This compensates well for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving detected anomalies for the site. It further elaborates on the nature of anomalies (deviations from 7-day rolling average) and lists types, which helps differentiate from sibling tools focused on funnels, sessions, and stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about what anomalies are and the data they include, which implies usage for monitoring anomalies. However, it does not explicitly state when to use this tool versus the sibling tools, nor does it provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a conversion funnel — see where users drop off.
Returns step-by-step conversion rates showing how many sessions reached each step, the conversion rate between steps, and the overall funnel completion rate.
Use this to identify which step in a user flow (e.g. landing -> signup -> checkout -> payment) loses the most visitors.
Args: funnel_id: Funnel ID from get_funnels results days: Lookback period in days (7-90, default 30)
| Name | Required | Description | Default |
|---|---|---|---|
| funnel_id | Yes | ||
| days | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly states the tool returns step-by-step conversion rates, conversion between steps, and overall completion rate. It also mentions that funnel_id comes from get_funnels results, implying it is a read-only analysis. No destructive hints, and the behavior is well-described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, then details returns, then usage guidance, then parameter explanations. Every sentence adds value, and there is no wasted wording. It is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters and an output schema (though not shown), the description covers what the tool returns (step-by-step rates), prerequisites (funnel_id from get_funnels), and parameter details (days range). It is complete for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. The description explains both parameters: funnel_id is from get_funnels results (origin), and days has a range (7-90) and default (30). This adds significant meaning beyond the schema's type/default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes a conversion funnel and identifies drop-off points. It mentions step-by-step conversion rates, distinguishing it from sibling tools like get_funnels which lists funnels. The verb 'analyze' and resource 'conversion funnel' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to identify which step... loses the most visitors.' This provides clear when-to-use guidance. It does not explicitly mention when not to use or alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all conversion funnels defined for this site.
Returns funnel definitions with their name, steps (URLs/patterns), and creation date. Use the funnel ID with get_funnel_analysis to see conversion rates and drop-off points.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It mentions return fields (name, steps, creation date) but does not discuss authorization, rate limits, or side effects. Since there is an output schema, the lack of full return structure details is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence front-loads the purpose, and the second adds useful return information and a link to a sibling tool. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema, the description is fairly complete. It explains the tool's purpose, return fields, and relation to get_funnel_analysis. It could mention that it returns a list, but this is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline is 4. The description adds value by describing what the tool returns, which is beyond the empty schema. This compensates for the absence of parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (list), resource (conversion funnels), and scope (defined for this site). It distinguishes from sibling tools like get_funnel_analysis, which deals with analysis rather than definitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by linking to get_funnel_analysis for conversion rates, indicating when to use this tool vs. its sibling. However, it does not explicitly state when not to use it or compare with other listing tools like get_anomalies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for a specific session.
Returns the complete session record including: all page visits with timestamps, event timeline, device/browser info, IP address, geographic location, friction breakdown, rage clicks, errors encountered, and navigation path.
Use this to deep-dive into a specific session after finding it via get_sessions.
Args: session_id: The session primary key (UUID) from get_sessions results
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description lists return fields but does not mention side effects, permissions, or rate limits. Since the tool is read-only, a 3 is adequate but lacks depth beyond the return data listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, three-section structure: purpose, return details, usage context, parameter docs. No superfluous words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists but not shown. Description lists extensive return fields (page visits, events, etc.). Could mention potential errors or limits, but nearly complete for a detail lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for 'session_id' (just type string). Description adds: 'session_id: The session primary key (UUID) from get_sessions results,' specifying type and source. Fully compensates for schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get full details for a specific session.' Lists specific return data (page visits, event timeline, etc.) and differentiates from sibling tools like get_sessions (list) and get_site_stats (aggregate).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this to deep-dive into a specific session after finding it via get_sessions.' Provides clear context and precondition. Could add when not to use, but sufficient for a detail-retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent visitor sessions with filtering.
Each session includes: duration, page count, entry/exit URLs, device info, screen size, IP address, location (country/city), friction score, and rage click count.
Use this to find sessions matching specific criteria — e.g. frustrated mobile users, visitors from a specific country, or high-friction sessions.
Args: query: Search entry/exit URLs (e.g. "/pricing", "/checkout") limit: Max results (1-100, default 20) offset: Pagination offset country: Filter by country name device_type: "mobile" or "desktop" min_friction: Minimum friction score (0-10) min_duration: Minimum session duration in seconds has_rage_clicks: Only sessions with rage clicks
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| limit | No | ||
| offset | No | ||
| country | No | ||
| device_type | No | ||
| min_friction | No | ||
| min_duration | No | ||
| has_rage_clicks | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the returned fields but does not mention read-only nature, rate limits, authentication requirements, or pagination behavior beyond offset/limit. Adequate for a simple list tool but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a front-loaded purpose statement, a field list, a usage example, and parameter definitions. It is concise but could potentially omit the field list if the output schema is rich, though the output schema is not shown.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (none required) and an output schema, the description covers parameter semantics and usage context well. It lacks information on sorting, performance, or rate limits, but overall it is complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so effectively with an Args section explaining each parameter's purpose, valid values, and defaults. This adds significant meaning beyond the schema's basic titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List recent visitor sessions with filtering' and enumerates the fields included in each session. This distinctively differentiates it from siblings like get_session_detail (single session) and get_anomalies/funnels (different analyses).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage examples ('frustrated mobile users, visitors from a specific country, or high-friction sessions') and implies when to use this tool for listing vs get_session_detail for detail. It could improve by explicitly stating when not to use it, but the examples offer strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregate site statistics and performance metrics.
Returns: total sessions, average duration, average friction score, bounce rate, rage click sessions, device breakdown (desktop/mobile), browser breakdown, top entry pages, top exit pages, daily session counts, and friction score distribution.
Use this for an overview of site health and trends.
Args: days: Lookback period in days (7-90, default 7)
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It adds a parameter constraint (days range 7-90) beyond the schema, and implies read-only behavior by describing aggregate stats. However, it lacks details on authentication, rate limits, or what happens with invalid input, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear verb-object statement and structured with a Returns list and Args line. While efficient, the bullet list of metrics could be slightly more compact, but overall it is well-organized and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (many return fields) and the presence of an output schema, the description provides a comprehensive list of return values and usage guidance. It also documents the parameter. However, it omits behavioral details like performance impact or error handling, leaving minor completeness gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a type and default for the single parameter 'days.' The description adds meaningful semantics: 'Lookback period in days (7-90, default 7),' specifying the valid range and clarifying its purpose (time window for aggregation). This fully compensates for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get aggregate site statistics and performance metrics.' It lists the specific metrics returned and explicitly distinguishes it as an 'overview of site health and trends,' which contrasts with sibling tools like get_anomalies or get_session_detail that target specific aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this for an overview of site health and trends,' providing clear context for when to use the tool. However, it does not explicitly state when not to use it or mention alternative tools for more granular data, missing a stronger usage boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.4get_anomaliesget_funnel_analysisget_funnelsget_session_detailget_sessionsget_site_statsEach tool targets a distinct aspect of site analytics: anomalies, funnel definitions, funnel conversion analysis, session listing, session deep-dive, and aggregate stats. No two tools overlap in functionality.
All tool names follow a consistent 'get_<resource>' pattern with snake_case. Variations like 'get_funnel_analysis' and 'get_session_detail' extend logically without breaking the pattern.
With 6 tools covering anomalies, funnels, sessions, and site stats, the set is well-scoped for an analytics MCP server. Each tool serves a clear purpose without being overly granular or sparse.
The tool surface covers all major read-only analytics needs: listing and details for sessions, funnels, and anomalies plus aggregate stats. Minor gaps exist: no single anomaly detail view and no way to acknowledge anomalies, but the core workflows are supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Query your Betterlytics web analytics from AI agents: traffic, funnels, journeys, errors, uptime.
Real-time web analytics for AI agents: query traffic, funnels, revenue, and manage your sites.
Privacy-first web analytics for AI agents: visitors, revenue, funnels, visitor profiles.
Commerce intelligence for AI agents. Diagnose drop-offs, fix checkouts, optimize pricing.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/KrystalView/krystalview-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
