Skip to main content
Glama

LiveReacting

by com.livereacting
OverviewDiscussionsAdmin

Read analytics for a finished broadcast

livereacting_get_stream_analytics
Read-onlyIdempotent

Read the analytics of one broadcast. Get the broadcast id from livereacting_list_broadcasts.

type: "youtube" is included with every paid plan. type: "playlists" is available on request rather than on every plan, so it can return FEATURE_NOT_AVAILABLE for an account that is otherwise working normally. Tell the customer to email hello@livereacting.com to ask for access to it.

type: "youtube" returns what YouTube reports for the broadcast -- views, watch time, likes, peak and average concurrent viewers, revenue where it is available, plus traffic sources, daily trend, age and gender split, devices and geography. The channel must also have granted analytics access.

type: "playlists" returns what LiveReacting itself recorded: one row per recorded playback action, naming the file, the action, its timestamp and how many people were watching at that moment.

The row-shaped YouTube sections are only returned when you name them in sections, 50 rows at a time. There is no CSV export here; use the REST API for that.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeYes"youtube" for what YouTube reports about the broadcast. "playlists" for what LiveReacting recorded about each video file that played. "youtube" is included with every paid plan; "playlists" is available on request.
limitNoHow many rows to return. Defaults to 100 for type "playlists", and to 50 per section for type "youtube".
liveIdYesBroadcast id, from livereacting_list_broadcasts.
offsetNoSkip this many rows. Use the nextOffset from a truncated response.
endDateNoLast day to report on, YYYY-MM-DD.
sectionsNotype "youtube" only. Which row-shaped sections to include. Nothing here is returned unless you ask for it: trafficSources, dailyTrend, ageGroups, genders, devices, geography.
accountIdNotype "youtube" only. Which YouTube channel to report on, when the broadcast went to more than one.
startDateNoFirst day to report on, YYYY-MM-DD. For type "playlists", send startDate and endDate together and keep the range to 28 days or less.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuine context beyond them: the YouTube channel must have granted analytics access, `playlists` can fail with FEATURE_NOT_AVAILABLE on a healthy account, row-shaped sections are paginated 50 at a time, and no CSV export is available here. That is exactly the extra behavioral detail the annotations do not carry.

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?

Front-loaded with the core action and organized into one paragraph per concern (prerequisite, plan availability, youtube returns, playlists returns, section paging). Slightly repetitive, since `playlists` availability is stated twice, but every paragraph carries information.

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?

With no output schema, the description carries the return-value burden and does so for both modes, enumerating the metric families and the row shape. All 8 parameters are documented and the two required ones are explained in context.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning for `type`: per-plan availability, the error it can produce, and what each mode returns. It also reinforces the opt-in nature of `sections` and the row-at-a-time paging behavior, though the 28-day range and default limits mostly restate the 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?

Opens with a specific verb+resource ('Read the analytics of one broadcast') and immediately scopes it to a single broadcast, distinguishing it from list-level siblings. The two `type` modes are each described in concrete terms (YouTube-reported metrics vs LiveReacting-recorded playback rows).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the prerequisite source for the id (livereacting_list_broadcasts), explains when each `type` value applies, and states what to do when `playlists` returns FEATURE_NOT_AVAILABLE (tell the customer to email hello@livereacting.com). It also tells the agent to use the REST API instead when CSV export is needed.

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

All LiveReacting toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources