Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

nba_enums

Returns pinned NBA request enum values for league IDs, season types, measures, per modes, stat categories, scope, date/season formats, and blocked values to validate requests without upstream calls.

Instructions

List the pinned NBA request enum values. Returns the complete pinned request-enum inventory the NBA routes validate locally: league ids, season types (all four upstream values, including Pre Season and All Star), measure types, per modes, leader stat categories, the leaderboard scope, the game-date and season formats, and the values deliberately blocked because they are not verified. The upstream exposes no value-listing endpoint and answers an invalid enum with a bare HTTP 500, so these values are pinned from measured live acceptance and covered by exact-set tests. No upstream call is made.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A4.4/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 that no network call occurs, that the values are pinned from measured live acceptance rather than fetched, and — importantly — that some values are deliberately blocked because they are unverified, which an agent could otherwise misuse. What it omits is the shape of the returned inventory (keyed by category? flat list?) and whether blocked values are flagged inline.

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 and contents are front-loaded, and each subsequent sentence adds justification for why the values are hard-coded. The clause about exact-set tests is marginal for an agent selecting or calling the tool, and the reasons for pinning are restated twice (no listing endpoint; 500 on invalid enum), so a slightly tighter version would score higher.

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 zero-parameter, annotation-free, output-schema-free lookup tool, the description is nearly complete: it explains the contents category by category and why the tool exists and is trustworthy. The remaining gap is the concrete return shape — whether results are grouped by category and how 'blocked' values are represented — which the agent only learns after calling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, and the schema is empty with 100% coverage, so there is nothing for the description to disambiguate. Baseline for a no-parameter tool applies, and the description correctly explains why no inputs exist (the inventory is pinned locally).

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?

The first sentence is a specific verb plus resource ('List the pinned NBA request enum values'), and the second sentence enumerates exactly what the inventory contains (league ids, season types, measure types, per modes, leader stat categories, leaderboard scope, date/season formats, blocked values). This clearly separates it from the sibling data-returning tools like nba_games or nba_box_score, which return stats rather than valid parameter values.

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 rationale ('the upstream exposes no value-listing endpoint and answers an invalid enum with a bare HTTP 500') makes the when-to-use case evident: consult this before passing enum values to other NBA tools. 'No upstream call is made' also signals a cheap, safe lookup. It stops short of explicitly naming which sibling tools consume these enums or stating that this is the required first step, so guidance is strong but inferential.

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