Skip to main content
Glama

Player game logs

get_game_logs
Read-onlyIdempotent

A player's box score line for each past game, newest first: minutes, opponent, home or away, and every stat. Use for recent form and for prop model features. Pass player_id (from get_projections or find_players), or player and league, with last for the most recent N games. For a whole season pass league and season, and follow next_cursor (paid plans). Free plan: the last 10 games per player, and no season-wide reads. Stats are loaded for only some leagues: meta.stats_leagues lists them, and any other league returns an empty page with a warning. SOCCER and TENNIS read every competition listed under them.

Input Schema

NameRequiredDescriptionDefault
dateNoOne game date, league local.
lastNoThe player's most recent N rows matching the filters. Needs one player. limit and cursor are ignored.
teamNoOnly this team's players: a code (BOS) or team id (tm_...). Needs a season or date range unless a player or opponent is also sent.
viewNocompact is a flat row for bulk reads and allows limit up to 1000. full adds ids, scores and game context, with limit up to 200.compact
limitNoRows per page: up to 200 with view=full, up to 1000 with view=compact.
cursorNometa.next_cursor from the preceding page. Send the same filters.
leagueNoLeague code, for example NBA. meta.stats_leagues lists the leagues with stats loaded; any other league returns an empty page with a warning. A segment league from a projection row (NBA1Q) reads as its full league. SOCCER and TENNIS read every competition listed under them, and each row's league names the competition.
playerNoExact player name, case-insensitive. Needs league. A name shared by two players returns 400 listing their ids.
seasonNoSeason label, as listed in meta.coverage.seasons: 2025-26, or 2026 in single-year leagues.
end_dateNoGames on or before this league-local date. For a feature as it stood before a game, set this to the day before.
opponentNoOnly games against this team: a code or team id.
positionNoPosition as the box score lists it, for example G, F or C.
player_idNoA player_id (pl_...) from /players or /projections, or a stats_player_id (sp_...) from /results. A pl_ id needs no league. An sp_ id needs league.
start_dateNoGames on or after this league-local date.
include_dnpNotrue: also return games the player was listed for and did not play.
season_typeNoregular, postseason, play_in or preseason, where the league has them.
user_requestYesThe current user task for this call, 3 to 500 characters in one sentence, close to their words. Required on every data call, including follow-ups and pagination. Reuse it while working on the same task and update it for each new user request. Do not ask the user again if their goal is already clear. If no person asked, as in a scheduled job, say what the job is for. Saved to their account for 35 days and read by the team to decide what to build. Leave out names, contact details and anything private.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds real behavioral context the schema does not: newest-first ordering, free-plan row caps, empty-page-with-warning behavior for unloaded leagues, and paid-plan cursor pagination. It does not say what meta looks like beyond next_cursor and stats_leagues, which is minor.

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?

Front-loads what a row is, then id options, then access limits and league coverage; every sentence carries a constraint. Slightly dense and the SOCCER/TENNIS sentence reads as an appended caveat rather than part of the flow.

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?

For a 17-parameter, output-schema-less list tool this covers the correctness essentials: id resolution, pagination, plan gating, and which leagues have stats. Return-shape detail (what compact vs full rows look like) is left to the schema, which is acceptable, and meta fields beyond next_cursor/stats_leagues go unmentioned.

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, but the description adds cross-parameter semantics the schema only states locally: last is tied to a single player, and the season-wide read needs league+season plus cursor following. It reinforces the meta.stats_leagues and SOCCER/TENNIS league expansion rules that govern whether a query returns rows at all.

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 a specific verb+resource (a player's box score line per past game) with field detail (minutes, opponent, home/away, every stat) and distinguishes itself from get_projections, find_players and get_results by pointing at them for ids.

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

Usage Guidelines5/5

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

Explicitly names uses (recent form, prop model features), the two id paths (player_id from get_projections or find_players, or player+league), and the season-wide path with next_cursor. It also states what does not work: free plan limits to last 10 games and no season-wide reads, and leagues without stats return an empty page.

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