Skip to main content
Glama

Glitchless

Events

glitchless_events
Read-onlyIdempotent

The game's own metrics, from the custom events it sends with track() and the streams it counts with count() (marked counted: summed on the device per window, so their numbers have sums and averages but no spread): each event's count in the window, the sessions and players that sent it, how its attribute values break down (for example plays by mode, paywall views by placement, purchases started vs done; a list attribute such as a deck by element, each event counted once under each), the sums of its numeric attributes per currency (revenue: the amount of purchase events) and their p50, p90 and p99, and hours, the hours played in the window, to turn any count into a rate per hour. Give funnel to count the sessions that went from one event to the next, in that order. With name and rate (a flag such as "won", or a word outcome "result=win") or avg (a numeric attribute), it measures that event: overall, or with by per value (win rate by hero, with a 95% interval for each, next to the overall rate). With name and of (a numeric attribute), it gives that attribute's distribution: percentiles and a histogram, optionally by a split. properties lists what the game set for its sessions with setProperties (rank, class, region, a preset), each with its values and their sessions and players; identifier_like marks one with more than 200 values a day, which is an ID rather than a property. Every read tool filters by them (props) and splits by them (by "$rank").

Input Schema

NameRequiredDescriptionDefault
byNoWith rate, avg or of: split by an attribute (a list splits by element), $version, $level, $zone, $platform, $browser, $device_tier, $link (the kind of connection), or a session property ("$rank")
ofNoA numeric attribute whose distribution to give, e.g. "duration_s" (match length) or "placement"
avgNoA numeric attribute's mean per event, e.g. "duration_s"
envNoOnly include sessions from this environment, e.g. "prod" (what the game passes to init; builds a developer runs usually send "dev")
minNoWith rate or avg and by: the fewest events a row needs (default 30 for a rate, 10 for an average); smaller rows are counted in small
gameNoThe game, by name or id, when signed in to a workspace (glitchless_list_games lists them); later calls keep it. Ignored with a key for one game.
nameNoOnly this event, e.g. "paywall". With rate, avg or of, the event to measure; it can carry a filter like a panel's event: "match_end:mode=ranked", or "battle_end:deck=hog_rider+ice_spirit" for decks with both
rateNoThe share of the event's events where a flag holds ("won": true or false, or 1 or 0) or a word outcome holds ("result=win")
hoursNoLook-back window in hours (default 24), as far back as the workspace keeps data on Glitchless Cloud (the answer says when it starts later than asked). Past 744 (31 days) answers are by day.
propsNoOnly sessions with these session properties (what the game set with setProperties): { rank: "diamond" }, or a list of values for any of them, { rank: ["diamond", "master"] }; "(none)" keeps the sessions without one. glitchless_events lists the properties and their values. Read from the sessions, so over 31 days or less
funnelNoSteps in order, comma-separated: "open,paywall,buy". A step can require a value: "buy=done" (any attribute) or "buy:step=done"; a list matches when it has the value
serviceNoGame service name (defaults to the most recently active game)
versionNoOnly include sessions from this game version
session_typeNo"user": players only; "tester": people on TestFlight and other test builds only; "synthetic": bots, playtests and store test devices only; "all" or unset: every session. Findings (glitchless_triage, and the overview's) read the production sessions of players unless env or session_type is given
steam_branchNoOnly include sessions that ran this Steam branch ("public", or a beta's name); games that use Steamworks send it

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

With annotations already declaring a safe read-only, idempotent operation, the description adds substantial context: counted events are summed on-device per window so they have no spread, identifier_like flags properties with more than 200 values a day, past 744 hours answers are by day, and min defaults to 30 for rates and 10 for averages. It also explains session_type defaults for findings. It stops short of discussing rate limits, auth, or error behavior, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is dense and mostly relevant, but it is delivered as one long, heavily parenthetical paragraph rather than being structured for scanning. For a 15-parameter tool some length is warranted, yet the run-on structure and the confusing `properties` clause reduce clarity.

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 complex, multi-mode analytics tool with no output schema, the description covers the important output concepts (counts, sessions, players, breakdowns, currency sums, percentiles, hours) and key caveats (device-summed counted events, day granularity beyond 744 hours, row-size thresholds). It does not describe the response shape or the undocumented `properties` mode, leaving minor gaps.

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 per-parameter meaning is already documented, but the description adds real value by explaining mode combinations: name plus rate or avg measures an event, adding by gives per-value rates with 95% intervals, and name plus of produces a distribution with optional split. The one flaw is the reference to a `properties` mode that has no corresponding input parameter, which introduces ambiguity.

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 resource (the game's custom events from track() and count()) and enumerates the metrics returned: counts, sessions/players, attribute breakdowns, sums, percentiles, and hours. It is clear what the tool does, but it never explicitly differentiates itself from siblings like glitchless_player_funnel, which overlaps on funnel analysis.

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?

It explains how to trigger each mode (funnel, rate, avg, of, by) and mentions that every read tool filters via props, but it gives no explicit guidance on when to choose this tool over glitchless_overview, glitchless_revenue, or glitchless_player_funnel. Usage is implied by the capability list rather than by selection criteria or exclusions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources