Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

nba_franchise_history

Retrieve NBA franchise history, including defunct teams, as league-wide active and defunct tables; pass team_id to narrow results to one franchise.

Instructions

NBA franchise history, including defunct teams. Returns every franchise's history as two tables: FranchiseHistory for active franchises and DefunctTeams for the ones that no longer play. Verified columns are TEAM_ID, TEAM_NAME, START_YEAR, END_YEAR, YEARS and GAMES. The table is league-wide and needs no team id; pass team_id only to narrow it.

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

Input Schema

NameRequiredDescriptionDefault
team_idNoOptional team id from nba-standings; narrows the history to that franchise
league_idNoLeague id; only 00 (NBA) is verified

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?

No annotations are supplied, so the description carries the full burden and does substantially well: it discloses the return shape (two separate tables), the league-wide scope, and the verified column set. It does not discuss pagination, row limits, or whether any auth is needed, which is the only meaningful gap 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.

Conciseness4/5

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

Three front-loaded sentences that move from purpose to return shape to scoping, with no filler. The column enumeration is mildly schema-like detail but it earns its place by telling the agent what fields exist without an output schema.

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?

For a simple two-parameter read tool with no output schema and no annotations, the description covers purpose, return structure, columns, and parameter scoping. 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% and the schema already documents both parameters, including that team_id 'narrows the history to that franchise' and that only league_id 00 is verified. The description restates rather than extends that meaning, so baseline 3 applies.

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 ('NBA franchise history, including defunct teams') and immediately scopes the result as two tables, FranchiseHistory and DefunctTeams. An agent can tell exactly what it gets without opening the 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 concrete calling guidance: 'The table is league-wide and needs no team id; pass team_id only to narrow it.' That states the default behavior and the one condition for narrowing, covering both parameters. No explicit exclusions or named alternatives, but none are obviously needed for a single-purpose history tool.

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