Skip to main content
Glama
wave-av

WAVE MCP Server

Official
by wave-av
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

wave_get_viewers

Retrieve account-wide viewer engagement metrics for any date range. Identify audience trends and measure content performance with precise analytics.

Instructions

Get account-wide viewer engagement analytics (GET /v1/analytics/engagement) over an optional date range

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoRange end (ISO 8601 timestamp), optional
fromNoRange start (ISO 8601 timestamp), optional

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.3.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / from
      Added value: +{
+  "description": "Range start (ISO 8601 timestamp), optional",
+  "type": "string"
+}
    • removedInput schema / properties / include_demographics
      Removed value: -{
-  "description": "Include geographic and device breakdown (default: false)",
-  "type": "boolean"
-}
    • removedInput schema / properties / stream_id
      Removed value: -{
-  "description": "Stream ID to get viewers for. Omit for account-wide totals.",
-  "format": "uuid",
-  "type": "string"
-}
    • addedInput schema / properties / to
      Added value: +{
+  "description": "Range end (ISO 8601 timestamp), optional",
+  "type": "string"
+}
  2. First observedv0.1.5

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does disclose the HTTP method GET, which indicates a read-only operation, and the date-range filtering behavior. However, it does not mention authentication, rate limits, pagination, or the shape of the response, leaving notable operational details unstated.

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 entire description is one tight sentence that leads with the action, specifies scope, includes the endpoint, and notes the optional date range. Every word provides value and there is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with two optional, fully documented parameters, the description is largely sufficient: it states exactly what is retrieved and the available filter. The lack of an output schema means the response structure is not described, which prevents a 5, but the core invocation details are complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description's 'optional date range' adds minimal grouping context for from/to, but the schema already documents the parameters and their optionality. There is no deeper semantic information beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Get'), resource ('viewer engagement analytics'), and scope ('account-wide'), and even includes the endpoint (GET /v1/analytics/engagement). It is clear and distinct from sibling tools like wave_get_stream_metrics, but does not explicitly name or differentiate a sibling, so it falls short of a 5.

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 phrase 'account-wide' implies when this tool should be used versus per-stream alternatives, and 'optional date range' hints at parameter usage. However, there is no explicit guidance about when to prefer this over siblings like wave_get_usage or wave_get_stream_metrics, no exclusions, and no mention of prerequisites.

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

Deploy Server

Other Tools