Skip to main content
Glama

nba_standings

Read-only

Get one NBA season's standings and return every team's conference, division, wins, losses, win percentage, games behind, streaks and home/road splits. Use season in YYYY-YY form such as 2026-27 (defaults to the current season) and season_type Regular Season or Playoffs; only league_id 00 (NBA) is verified. Standings for an unavailable season are an upstream error, not a guessed empty table.

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

Input Schema

NameRequiredDescriptionDefault
seasonNoOptional season in YYYY-YY form, for example 2026-27. Defaults to the current NBA season.
league_idNoOptional league id; only 00 (NBA) is verified.
season_typeNoOptional season type; Regular Season or Playoffs. Defaults to Regular Season.

Output Schema

NameRequiredDescriptionDefault
dataYesThe tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly and openWorld, so the safety profile is covered; the description adds real behavioral context beyond that — that only league_id 00 is verified, that omitted parameters default rather than fail, and that an unavailable season surfaces as an upstream error rather than a fabricated empty table. Still no note on rate limits or result size, but that is minor here.

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

Conciseness5/5

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

Three tight sentences: return shape first, then calling parameters, then failure semantics. No boilerplate and nothing repeated without purpose.

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, so return values need not be explained further, and the description still covers parameters, defaults, league restriction, and error behavior. Nothing an agent needs to invoke this 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 each of the three parameters already carries its own description, defaults and value examples. The description reinforces the format and the verified-league constraint but adds no syntax or edge-case detail the schema does not already contain, 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?

States a specific verb and resource ("Get one NBA season's standings") and enumerates the return fields, so the agent knows exactly what this returns versus a box score or player-list sibling. The scope (one season, NBA) is unambiguous.

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 clear calling context: season format YYYY-YY, the two season_type values, defaults for both parameters, and the league_id 00 restriction. It does not explicitly route to alternative standings providers (e.g. espn_standings), but the usage rules for this tool itself are complete.

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.