Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

nba_pt_defend

Retrieve the NBA defensive tracking table for a chosen defended-shot category, showing player, team, frequency, and defended field-goal stats to compare defensive performance.

Instructions

NBA defensive tracking dashboard. Returns the league's defensive tracking table for one defended-shot category. Marker-verified columns are CLOSE_DEF_PERSON_ID, PLAYER_NAME, TEAM_ID, TEAM_ABBREVIATION, AGE, GP, G, FREQ, D_FGM, D_FGA, D_FG_PCT, NORMAL_FG_PCT and PCT_PLUSMINUS. The player identity column on this table is CLOSE_DEF_PERSON_ID, not PLAYER_ID.

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

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
defense_categoryNoDefended-shot category

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?

With no annotations, the description carries the full burden; it does disclose the returned column set and a genuinely useful pitfall — that the identity column is CLOSE_DEF_PERSON_ID, not PLAYER_ID, which prevents bad joins. It does not say whether the table is one row per player, how rows are ordered, whether there is a row cap, or that it is a non-mutating read, leaving meaningful behavioral gaps.

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 the tool's identity, then the returned columns, then the join-key warning in the strongest position at the end. The long column enumeration is dense but every item is information the agent cannot get elsewhere without an output schema.

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 stats-table tool with no output schema and all-optional parameters, the description supplies the return shape and the key gotcha, which is most of what an agent needs to call and use it. It stops short of stating cardinality or any caveats about the unverified non-00 league value beyond the schema enum.

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 four of five parameters are enums, so the schema already documents each parameter fully. The description adds only that the category selects a defended-shot category and restates the 00-only league constraint, so the baseline of 3 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?

The description gives a specific verb and resource: it returns the league's defensive tracking table for a single defended-shot category, and it names the player identity column. It is clearly a read-only stats-table tool, but it never names a sibling (e.g. nba_hustle_stats or nba_team_dash_pt_shots) to differentiate itself from the many other tracking/box-score tools in the catalog.

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 explicit when-to-use or when-not-to-use guidance and no alternative tool is named, so the agent must infer from the phrase 'one defended-shot category' that this is the per-player defensive matchup view. The only constraint-like guidance (league_id 00 only, defaults for season) lives in the schema rather than the description.

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