Skip to main content
Glama

Glitchless

Compare versions

glitchless_compare_versions
Read-onlyIdempotent

Compare game versions side by side, in the game's own terms first: the stats on its boards (glitchless_dashboard) and its own events per session, then the built-in measures it reports (frame time overall and per level, hitches/min, crash-free and error-free sessions, errors per session, level completion, rage-quit rate, deaths per session, geometry growth). Use it to confirm a fix or a design change after shipping a new version. Versions come in release order (when each first showed up at all, not in this window), so by default it compares the newest with the one before it, also while players of older versions still play. For a game on Steam, by "steam_branch" compares Steam branches instead (a beta against "public"), and by "steam_build" Steam builds: a and b are then branch names or build ids. By a session property ("class", "spender"; glitchless_events lists them) it compares that property's values the same way, the most sessions first (over 31 days or less): a and b are then values.

Input Schema

NameRequiredDescriptionDefault
aNoBaseline version, branch or build (default: the one before the newest)
bNoNew version, branch or build (default: newest)
byNoWhat to compare (default version): steam_branch or steam_build (a game that uses Steamworks), or a session property's key, e.g. "class"
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 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
serviceNoGame service name (defaults to the most recently active game)
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/5.0
Behavior4/5

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

Annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds useful behavioral context about release-order comparison, default newest-vs-previous behavior, branch/build/session-property modes, and daily aggregation beyond 31 days, though it does not describe the response shape in detail.

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, but the description is long and dense, with several convoluted sentences and parenthetical clauses. The complexity justifies some length, yet the structure could be clearer and more scannable.

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?

Given nine parameters, nested props, and no output schema, the description covers the core comparison behavior and modes well. It does not fully explain the return format or response organization, but it lists the built-in measures and aggregation behavior sufficiently for an agent to call it correctly.

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 coverage is 100%, so the schema already documents all nine parameters. The description adds some meaning around by-mode comparisons and defaults for a and b, but most parameter semantics remain schema-driven rather than elaborated in the description.

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 states a specific verb and resource: compare game versions side by side. It enumerates the compared measures and explicitly references related tools such as glitchless_dashboard and glitchless_events, making it distinguishable from sibling analytics tools.

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: confirming a fix or design change after shipping a new version. It also explains comparison modes and defaults for versions, Steam branches/builds, and session properties, though it does not explicitly state when not to use it or name a direct alternative comparison tool.

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