Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

nba_player_bio_stats

Access NBA player biographical and season stat data for any season: height, weight, college, country, draft details, age, games played, points, rebounds, and assists in one table.

Instructions

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
seasonNoSeason in YYYY-YY form; defaults to the current NBA season
per_modeNoAggregation
league_idNoLeague id; only 00 (NBA) is verified
season_typeNoSeason type

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

B3.2/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full disclosure burden. It does credibly describe the returned payload, listing the exact columns and noting they are marker-verified as a complete sampled set, which compensates for the absent output schema. It says nothing about permissions, ordering, row cardinality, or whether the counting columns are per-game averages despite per_mode being fixed to PerGame, so key behavioral questions remain open for a read tool.

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?

Purpose is front-loaded in the first sentence, and the second sentence's column list earns its space because no output schema exists. The opening slightly repeats itself ('NBA league bio table. Returns the league bio table...'), and the marker-verification clause is more internal provenance than agent-facing guidance, but the text is compact overall.

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 no annotations and no output schema, the description does the necessary work of defining the return payload and confirming column coverage, which is what an agent needs before calling. Residual gaps are row granularity (one row per player?), sort order, and any pagination or rate-limit limits, none of which are stated. Given a four-parameter, fully-documented schema, these omissions are moderate rather than disqualifying.

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 three of four parameters carry enums, so the schema already documents season format, default-to-current-season behavior, and the single allowed values for per_mode, league_id, and season_type. The description adds no parameter meaning beyond that; it never mentions season form or the fact that only league 00 and Regular Season are verified, which is the kind of constraint prose could have surfaced.

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 states a specific verb and resource: it returns a per-player league bio table for a season, and enumerates the fields (height, weight, college, country, draft, age) plus GP and the counting stat line. That is far more specific than the name alone. It does not, however, explicitly distinguish itself from close siblings such as nba_player_stats or nba_player_career_stats, leaving the agent to infer the boundary from the field list.

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 and no named alternative. Nothing tells the agent to prefer this over nba_player_stats or nba_player_career_stats when it needs biographical attributes rather than box-score production. Usage is only inferable from the enumerated fields, which is weak routing guidance in a catalog this dense with player-stat siblings.

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