Skip to main content
Glama

get_game

Retrieve a stored chess game move by move from cached analysis, including evaluations, win chances, move classes and flagged mistakes; filter by ply range to review key positions.

Instructions

One cached game move by move, from the stored analysis (no engine is run).

game is a game_id or a chess.com game link. Pass username so meta.my_color is set. ply_from/ply_to are an inclusive range. only_flagged keeps just inaccuracies, mistakes and blunders of either side, plus the ply before and after each (marked "context": true).

Conventions:

  • ply 1 is White's first move, ply 2 Black's first; Black's n-th move is ply 2n.

  • eval_before/eval_after are always from WHITE's point of view: {"cp", "mate"}. cp is clipped to +-1000. When a mate is known, cp is null and mate is the number of moves (positive = White mates). mate 0 = the position is checkmate ("mated" names the loser).

  • win_chance_before/after and wp_loss (0-100 scale) are from the point of view of the side that MADE the move, the same as worst_moments. class is best/good/inaccuracy/mistake/ blunder, using the same thresholds as the reports. No opening-book detection exists.

  • Every win chance, loss and percentage in every tool is rounded to 1 decimal, halves up, so the same move reads the same everywhere. Classes use the unrounded value.

  • mate_before_mover: N when the mover had a forced mate in N before moving. missed_mate: N when the move left no mate for the mover (class is NOT changed by this, a missed mate can still read "good"). mate_lengthened: {"from": N, "to": M} when a mate survives but takes more than N-1 moves. All null when there was no mate or the mate data is unknown (see meta.mate_data and the note). only_flagged also keeps a missed mate of 5 moves or fewer.

  • motifs: why a costly move (mistake, blunder, or a mate of 5 moves or fewer let go) was costly, e.g. ["moved_piece_hangs"], ["untagged"] when no rule fits. [] = not costly enough to tag; null = costly but not tagged yet (run tag_motifs). motif_details carries extras such as {"allowed_fork": {"with_check": true}}.

  • best_san/best_uci are null when the move played was the engine's best; best_pv_san (up to 5 plies, starts with the best move) is still given, or null if not stored.

  • clock_after is seconds left after the move; time_spent includes the increment. Both are null when the game has no clock data.

  • An unanalysed game returns SAN/UCI/FEN/clock with all evaluation fields null.

Input Schema

NameRequiredDescriptionDefault
gameYes
ply_toNo
ply_fromNo
usernameNo
include_pvNo
only_flaggedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so richly: it discloses cached/no-engine behavior, evaluation perspective, clipping, rounding, class thresholds, mate-field semantics, only_flagged filtering, motif semantics, clock null behavior, and what an unanalysed game returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but front-loaded and dense with useful conventions. Every section earns its place by clarifying return values, filtering, or edge cases, and there is no fluff.

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 no output schema and no annotations, the description is largely complete for interpreting the game data and its edge cases. It falls short of full completeness because include_pv is undocumented and there is no explicit read-only or error-handling note.

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 0%, so the description must explain parameters, and it does well for game, username, ply_from/ply_to, and only_flagged. The notable gap is include_pv, which is never mentioned despite affecting the returned PV data.

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 opens with a specific verb and resource: retrieve one cached game move by move from stored analysis, explicitly noting no engine is run. That scope distinguishes it from analyze_games and list_games even without naming them.

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

Usage Guidelines3/5

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

Usage is implied by the opening scope and parameter notes, such as using this to read an already-analysed single game and passing username to set meta.my_color. However, it never explicitly says when to choose this over siblings like list_games, analyze_games, or worst_moments, nor when not to use it.

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