Skip to main content
Glama

Glitchless

Player funnel

glitchless_player_funnel
Read-onlyIdempotent

Player experience per level: sessions that started vs completed each level, attempts, deaths per session and their causes, fails, abandons and the attempts a disconnect ended (never counted as fails), median and slowest clear times, rage quits (quit ≤20s after dying), session length distribution and recent rage quits with positions. With by, each level per value of what describes the attempt: an attribute the game passed to levelStart ("tier", "difficulty", "party_size"; a list such as "build" counts under each element), a session property ("$class") or a split ("$platform"): clears and wipes by difficulty, by group size, by class; level keeps one level; count "runs" counts each run once at each level it reached (a roguelite's biomes). Also retention: of the players first seen each day, the share back 1, 7 and 30 days later (D1, D7, D30; hours of 48 or more for D1), and with by_prop per value of a session property (spenders against the rest). Retention needs player IDs: status "anonymous" means the game sends none, and privacy "install" in the SDK turns them on.

Input Schema

NameRequiredDescriptionDefault
byNoSplit each level's attempts: an attribute of its levelStart ("tier"), a session property ("$class") or $platform, $browser, $device_tier, $link
envNoOnly include sessions from this environment, e.g. "prod" (what the game passes to init; builds a developer runs usually send "dev")
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.
countNo"runs": each run (setGroup("run")) counted once at each level it reached
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.
levelNoWith by or count: only this level
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
by_propNoRetention per value of this session property, e.g. "spender"
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

A4.6/5.0
Behavior5/5

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

It adds critical behavioral context not in the schema or annotations, such as how 'runs' are counted (once per level reached), how disconnect events are categorized (not counted as fails), and the data limitations regarding retention privacy ('anonymous' vs. 'install' SDK status).

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 description is extremely dense and spans multiple paragraphs covering numerous metrics and logic branches. While every sentence is functional, the overall structure is overwhelming and lacks the front-loaded, quick-scan nature expected of an ideal tool definition.

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 complexity of calculating funnels, retention (D1, D7, D30), and session metrics, the definition is maximally complete. It covers the data returned, the grouping mechanism, the filtering logic, and operational caveats.

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?

Although the schema is 100% covered, the description adds crucial semantic value by explaining the operational logic of parameters. For example, it clarifies that the 'by' parameter can accept game attributes ('tier'), session properties ('$class'), or technical splits ('$platform').

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 functions as a comprehensive document detailing player experience metrics across levels. It is clearly distinct from other sibling tools like glitchless_overview or glitchless_events because it specifically aggregates flow, failure rates, and retention.

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?

While the description is massive, it acts as an exhaustive guide, explicitly detailing how specific variables (`by`, `count`, `by_prop`) alter the resulting view, which serves as a usage guide for complex queries.

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