Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

nba_player_stats

Retrieve NBA league-wide player statistics for a chosen season, measure, and aggregation, returning one row per player with source-published stat columns and headers for accurate analysis.

Instructions

NBA league-wide player statistics table. Returns the league-wide player statistics table for one season, measure and aggregation: one row per player with the columns the source publishes for that measure, keyed by the source's own column names such as PLAYER_ID, PLAYER_NAME, TEAM_ID, GP, MIN, PTS, REB and AST. Base and Advanced are the two verified measures, and PerGame and Totals the two verified aggregations; read the response's headers list rather than assuming a fixed column set.

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_player_stats"
  }
}

Input Schema

NameRequiredDescriptionDefault
seasonNoSeason in YYYY-YY form; defaults to the current NBA season
per_modeNoAggregation; PerGame or Totals
league_idNoLeague id; only 00 (NBA) is verified
season_typeNoSeason type; Regular Season or Playoffs
measure_typeNoStatistic family; Base or Advanced

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A3.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: the result is one row per player, columns are whatever the source publishes under its own names, and the agent should read the response's headers list rather than assume a fixed column set. That is genuine operational context beyond a restatement of the name. It omits any note on missing/empty results for unsupported measure-aggregation combinations, which would have earned a 5.

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

Conciseness3/5

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

The description opens with a noun phrase that the second sentence then repeats almost verbatim ('Returns the league-wide player statistics table...'), wasting the front-loaded position. The remaining content — verified enum values and the headers-list warning — earns its place, so the waste is limited to the redundant opening rather than the whole text.

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 5-parameter, zero-required read tool with no annotations and no output schema, the description covers what the agent most needs: the output grain (one row per player), the dynamic column set, and the caveat to read headers. It lacks only guidance on defaults/empty responses and on choosing this over similarly named player-stat siblings, which keeps it short of a 5.

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 real meaning by narrowing the enums to a verified subset — Base and Advanced for measure_type, PerGame and Totals for per_mode — telling the agent which of the seven/eight enum values are actually supported. It also names example output columns (PLAYER_ID, PLAYER_NAME, TEAM_ID, GP, MIN, PTS, REB, AST), which helps the agent reason about the measure parameter.

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 gives a specific verb and resource — returns a league-wide NBA player statistics table for one season, parameterized by measure and aggregation — and the 'league-wide' scope distinguishes it from per-match or per-game siblings like nba_player_game_logs or fotmob_player_match_stats. It does not name any sibling explicitly, so differentiation is inferential rather than stated.

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

Usage Guidelines2/5

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

There is no when-to-use guidance: nothing says when to pick this over nba_player_career_stats, nba_player_bio_stats, or nba_box_score_player_track. The note about which measures and aggregations are 'verified' is parameter guidance, not tool-selection guidance, so the agent is left to infer scope from the phrase 'league-wide ... for one season'.

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