Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

nba_scoreboard

Fetch every NBA game for a specific game day, including teams, scores, status, and game IDs needed for box-score and play-by-play lookups.

Instructions

NBA scoreboard for one game day. Returns every NBA game for a game day from the league's own statistics service: game id, code, status and clock, period, and both teams with id, tricode, name, score, wins and losses. Game ids from this route are the input to the box-score and play-by-play routes. The upstream requires a game date, so a missing date defaults to the current UTC date; the NBA game day is US Eastern, so pass game_date explicitly when the exact slate matters.

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

Input Schema

NameRequiredDescriptionDefault
game_dateNoGame day in MM/DD/YYYY form; defaults to the current UTC date
league_idNoLeague id; only 00 (NBA) is verified
day_offsetNoWhole-day offset applied to the game day example(0)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A4.2/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 well: it discloses the default behavior for a missing date, the UTC-vs-US-Eastern mismatch that can silently shift the slate, and that only league_id 00 is verified. It does not cover failure modes or rate/auth constraints, but it is substantially more informative than typical for an unannotated 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.

Conciseness5/5

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

Three sentences, front-loaded with what the tool returns, then downstream linkage, then the date/timezone caveat. The field enumeration is dense but useful; 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?

For a read-only, three-optional-parameter tool with no output schema and no annotations, the description covers return contents, defaulting behavior, the timezone pitfall, and downstream tool linkage. Slightly incomplete on error behavior, but nothing an agent needs to call it correctly is missing.

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 all three parameters are already documented and the baseline is 3. The description adds the important framing that the upstream requires a date and that the NBA game day is Eastern while the default is UTC, but that timezone caveat is the only meaning genuinely added beyond the schema.

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 ('Returns every NBA game for a game day') plus the source of truth ('the league's own statistics service'), which implicitly separates it from the ESPN/Yahoo scoreboard siblings. It even enumerates the payload fields (game id, code, status, clock, period, teams, scores, records), so an agent knows exactly what it gets without opening a 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?

Gives clear context: use it for a single game day, and its game ids are the required input to the box-score and play-by-play routes, which is real routing guidance. It also tells the agent to pass game_date explicitly when the exact slate matters. It stops short of naming a competing tool (e.g. espn_scoreboard or nba_games) as the alternative for other cases.

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