Skip to main content
Glama

Get League Health (commissioner report)

fantasy_get_league_health
Read-onlyIdempotent

THE COMMISSIONER REPORT for one league: competitive balance (points-for or win% spread), this week's blowouts, and which teams look checked out (inactive-heavy rosters). For "is my league healthy/competitive", "who's tanking", or a state-of-the-league summary.

Input Schema

NameRequiredDescriptionDefault
sportNoe.g. 'NFL', 'NBA'. Needed for ESPN/Sleeper and Fantrax name lookups.
seasonNoSeason year, e.g. 2025; ignored by Fantrax.
providerNoFantasy platform. Optional: defaults to your connected platform ('sleeper').
league_idNoOmit when connected. League id (Fantrax also takes the league URL).
league_queryNoA connected league's name/id; omit to auto-pick (primary first). Never ask for ids.
response_formatNo'markdown' (default, most compact) or 'json' (same normalized data, not the raw payload).markdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / season / anyOf
      Previous value: -[
      -  {
      -    "type": "integer"
      -  },
      -  {
      -    "type": "string"
      -  }
      -]New value: +[
      +  {
      +    "maximum": 9007199254740991,
      +    "minimum": -9007199254740991,
      +    "type": "integer"
      +  },
      +  {
      +    "type": "string"
      +  }
      +]
  2. Changed5 schema fields changed
    • changedInput schema / properties / league_id / description
      Previous value: -"The platform's league id (Fantrax also accepts the full league URL)."New value: +"Omit when connected. League id (Fantrax also takes the league URL)."
    • changedInput schema / properties / league_query / description
      Previous value: -"League name/id filter, for when the profile has several leagues on the provider."New value: +"A connected league's name/id; omit to auto-pick (primary first). Never ask for ids."
    • changedInput schema / properties / response_format / description
      Previous value: -"'markdown' (default) or 'json' (raw payload)."New value: +"'markdown' (default, most compact) or 'json' (same normalized data, not the raw payload)."
    • changedInput schema / properties / season / description
      Previous value: -"Season year, e.g. 2025. Required for ESPN/Sleeper league discovery; ignored by Fantrax."New value: +"Season year, e.g. 2025; ignored by Fantrax."
    • changedInput schema / properties / sport / description
      Previous value: -"Sport, e.g. 'NFL', 'NBA', 'MLB', 'NHL'. Required for ESPN/Sleeper and Fantrax name lookups."New value: +"e.g. 'NFL', 'NBA'. Needed for ESPN/Sleeper and Fantrax name lookups."
  3. Changed7 schema fields changed
    • changedInput schema / properties / league_id / description
      Previous value: -"The league id from the platform. For Fantrax, a full league URL is also accepted and the server extracts the id."New value: +"The platform's league id (Fantrax also accepts the full league URL)."
    • changedInput schema / properties / league_query / description
      Previous value: -"Optional profile league name/id filter. Use when the profile has multiple leagues for the provider."New value: +"League name/id filter, for when the profile has several leagues on the provider."
    • changedInput schema / properties / provider / description
      Previous value: -"Fantasy platform: 'fantrax', 'espn', or 'sleeper'. Call fantasy_list_providers first to see each provider's capabilities and required credentials."New value: +"Fantasy platform. Optional: defaults to your connected platform ('sleeper')."
    • changedInput schema / properties / response_format / description
      Previous value: -"Output format: 'markdown' (default, human-readable) or 'json' (raw upstream payload)."New value: +"'markdown' (default) or 'json' (raw payload)."
    • changedInput schema / properties / season / description
      Previous value: -"Season year, e.g. 2024. REQUIRED for espn and sleeper league discovery; ignored by fantrax."New value: +"Season year, e.g. 2025. Required for ESPN/Sleeper league discovery; ignored by Fantrax."
    • changedInput schema / properties / sport / description
      Previous value: -"Sport, e.g. 'NFL', 'NBA', 'MLB', 'NHL'. Required for ESPN/Sleeper and for Fantrax player/name lookups."New value: +"Sport, e.g. 'NFL', 'NBA', 'MLB', 'NHL'. Required for ESPN/Sleeper and Fantrax name lookups."
    • removedInput schema / required
      Removed value: -[
      -  "provider"
      -]
  4. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds that output is a derived analytical report (spread-based balance, inactivity-aware 'checked out' detection) rather than raw records, which matters since no output schema exists. It does not disclose cost, latency, or failure modes such as an unresolvable league.

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?

Two sentences, zero filler, with the identity of the report front-loaded before the component breakdown and the example intents. Every clause either names content the tool produces or a query it answers.

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?

With no output schema, the description correctly spends its words on what the report contains, which is the main thing an agent cannot learn elsewhere; parameters are fully covered by the schema. The remaining gap is scope boundary against fantasy_get_weekly_digest and fantasy_get_standings.

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 description coverage is 100% and every parameter is documented in-schema (provider defaults, season ignored by Fantrax, league_query auto-pick), so the baseline is 3. The description only implies single-league scoping ('for one league') and adds no syntax or format detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific composite resource ('THE COMMISSIONER REPORT for one league') and enumerates its three components: competitive balance spread, this week's blowouts, and checked-out teams. An agent can broadly tell it apart from raw-data siblings like fantasy_get_standings or fantasy_get_rosters, but it never contrasts itself with the nearby fantasy_get_weekly_digest, which sounds similar in scope.

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 triggering intents: 'is my league healthy/competitive', 'who's tanking', or a state-of-the-league summary. However, it offers no when-not guidance and no explicit alternative for agents that only need raw standings (fantasy_get_standings) or a general digest (fantasy_get_weekly_digest).

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.

Resources