Skip to main content
Glama
DanielTomaro13

sportsdata-mcp

by DanielTomaro13
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

nbl_season_current

Read-onlyIdempotent

Retrieve the current NBL season(s) with an optional row limit. Returns season IDs, names, years, types, external IDs, and start/end dates, resolving even when no season is active.

Instructions

The current season(s). Convenience shortcut over nbl_seasons; may return empty in the deep off-season (the call still resolves). Use limit to cap rows.

Returns: {type, count, data:[{id, name, year, season_type, external_id, start_date, end_date}]}

Auth: none needed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax rows (default 1).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.24.0
    • addedInput schema / properties / limit / description
      Added value: +"Max rows (default 1)."
  2. Addedv0.1.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover read-only/idempotent safety, but the description adds valuable behavior: it may return empty in the deep off-season yet still resolve, and includes the exact return shape. It also states auth is not needed. No contradiction with annotations.

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?

The description is compact and front-loaded with the main purpose. Every sentence contributes: purpose, shortcut relationship, off-season caveat, limit usage, return shape, and auth. No filler.

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 read tool with one optional parameter and no output schema, the description is fully adequate. It includes return structure, edge-case behavior, and auth info. No significant gaps.

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?

The input schema fully documents the single `limit` parameter (default 1, max rows). The description repeats this via 'Use `limit` to cap rows' without adding new meaning, so baseline 3 for high schema coverage.

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 description clearly states this tool returns current season(s) and explicitly positions it as a convenience shortcut over nbl_seasons, distinguishing it from that sibling. The verb and resource are specific, and the off-season behavior is noted.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names nbl_seasons as the broader tool this shortcuts, and warns that results may be empty in the deep off-season, which provides practical context for when this tool is appropriate. The mention of the `limit` parameter also aids usage.

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