Glitchless

Overview

glitchless_overview

Read-onlyIdempotent

Headline KPIs for a game: sessions, players, crash-free and error-free sessions, frame-time p50/p95/p99 vs budget, hitches per minute, rage quits, top errors and the level funnel.

Input Schema

Name	Required	Description
`env`	No	Only include sessions from this environment, e.g. "prod" (what the game passes to init; builds a developer runs usually send "dev")
`game`	No	The 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.
`hours`	No	Look-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.
`props`	No	Only 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
`service`	No	Game service name (defaults to the most recently active game)
`version`	No	Only include sessions from this game version
`session_type`	No	"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_branch`	No	Only 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.

First observedOct 26, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and closed-world, so the safety profile is covered. The description adds the scope of what is returned (the metric set) but says nothing about defaults (24h window), aggregation behavior, or truncation limits, which matter for a summary endpoint with no output schema.

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?

A single front-loaded sentence with no filler, and the KPI list is genuinely informative. It is a bare noun phrase with no verb, which slightly weakens the framing but wastes no words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacking an output schema, the description usefully enumerates the returned metrics, which is the main thing an agent needs. However, for an 8-parameter aggregation endpoint it omits defaults, the effect of the filters on the answer, and routing versus sibling overview tools, leaving real gaps.

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% and the parameter descriptions are unusually detailed (env, props, hours/day rollover, session_type defaults). The description contributes nothing about parameters, so the baseline 3 applies — it neither helps nor hurts.

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 enumerates the exact contents (sessions, players, crash-free/error-free sessions, frame-time percentiles, hitches, rage quits, top errors, level funnel) for a specific resource: a game's headline KPIs. It never says how this differs from close siblings like glitchless_dashboard, glitchless_performance, or glitchless_player_funnel, so an agent must guess which overview to call.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool, when not to, or which alternative to prefer. With 17 siblings including a dashboard, a performance tool, and a funnel tool that overlap heavily with the listed metrics, this absence is costly.

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

All Glitchless tools Inspect

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

Need Help?