Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

nba_box_score

Fetch a traditional NBA box score for one game, returning both teams and per-player stats including minutes, points, rebounds, assists, field goals, and player IDs.

Instructions

NBA traditional box score for one game. Returns the traditional box score for one game: both teams and, per team, one row per player with player id, name, jersey number, position, starter flag, minutes, points, rebounds, assists and field goals made. The player ids are the source's stable player identity used by the player-statistics routes.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "game_id": "<game_id>"
    },
    "name": "nba_box_score"
  }
}

Input Schema

Name	Required	Description
`game_id`	Yes	Ten-digit game id from nba-scoreboard
`league_id`	No	League id; only 00 (NBA) is verified
`end_period`	No	Last period to include, 0 to 14; 0 means through the end example(14)
`start_period`	No	First period to include, 0 to 14; 0 means from the start example(0)

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations present, the description carries the full burden and largely does so: it enumerates the return shape (both teams, one row per player, specific stat fields) so the agent knows what comes back before calling. It also flags that player ids are the source's stable identity used by player-statistics routes, which is genuine cross-tool behavioral context. It omits error behavior for an invalid game_id and whether the payload is live or final.

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 definition is short and front-loaded, with the resource stated first and the return detail second. The opening two clauses are redundant, though — "NBA traditional box score for one game. Returns the traditional box score for one game" repeats the same information before adding anything new.

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 four-parameter read tool with no annotations and no output schema, the description is nearly sufficient: it substitutes for the missing output schema by describing the row structure and field list. The gaps are the absence of any differentiation from the five sibling box-score variants and no note on period-range behavior, both of which matter for correct invocation.

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 description coverage is 100%, so all four parameters including the period range and league enum are already documented structurally; that establishes the baseline 3. The description adds only the single-game framing and reinforces game_id's provenance, saying nothing about start_period/end_period semantics or the league_id constraint.

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?

"NBA traditional box score for one game" gives a specific verb-less but precise resource and scope, and the word "traditional" implicitly differentiates it from the advanced/four-factors/scoring/usage siblings. It stops short of naming an alternative explicitly, so an agent must infer the contrast rather than read it.

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 "for one game" plus the schema note that game_id comes from nba-scoreboard, so the prerequisite source is discoverable. There is no explicit when-to-use/when-not statement and no routing to nba_box_score_advanced or the other box-score variants, which is the main thing an agent would need.

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

Deploy Server