Skip to main content
Glama

Nba Search Players

nba_search_players
Read-onlyIdempotent

"Find NBA player [name]" / "search NBA roster for [X]" / "is [player] in the NBA" — search NBA players by name on BallDontLie. Returns position, height, weight, college, country, draft info, and current team. NOTE: per-season averages (PPG/RPG/APG) and career stats are NOT in this response — those require BallDontLie's ALL-STAR tier ($9.99/mo at https://www.balldontlie.io/) via the /season_averages endpoint, which is not currently exposed by Pipeworx. Free-tier _apiKey works for this tool.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "LeBron James"
    },
    "name": "nba_search_players"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoNumber of results to return (default: 10, max: 100)
queryYesPlayer name or partial name to search for
_apiKeyYesBallDontLie API key

Output Schema

NameRequiredDescriptionDefault
queryYesSearch query for player names
totalYesTotal count of matching players
playersYesList of matching players
returnedYesNumber of players returned in this response

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, open world), and the description adds genuinely useful context beyond them: the response payload, the fact that season averages and career stats are absent, and the paid-tier constraint behind that gap. It omits pagination behavior beyond the schema's limit default and says nothing about rate limits or error cases.

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?

Purpose is front-loaded and the NOT-included caveat is flagged with a clear NOTE, which is well structured. The pricing detail and the full BallDontLie URL are heavier than an agent needs, but the tier context is at least load-bearing.

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

Completeness5/5

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

An output schema exists, yet the description still summarizes the return shape and, more importantly, pre-empts the most likely agent error by stating which stats are unavailable and why. Combined with the auth-tier note, an agent has enough to call this correctly without further exploration.

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, which sets the baseline at 3. The description corroborates the name-search semantics of 'query' and clarifies that a free-tier '_apiKey' is sufficient, but adds no syntax, matching rules (partial name behavior), or limit guidance 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?

Names a specific verb and resource ('search NBA players by name on BallDontLie') and enumerates the returned fields (position, height, weight, college, country, draft info, current team). The sample-utterance prefixes make the intent unambiguous at a glance.

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?

The 'Find NBA player [name]' / 'is [player] in the NBA' phrasings give clear situational context for when to reach for this tool. It stops short of naming alternatives — notably it never says to use nba_get_player instead when you already have an ID — so there is no explicit exclusion or routing rule.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.