Skip to main content
Glama

Glitchless

Match

glitchless_match
Read-onlyIdempotent

Matches of a multiplayer game, from every side (the game marks a match with setGroup('match', id), the ID its server made; every SDK hashes it the same way, so its players and its server join up). Without id: the window's matches, the most recent first, or the worst by lag (ping) or disconnects (sort), each with its level, players, outcomes, disconnects, ping and lag (the share of connected play over 150 ms), and its server's tick. With id: one match slot by slot (30 seconds) from its start, with a verdict that tells a whole lobby lagging at once (the server or its network) from one player lagging (their connection): each player's ping, frame time, outcome and disconnects, the server's ticks against its budget and the players connected in the same slots, and the match's events. slots: true gives every slot of every player.

Input Schema

NameRequiredDescriptionDefault
idNoA match id (h_… or the game's own), from the list or a finding
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.
sortNoWithout id: recent (default), lag (the worst ping p95 first) or disconnects
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.
limitNoWithout id: how many matches (default 20)
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
slotsNoWith id: every 30-second slot of every player and server (long for a big match); by default only the slots that lagged
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.3/5.0
Behavior5/5

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

Beyond the annotations, it describes what each mode returns: recent-first or sorted match lists with level, players, outcomes, disconnects, ping and lag definition; and per-slot match detail with a verdict distinguishing whole-lobby lag from one-player lag. This adds substantial behavioral context without contradicting the read-only annotations.

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 description is front-loaded and organized around the with-id / without-id split. It is dense and parenthetical in places, but the length is largely justified by the tool's two modes and rich output detail.

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 a 12-parameter tool with no output schema, the description is complete enough for an agent to understand both modes, the sort and slots behavior, and the shape of returned match data. Remaining parameter details are well covered by the schema.

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 baseline is 3, but the description adds meaningful semantics for id, sort, slots, and the hours window beyond what the schema states. It does not explain all 12 parameters, but the schema already documents them thoroughly.

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 clearly identifies the resource as multiplayer match data and distinguishes its two modes: listing a window of matches without an id, and inspecting one match slot-by-slot with an id. It does not explicitly differentiate itself from sibling tools such as glitchless_session or glitchless_network, so it stops short of a 5.

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 clear operational guidance for the main branching parameter: without id lists matches and supports sort; with id returns one match slot-by-slot, with slots: true for all players. It does not mention alternatives or when another sibling tool would be more appropriate.

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