Skip to main content
Glama

Glitchless

Revenue

glitchless_revenue
Read-onlyIdempotent

The game's real revenue as RevenueCat or Stripe counts it, for a game connected to either in Glitchless Cloud (Settings → Integrations); a game with both gets both unless source picks one. RevenueCat counts production purchases only (never sandbox, TestFlight or licence-tester ones): revenue and transactions by UTC day, MRR, active subscriptions and trials, installs (its new customers: the first time its SDK starts on a device) next to the new players Glitchless saw, active users a day next to Glitchless's players a day, and, where RevenueCat splits them, revenue by the app version purchases were made on, installs, revenue and purchases by country, and revenue by store (App Store, Google Play) next to the sessions Glitchless measured on iOS and Android. Stripe is the game's own account (a web or PC game's unlock, DLC, supporter packs; a test-mode key says so): revenue by UTC day with refunds, disputes, Stripe's fees and net, new paying customers, revenue by product and by country, and revenue by version and platform for the purchases the game tied to a Glitchless session or player (client_reference_id, or glitchless_session / glitchless_player metadata), with how many players paid. Both give revenue per player Glitchless measured, each day next to its sessions and players, each version next to its players, crash-free sessions and frame-time p95, and what the game's own purchase events (track('purchase', { amount, currency })) add up to: the gap is purchases that never reach Glitchless. Use it for money questions, e.g. whether 1.4.2 earns more per player than 1.4.1, or which DLC gets refunded. Use glitchless_events for purchases by item, level or player.

Input Schema

NameRequiredDescriptionDefault
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.
hoursNoLook-back window in hours (default 720, 30 days), read as whole UTC days
sourceNoOnly this revenue source (default: every one the game is connected to)
serviceNoGame service name (defaults to the most recently active game)
versionNoOnly this version: its revenue (where RevenueCat splits revenue by version, or Stripe's purchases joined to that version's sessions) over its players. MRR, subscriptions and trials, and Stripe's refunds and fees, stay the whole game's
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

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the read-only annotations, the description discloses substantial behavior: RevenueCat production-only counting, Stripe test-mode caveats, how version scoping interacts with game-wide metrics, and how Glitchless joins purchases to its own session/player data. This is unusually rich operational context.

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 purpose is front-loaded and the content is relevant, but the description is a very dense single paragraph with long semicolon-chained sentences. It could be structured more clearly without losing the important distinctions.

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?

For a complex revenue tool with no output schema, the description thoroughly explains what data is returned, how each source is treated, and key caveats. An agent has enough context to use it correctly for the intended money questions.

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 parameter definitions already do most of the work. The description adds semantics for `source` and some caveats around `version`, but it does not add much meaning for `hours`, `game`, or `service` beyond what the schema states.

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 names a specific resource, revenue, and precisely scopes it to RevenueCat and/or Stripe data for a connected game. It clearly distinguishes what the tool returns from `glitchless_events` and makes the source-specific coverage explicit.

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?

It gives a clear intended use case for money questions and explicitly routes item/level/player purchase analysis to `glitchless_events`. It lacks explicit exclusions against other analytical siblings like `glitchless_overview`, but the guidance is strong.

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