KrystalView MCP Server

Official

by KrystalView

Overview Schema Related Servers Score Discussions(1)

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.4
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.2/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/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: 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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
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), 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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/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 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.
Parameters5/5
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.
Purpose5/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: '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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![krystalview-mcp MCP server](https://glama.ai/mcp/servers/KrystalView/krystalview-mcp/badges/card.svg)](https://glama.ai/mcp/servers/KrystalView/krystalview-mcp)

Score Badge

Copy to your README.md:

[![krystalview-mcp MCP server](https://glama.ai/mcp/servers/KrystalView/krystalview-mcp/badges/score.svg)](https://glama.ai/mcp/servers/KrystalView/krystalview-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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