Glitchless

Get error

glitchless_get_error

Read-onlyIdempotent

Error Tracking for a game. Without a fingerprint: the list of error issues ranked by sessions affected. With a fingerprint: the full issue — message, location, stack trace, affected levels/versions, occurrence counts and breadcrumbs (the game events right before it fired). For a minified web build whose source maps were uploaded (glitchless-sourcemaps), location and stack are the original ones, frames gives each frame with its line of code, and minified what the browser reported.

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
`fingerprint`	No	Issue fingerprint from the list or from glitchless_triage
`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

A4.3/5.0

Behavior4/5

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

Annotations already declare a safe, read-only, idempotent operation, so safety needs no restatement. The description adds genuinely non-obvious behavior: the list is ranked by sessions affected, the detail view includes breadcrumbs of preceding game events, and source-map uploads change whether locations are original or minified (with `frames` and `minified` fields). It never says how many issues the list returns or whether it is capped.

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?

The two-mode contract is front-loaded before the return-content detail, and every clause carries information. The final sentence is long and packs source-map behavior, `frames`, and `minified` together, which makes it denser than ideal but not wasteful.

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?

With no output schema, the description carries the return-shape burden alone, and it does describe both response forms plus the source-map variation. Gaps are minor: list size, ordering ties, and error/empty behavior are unaddressed for a 9-parameter tool.

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 the baseline is 3. The description still adds meaning the schema cannot: `fingerprint` is a mode switch, not just a filter, and the source-map note explains how the `location`/`stack` output differs. The remaining eight parameters are left entirely to the schema.

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?

States the resource (error issues for a game) and a specific dual behavior: a ranked list without a fingerprint, the full issue with a fingerprint. The mode split is stated up front, so an agent can distinguish this from glitchless_triage or glitchless_bug_reports without reading the schema.

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?

Explicitly tells the agent which mode applies based on whether a fingerprint is supplied, and points at glitchless_triage as the way to obtain one. It does not set out exclusions against siblings such as glitchless_bug_reports, so it stops short of full when/when-not guidance.

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?