Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

nba_league_game_log

Retrieve an NBA season game log by team or player to analyze each game's date, matchup, result, minutes, points, and plus-minus, ordered chronologically or newest-first.

Instructions

NBA game log for a season, by team or by player. Returns every game in a season as the league's game log. With player_or_team=T each row is one team-game and carries GAME_ID, TEAM_ID, GAME_DATE, MATCHUP, WL, MIN, PTS, PLUS_MINUS and VIDEO_AVAILABLE; with player_or_team=P each row is one player-game (the same identity columns plus PLAYER_ID and PLAYER_NAME) and the payload grows to several hundred KB. direction orders the log newest-first (DESC) or chronologically (ASC).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "nba_league_game_log"
  }
}

Input Schema

NameRequiredDescriptionDefault
seasonNoSeason in YYYY-YY form; defaults to the current NBA season
sorterNoSort key; only DATE is verified
directionNoOrdering; ASC or DESC
league_idNoLeague id; only 00 (NBA) is verified
season_typeNoSeason type
player_or_teamNoT for one row per team, P for one row per player

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full burden and does substantial work: it enumerates the returned identity/stat columns per mode and warns that the player-mode payload "grows to several hundred KB", which is a genuinely useful cost signal an agent could not otherwise anticipate. Remaining gaps are auth, rate limits, and any pagination or truncation behavior for the large payload.

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 purpose and mode split are front-loaded in the first sentence, and the column list and payload-size warning follow in a tight semicolon-chained structure with no filler. Every clause conveys information an agent would otherwise have to discover by calling the tool.

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 six-parameter, zero-required, no-output-schema tool, the description compensates well by naming the returned fields and flagging the large player-mode payload. It could be complete with a note on default behavior when parameters are omitted (the schema mentions a default season but nothing else) and on the enum-vs-description mismatch.

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 coverage is 100%, so the baseline is 3, and the description does add row-shape meaning for player_or_team and ordering meaning for direction that the bare enum does not convey. However, it partially conflicts with the schema constraints by describing ASC and player_or_team=P as usable while the schema enums only admit DESC and T, leaving the agent unsure which is authoritative.

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 opens with a specific resource and verb ("NBA game log for a season, by team or by player") and then distinguishes the two row shapes produced by player_or_team, so an agent knows this is a season-wide league log rather than a single-game view. It stops short of differentiating itself from siblings like nba_team_game_logs or nba_player_game_logs, which the dual-mode framing arguably overlaps with.

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?

Guidance is implied rather than stated: the T/P explanation tells you how to pick a mode, but there is no explicit when-to-use-this versus when-to-use-a-sibling rule, despite sibling tools that clearly overlap. The reader must infer that this tool is the general season-wide log and the siblings are per-entity variants.

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

Deploy Server

Other Tools