Skip to main content
Glama

nba_player_bio_stats

Read-only

Get NBA league bio table. Returns the league bio table for a season: each player's height (label and inches), weight, college, country, draft year/round/number and age, with season GP and the counting stat line. Marker-verified columns are PLAYER_ID, PLAYER_NAME, TEAM_ID, TEAM_ABBREVIATION, AGE, PLAYER_HEIGHT, PLAYER_HEIGHT_INCHES, PLAYER_WEIGHT, COLLEGE, COUNTRY, DRAFT_YEAR, DRAFT_ROUND, DRAFT_NUMBER, GP, PTS, REB and AST — the complete sampled set matched.

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

Input Schema

NameRequiredDescriptionDefault
seasonNoOptional season in YYYY-YY form, for example 2026-27. Defaults to the current NBA season.
per_modeNoOptional aggregation; defaults to PerGame.
league_idNoOptional league id; only 00 (NBA) is verified.
season_typeNoOptional season type; Regular Season, Playoffs, Pre Season or All Star. Defaults to Regular Season.

Output Schema

NameRequiredDescriptionDefault
dataYesThe tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds provenance context ('Marker-verified columns... the complete sampled set matched'), which tells the agent the column set was verified, but says nothing about pagination, row volume, rate limits, or freshness beyond the default-season note.

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?

Purpose is front-loaded in the first sentence, but the long enumerated marker-verified column list and the 'complete sampled set matched' clause read like a data-quality log and consume roughly half the text without helping an agent decide or invoke. Those sentences do not fully earn their place compared with the compact field summary already given.

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?

With an output schema present and full schema coverage, the description needs only to convey scope and contents, which it does: league-wide, one row per player per season, with bio plus counting stats. Missing only minor invocation context such as expected row counts or ordering, which is acceptable given the output schema.

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% and already documents season format, per_mode default, league_id restriction, and season_type values. The description adds no parameter-level meaning beyond implying season scope, so the baseline 3 for high-coverage schemas applies.

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?

States a specific verb and resource ('Get NBA league bio table') and enumerates the returned fields (height, weight, college, country, draft info, age, GP, PTS/REB/AST), so an agent knows this is a league-wide per-player bio+stat line for a season. It does not explicitly differentiate itself from close siblings like nba_player_info or nba_player_profile_v2, which keeps it from a 5.

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 only implied: the field list and 'for a season' scope suggest this is the tool for a league-wide biographical snapshot, but there is no explicit when-to-use, when-not-to-use, or named alternative. The defaults mentioned (current season) are restated in the schema rather than acting as selection guidance.

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.