KrystalView Analytics
Server Details
Read-only MCP access to sessions, funnels, campaigns, errors, live visitors, and anomalies.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- KrystalView/krystalview-mcp
- GitHub Stars
- 0
- Server Listing
- KrystalView MCP Server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.7/5 across 13 of 13 tools scored.
Each tool targets a distinct analytics aspect: anomalies, campaigns, errors, funnels, live visitors, notifications, scroll depth, sessions, and site stats. No two tools have overlapping purposes; the campaign-related tools are differentiated by focus (summary, ROAS, sessions).
All tools follow a consistent 'get_' prefix with snake_case resource names (e.g., get_anomalies, get_campaign_roas). No mixed conventions or irregular patterns.
13 tools is well-scoped for an analytics server. It covers core analytics (sessions, stats, funnels) without being bloated. Each tool serves a clear purpose.
The surface covers key analytics operations—retrieval of metrics, sessions, funnels, errors, anomalies, campaigns, and live data. Minor gaps exist (e.g., no create/update/delete for funnels), but these are not essential for a read-heavy analytics server.
Available Tools
13 toolsget_anomaliesGet AnomaliesBRead-onlyIdempotentInspect
List detected traffic, friction, bounce, and conversion anomalies for the site.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return. | |
| unacknowledged_only | No | Only include unacknowledged anomalies. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Detected traffic, bounce, friction, and conversion anomalies for the site. |
| meta | Yes | Site and rate-limit metadata for the current MCP call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds the types of anomalies listed, which is useful context. However, it does not disclose additional behaviors like pagination (though limit parameter exists) or authorization requirements.
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 a single, well-front-loaded sentence that efficiently conveys the tool's purpose with no unnecessary words.
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 is minimal but functional. With an output schema present (though not shown), return values are presumably documented. However, the description lacks context about what constitutes an anomaly, how results are ordered, or edge cases, making it barely adequate for a tool in a suite of similar tools.
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?
Both parameters are fully described in the input schema with defaults and constraints. The description adds no additional meaning or context beyond what the schema provides, so it does not improve the agent's understanding of parameters.
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 lists specific types of anomalies (traffic, friction, bounce, conversion) with verb 'list' and resource 'anomalies'. However, among many sibling 'get_*' tools, it does not explicitly distinguish itself from similar tools like 'get_errors' or 'get_notifications'.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use, or comparisons with sibling tools. Given the context of many similar 'get_*' tools, this is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_campaign_roasGet Campaign ROASARead-onlyIdempotentInspect
Get paid campaign spend, clicks, sessions, attributed conversions, and ROAS where ad data is connected.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback period in days. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Paid campaign spend, clicks, sessions, conversions, revenue, and ROAS evidence where connected. |
| meta | Yes | Site and rate-limit metadata for the current MCP call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations by noting 'where ad data is connected,' indicating a prerequisite condition. No contradictions with readOnly and idempotent hints.
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?
Single sentence is concise and front-loads the key purpose without extraneous details.
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?
With output schema present, the description adequately covers the tool's function for a simple parameter set, though it could mention return structure briefly.
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 only parameter 'days' has 100% schema coverage with clear description. The tool description adds no further meaning, meeting the baseline for high 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 returns specific metrics (spend, clicks, sessions, conversions, ROAS) for paid campaigns where ad data is connected, distinguishing it from siblings like get_campaign_sessions or get_campaign_summary.
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 implies usage for ROAS-related queries but lacks explicit guidance on when to use this tool versus alternatives, such as when only sessions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_campaign_sessionsGet Campaign SessionsARead-onlyIdempotentInspect
List sessions attributed to a specific marketing campaign.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return. | |
| offset | No | Pagination offset. | |
| campaign | Yes | UTM campaign name. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Visitor sessions attributed to the requested UTM campaign. |
| meta | Yes | Site and rate-limit metadata for the current MCP call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds no new behavioral insights beyond the schema and annotations. Actual behavior (e.g., pagination, session format) is captured in the input and output schemas.
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 a single, front-loaded sentence that directly conveys the tool's purpose. No extraneous words. It is appropriately concise for a simple read operation.
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 output schema exists and annotations cover behavioral traits, the description is largely complete. It does not mention ordering or other response details, but with the output schema, those are available. Missing minor contextual info like 'sessions are returned as session objects'.
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 100%, so the description does not need to add parameter details. The existing parameter descriptions (e.g., 'UTM campaign name') are clear. No additional semantic value is provided by the tool description.
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 lists sessions for a specific campaign, using the verb 'list' and resource 'sessions', with a filter attribute. It distinguishes from sibling tools like 'get_sessions' (broader) and 'get_session_detail' (single session), but could be more explicit about the UTM-based attribution.
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 implies usage when session data is needed for a campaign, but lacks explicit guidance on when to use this tool versus alternatives like 'get_sessions' or 'get_campaign_summary'. No when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_campaign_summaryGet Campaign SummaryARead-onlyIdempotentInspect
Get campaign attribution breakdown by UTM campaign, source, medium, sessions, duration, and bounce rate.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback period in days. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | UTM campaign attribution summaries including sessions, source, medium, duration, and bounce evidence. |
| meta | Yes | Site and rate-limit metadata for the current MCP call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, providing a clear safety profile. The description adds that the tool returns an attribution breakdown, but does not disclose additional behavioral traits like aggregation level or time granularity. Since annotations cover the main concerns, a score of 3 is appropriate.
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 a single, well-structured sentence that lists the tool's output elements. No extraneous information, perfectly concise.
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 presence of an output schema, the description adequately covers the tool's purpose and outputs. It lists key metrics, though it could mention return format or aggregation type. Mostly 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?
Schema coverage is 100% with the 'days' parameter fully described. The description does not add any semantic meaning beyond what the schema already provides, such as specifying the impact of the lookback period on results.
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 specifies that the tool retrieves campaign attribution breakdown with explicit metrics (UTM campaign, source, medium, sessions, duration, bounce rate). This distinguishes it from sibling tools like get_campaign_sessions or get_campaign_roas by its comprehensive nature.
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 no guidance on when to use this tool versus alternatives. It lacks context about scenarios where a summary is preferred over specific metrics or anomaly detection, 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.
get_errorsGet Browser ErrorsARead-onlyIdempotentInspect
Get aggregated browser errors grouped by type and message, with affected paths and sample sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return. | |
| error_type | No | Filter by error type. | |
| unresolved_only | No | Only include unresolved errors. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Aggregated browser error groups with affected paths, counts, and sample sessions. |
| meta | Yes | Site and rate-limit metadata for the current MCP call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so description does not need to repeat safety traits. It adds value by revealing that errors are grouped by type and message and that results include paths and sample sessions, which is behavior beyond the annotations.
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?
A single sentence that is front-loaded with the key action and resource, then provides specific details about the output structure. Every word earns its place with no 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?
With an output schema present (though not shown), the description does not need to explain return values. It covers the aggregation, grouping, and output fields adequately for a read-only tool with only three parameters.
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 100% with clear parameter descriptions. The description does not add additional parameter-level details beyond stating that data is aggregated and grouped, which is already implied by the parameter descriptions.
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 retrieves aggregated browser errors, specifies grouping by type and message, and mentions included data (affected paths, sample sessions). This distinguishes it from siblings like get_anomalies or get_sessions.
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 implies the tool is for aggregated error data but provides no explicit guidance on when to use it versus alternatives such as get_anomalies or get_sessions. No exclusions or when-not-to-use hints are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_funnel_analysisAnalyze FunnelBRead-onlyIdempotentInspect
Analyze a conversion funnel and show step reach, drop-off, and completion evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback period in days. | |
| funnel_id | Yes | Funnel ID from get_funnels. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Funnel reach, conversion, drop-off, and step-level evidence for the selected lookback period. |
| meta | Yes | Site and rate-limit metadata for the current MCP call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds minor behavioral context (shows step reach, drop-off, completion evidence) but does not disclose other traits like pagination, rate limits, or data freshness. With annotations covering safety, a score of 3 is appropriate.
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 a single sentence of 12 words, front-loaded with the verb 'Analyze' and the resource 'conversion funnel'. It is concise with no wasted words or redundancy. Every word earns its place.
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 presence of an output schema, the description does not need to explain return values. It adequately conveys the tool's purpose and what it shows. The required funnel_id is implied by the schema. However, it could be more explicit about the time window aspect (days parameter) and that it analyzes a specific funnel, but it is largely 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?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning beyond the schema; both parameters are already well-described in the schema (funnel_id: 'Funnel ID from get_funnels', days: 'Lookback period in days'). Therefore, the description adds no extra value for parameters.
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 shows step reach, drop-off, and completion evidence. It distinguishes from siblings like get_funnels (which lists funnels) by focusing on analysis of a specific funnel. However, it does not explicitly differentiate from other analytic tools like get_anomalies.
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 no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions relative to sibling tools. An agent would need to infer usage from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_funnelsList FunnelsARead-onlyIdempotentInspect
List conversion funnels defined for this site.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Configured conversion funnels for the current site. |
| meta | Yes | Site and rate-limit metadata for the current MCP call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true; description adds 'defined for this site' which is implied. No additional behavioral detail beyond annotations.
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?
Single sentence, front-loaded, and efficient with zero wasted words.
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?
Tool is simple (0 params, output schema exists); description covers the essential purpose. No gaps given the complexity.
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?
No parameters exist, so baseline 4 applies per guidelines. Description correctly omits parameter details.
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?
Description clearly states the verb 'list' and resource 'conversion funnels' with scope 'for this site', distinguishing it from sibling tools like get_funnel_analysis.
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?
No guidance on when to use this tool vs alternatives like get_funnel_analysis or get_sessions. Missing context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_live_visitorsGet Live VisitorsARead-onlyIdempotentInspect
Get currently active visitors and sessions seen in the live activity window.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Currently active visitor/session records in the live activity window. |
| meta | Yes | Site and rate-limit metadata for the current MCP call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds context of 'live activity window' but no additional behavioral traits like rate limits or data freshness.
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?
Single sentence of 10 words, no fluff. Front-loaded with verb and resource.
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?
0 parameters, strong annotations, output schema exists. Description adequately covers what the tool returns and its scope.
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?
No parameters exist; schema coverage 100%. Rule states baseline 4 for 0 params.
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 verb 'get', resource 'active visitors and sessions', and context 'live activity window'. Distinct from siblings like get_sessions which are likely historical.
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?
No guidance on when to use versus alternatives like get_sessions or get_site_stats. Only implied context of live activity window.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_notificationsGet NotificationsARead-onlyIdempotentInspect
Get recent KrystalView notifications such as insights, setup notices, errors, and anomalies.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return. | |
| unread_only | No | Only include unread notifications. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Recent KrystalView notifications, insights, setup notices, and anomaly messages. |
| meta | Yes | Site and rate-limit metadata for the current MCP call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds that it returns 'recent' notifications, but does not elaborate on ordering, pagination, or the exact scope of recency. It adds minor behavioral context beyond annotations.
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 a single, concise sentence that efficiently conveys the tool's purpose and provides concrete examples. No extraneous information is present.
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 presence of an output schema (not shown but indicated), the description adequately covers the purpose for a simple read-only list tool with few parameters. It could mention that results are ordered by recency, but overall 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 input schema has 100% description coverage for both parameters ('limit' and 'unread_only'). The description does not add any additional meaning or usage hints beyond the schema, so it meets the baseline but does not enhance understanding.
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 retrieves recent KrystalView notifications with specific examples (insights, setup notices, errors, anomalies). The verb 'Get' and resource 'notifications' are specific, and it distinguishes itself from sibling tools that focus on particular notification types or other entities.
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 implies this tool is for general notification retrieval, as siblings like 'get_anomalies' and 'get_errors' target specific types. However, there is no explicit guidance on when to use this versus those alternatives, nor any mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_scroll_depthGet Scroll DepthARead-onlyIdempotentInspect
Get cumulative scroll-depth reach buckets for a specific page path.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback period in days. | |
| path | Yes | Page path to analyze, for example /pricing. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Scroll-depth reach buckets and page-level scroll engagement evidence. |
| meta | Yes | Site and rate-limit metadata for the current MCP call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and destructiveHint, so the description aligns as expected. However, it adds no additional behavioral details such as rate limits, data freshness, or bucket definitions, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundant information. Every word is necessary and the structure is front-loaded.
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 presence of an output schema and simple parameters, the description is mostly complete. However, it does not explain what 'reach buckets' are or the expected output shape, which could help the agent better understand the tool's value.
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?
Input schema has 100% description coverage for both parameters (days and path). The description reinforces 'page path' but adds no extra semantic meaning beyond what the schema already provides.
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 'Get cumulative scroll-depth reach buckets for a specific page path', providing a specific verb and resource, and distinguishes from sibling tools like get_campaign_summary or get_funnels by focusing on page path and scroll depth.
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?
No guidance is given on when to use this tool versus alternatives like get_anomalies or get_funnels. The context signals mention sibling tools but the description does not specify when scroll depth is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_session_detailGet Session DetailARead-onlyIdempotentInspect
Get full details for a specific visitor session, including pages, events, device context, errors, and friction signals.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Session primary key from get_sessions. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Detailed visitor session evidence including pages, events, context, errors, and friction signals. |
| meta | Yes | Site and rate-limit metadata for the current MCP call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, non-destructive behavior. The description adds value by specifying the returned content (pages, events, device context, errors, friction signals), giving the agent a clear idea of what to expect 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose ('Get full details') and lists key content types. Every word contributes to clarity, with no filler or 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?
The tool has an output schema (not shown), so the description doesn't need to detail return values. It adequately covers the data categories returned. For a simple retrieval tool with one parameter and clear annotations, the description is sufficiently complete, though it could hint at performance or pagination for large sessions.
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 input schema has 100% description coverage, clearly defining session_id as 'Session primary key from get_sessions.' The description does not add additional semantic meaning beyond the schema, so a baseline score of 3 is appropriate.
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 'Get' and the resource 'full details for a specific visitor session', listing specific content types (pages, events, device context, errors, friction signals). It effectively distinguishes from siblings like get_sessions (which lists sessions) and get_errors (which focuses on errors only).
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 implies usage when a session_id is known and full details are needed, but does not explicitly state when not to use or mention alternative tools. Sibling tools exist for specific aspects (e.g., get_errors, get_scroll_depth), but the description doesn't guide the agent to choose this over those.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sessionsList SessionsARead-onlyIdempotentInspect
List recent visitor sessions with filters for URL, country, device, duration, friction, and rage clicks.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return. | |
| query | No | Search entry or exit URLs, for example /pricing. | |
| offset | No | Pagination offset. | |
| country | No | Country name filter. | |
| device_type | No | Device type filter. | |
| min_duration | No | Minimum session duration in seconds. | |
| min_friction | No | Minimum friction score. | |
| has_rage_clicks | No | Only sessions with rage clicks. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Paginated recent visitor session records and related summary fields. |
| meta | Yes | Site and rate-limit metadata for the current MCP call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover safety and idempotency. The description adds no further behavioral context (e.g., pagination behavior, rate limits, data recency window). The word 'recent' is vague.
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 a single concise sentence that packs the purpose and key filter dimensions. It is not verbose, but front-loading the filter list could be slightly improved for readability.
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?
With full schema coverage and an output schema present, the description adequately covers the tool's purpose and available filters. It does not explain ordering or the precise definition of 'recent', but overall it is sufficiently complete for a list 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 coverage is 100%, so baseline is 3. The description merely repeats filter names from the schema without adding semantic detail (e.g., how multiple filters combine, accepted value formats, or relationship between parameters).
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' and the resource 'visitor sessions', and enumerates specific filter dimensions (URL, country, device, etc.). This differentiates it from sibling tools like get_session_detail (single session) and get_live_visitors (live sessions).
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 implies usage for listing filtered sessions but provides no explicit guidance on when to use this tool versus alternatives like get_session_detail, get_live_visitors, or get_anomalies. No when-not or trade-off information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_site_statsGet Site StatsARead-onlyIdempotentInspect
Get aggregate site metrics including sessions, duration, friction, rage clicks, daily counts, device mix, and top pages.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback period in days. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Aggregate site analytics metrics, trend series, device mix, top pages, and friction distribution. |
| meta | Yes | Site and rate-limit metadata for the current MCP call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) cover core behavioral traits. Description adds value by enumerating included metrics, but doesn't mention any additional behavioral details like pagination or limits.
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?
Single sentence, no filler. Concise and to the point.
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?
Description is adequate given output schema exists and annotations are rich. Lists metrics which helps understanding. Could mention that it returns aggregated data per period.
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?
Single parameter 'days' is fully described in schema (description, min, max, default). Description doesn't add new semantics beyond the schema, so baseline 3.
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?
Description clearly states verb 'Get' and resource 'site metrics', listing specific metrics. However, it doesn't differentiate from sibling tools like get_sessions, which also provides session data. The aggregation aspect is implicit.
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?
No guidance on when to use this tool versus alternatives such as get_sessions or get_anomalies. Missing explicit context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.