Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

nba_lineups

Retrieve NBA five-man lineup statistics by season and measure, returning lineup and team identifiers with counting or rate columns for analysis.

Instructions

NBA lineup dashboard. Returns the lineup dashboard for one lineup size and measure: one row per lineup with GROUP_ID, GROUP_NAME, TEAM_ID, TEAM_ABBREVIATION and the counting/rate columns for the requested measure. The payload is large — the five-man sample was about 712 KB — so request it once and page locally. GroupQuantity is pinned to the one verified size, 5.

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

Input Schema

Name	Required	Description
`season`	No	Season in YYYY-YY form; defaults to the current NBA season
`per_mode`	No	Aggregation
`league_id`	No	League id; only 00 (NBA) is verified
`season_type`	No	Season type
`measure_type`	No	Statistic family
`group_quantity`	No	Lineup size; only 5 is verified

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, the description carries the full load and does disclose two behaviors an agent could not otherwise know: the payload is very large (~712 KB for the five-man sample) and the correct strategy is a single fetch with local paging. It omits permissions, rate limits, and error behavior, but the payload-size warning is the operationally important one.

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?

Three sentences, front-loaded with purpose, then row shape, then the payload warning. Minor redundancy in restating 'lineup dashboard' immediately after the opening label, but nothing is padding.

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?

No output schema exists, and the description compensates by enumerating the returned columns (GROUP_ID, GROUP_NAME, TEAM_ID, TEAM_ABBREVIATION, plus measure columns). Combined with the payload-size and paging guidance, an agent has enough to call it correctly; only result ordering and empty-result behavior are unaddressed.

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 five of six parameters are enums, so the schema already documents everything. The description adds only that lineup size is effectively fixed at 5 and that one measure is requested at a time — marginal value over the schema, so baseline 3.

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 ('Returns the lineup dashboard') and pins down the grain: one row per lineup keyed by GROUP_ID/GROUP_NAME/TEAM_ID. That row-level framing implicitly separates it from the player-level nba_box_score siblings, though no alternative is named outright.

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?

Offers a real usage constraint — 'request it once and page locally' — driven by the 712 KB payload, and notes GroupQuantity is pinned to 5. It never says when to prefer this over the box-score or lineup siblings, and gives no when-not guidance.

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

Deploy Server