Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

nba_player_pt_shot

Retrieve NBA player shooting stats as one row per player, with overall and three-point shooting splits. Filter by season, season type, and per-game or totals aggregation.

Instructions

Returns the league's player shooting table: one row per player with the shooting line, split overall and from three. Returns the league's player shooting table: one row per player with the shooting line, split overall and from three.

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

Input Schema

NameRequiredDescriptionDefault
seasonNoOptional season in YYYY-YY form; defaults to the current NBA season.
per_modeNoOptional aggregation.
league_idNoOptional league id; only 00 (NBA) is verified.
season_typeNoOptional season type.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

C2.9/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, and "Returns" does make clear this is a non-mutating read. It also discloses the useful behavioral detail of result shape (one row per player, shooting line split overall and from three), but says nothing about season coverage limits, row volume, or what happens with the only-verified league filter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

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

The single sentence is repeated verbatim, so half the text is pure duplication and the definition looks like a copy-paste artifact. The remaining content is front-loaded and efficient, but the redundancy is a real structural defect.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-optional-parameter read tool with no output schema and no annotations, the description covers the essential return grain reasonably well. It is missing enough scope detail (what a shooting line contains, how the overall vs. three split is represented in each row, limitations of league filtering) that an agent still has open questions.

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%, with three of four parameters carrying enums, so the schema already communicates parameter meaning well. The description adds no additional semantics about how parameters interact (for example, per_mode vs. the overall/three split) beyond what the schema states.

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 concrete verb and resource ("Returns the league's player shooting table") plus the row grain ("one row per player") and the split dimension (overall and from three). It implicitly separates itself from nba_team_pt_shot by saying "player", but it never names or contrasts with close siblings such as nba_player_dash_pt_shots.

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, no preconditions, and no mention of alternatives or when this table is the wrong choice. The agent must infer the appropriate context purely from the phrase "player shooting table".

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