Skip to main content
Glama
Sign In

Crawlora MCP

by net.crawlora
OverviewDiscussionsAdmin

nba_player_dash_pt_reb

Read-only

Get NBA player rebound dashboard. Returns one player's rebound dashboard: the rebound-type and distance-range breakdowns the upstream computes, as several result sets. Use it when you need one player's rebounding breakdown before or alongside nba-player-stats and nba-player-dash-pt-shots; player_id is required and comes from nba-players, and the dashboard scope set is fixed by the service.

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

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.
player_idNoRequired player id from nba-players or nba-team-roster, for example 1628398.
season_typeNoOptional season type; 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

A4.1/5.0
Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries the rest and does add value: it discloses that results come back as several result sets with upstream-computed breakdowns, and that the dashboard scope set is fixed by the service, which constrains how the agent should invoke it. It does not cover result size, pagination, or whether an unknown player id yields an empty or error response.

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?

Two sentences, front-loaded with purpose, followed by the usage cue and prerequisites. The final sentence packs several clauses together and is slightly run-on, but nothing is redundant.

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 five-parameter read-only dashboard tool with an output schema and full schema coverage, the description supplies what the structured fields cannot: what the dashboard contains, how it is returned, and where it sits relative to sibling tools. Only the fixed-scope caveat and the player_id-required assertion are left slightly under-explained.

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. The description adds provenance for player_id (comes from nba-players) and notes the scope set is fixed, which is useful, but it also asserts player_id 'is required' while the schema lists the parameter as nullable with no required list — a minor mismatch the agent must reconcile.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/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 player rebound dashboard') and immediately clarifies the scope: one player's rebound-type and distance-range breakdowns. It names the neighboring tools it complements (nba-player-stats, nba-player-dash-pt-shots), so an agent can place it among siblings without opening the schema.

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

Usage Guidelines4/5

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

Explicitly says when to reach for it ('when you need one player's rebounding breakdown before or alongside...') and names two alternative/complementary tools. It lacks an explicit when-not or a direct contrast with the team-level rebound dashboard, which keeps it below a 5.

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

All Crawlora MCP toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources