Skip to main content
Glama

Get Fantasy Standings

fantasy_get_standings
Read-onlyIdempotent

League standings: rank, record, points for/against. Profile-first: league inferred when connected. ESPN/Sleeper mark your row ⭐ automatically; Fantrax needs team_query.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sportNoSport, e.g. 'NFL', 'NBA', 'MLB', 'NHL'. Required for ESPN/Sleeper and Fantrax name lookups.
seasonNoSeason year, e.g. 2025. Required for ESPN/Sleeper league discovery; ignored by Fantrax.
providerNoFantasy platform. Optional: defaults to your connected platform ('sleeper').
league_idNoThe platform's league id (Fantrax also accepts the full league URL).
team_queryNoYour team's exact id (preferred) or a unique name fragment; marks it ⭐. Required on Fantrax (no owner data there); ESPN/Sleeper auto-detect. Team ids come from fantasy_get_league_info.
credentialsNoPer-call credentials, only needed WITHOUT a connected profile. Keys: secret_id (Fantrax); espn_s2 + swid (private ESPN leagues); username or user_id (Sleeper discovery); session_cookie / auth_token + write_enabled:true (explicit write opt-in only). Public ESPN leagues and all Sleeper reads need none.
league_queryNoLeague name/id filter, for when the profile has several leagues on the provider.
response_formatNo'markdown' (default) or 'json' (raw payload).markdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed15 schema fields changed
    • changedInput schema / properties / credentials / additionalProperties
      Previous value: -falseNew value: +true
    • changedInput schema / properties / credentials / description
      Previous value: -"Per-call credentials. Fill only the keys your provider needs (see fantasy_list_providers). Public ESPN leagues and all Sleeper reads need none."New value: +"Per-call credentials, only needed WITHOUT a connected profile. Keys: secret_id (Fantrax); espn_s2 + swid (private ESPN leagues); username or user_id (Sleeper discovery); session_cookie / auth_token + write_enabled:true (explicit write opt-in only). Public ESPN leagues and all Sleeper reads need none."
    • removedInput schema / properties / credentials / properties / espn_s2
      Removed value: -{
      -  "description": "ESPN private-league cookie 'espn_s2' (DevTools → Application → Cookies → espn.com).",
      -  "type": "string"
      -}
    • removedInput schema / properties / credentials / properties / secret_id
      Removed value: -{
      -  "description": "Fantrax Secret ID (User Profile → 'Your Secret ID').",
      -  "type": "string"
      -}
    • removedInput schema / properties / credentials / properties / swid
      Removed value: -{
      -  "description": "ESPN private-league cookie 'SWID': a GUID in curly braces, e.g. {XXXX-...}.",
      -  "type": "string"
      -}
    • removedInput schema / properties / credentials / properties / user_id
      Removed value: -{
      -  "description": "Sleeper numeric user_id (alternative to username).",
      -  "type": "string"
      -}
    • removedInput schema / properties / credentials / properties / username
      Removed value: -{
      -  "description": "Sleeper username (for league discovery).",
      -  "type": "string"
      -}
    • 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."
    • changedInput schema / properties / team_query / description
      Previous value: -"Identifies your team and marks it ⭐. Use the exact team id (preferred because it never breaks on rename) or a unique part of the team name. REQUIRED for Fantrax to identify your team: Fantrax exposes no owner data, so it cannot be auto-detected (ESPN/Sleeper auto-detect from your credentials). Get team ids from fantasy_get_league_info. For rosters this also filters to that team."New value: +"Your team's exact id (preferred) or a unique name fragment; marks it ⭐. Required on Fantrax (no owner data there); ESPN/Sleeper auto-detect. Team ids come from fantasy_get_league_info."
    • removedInput schema / required
      Removed value: -[
      -  "provider"
      -]
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Beyond the readOnlyHint/idempotent annotations, the description adds real behavioral nuance: it reveals that league inference depends on a connected profile, and that provider-specific behaviors like auto-starring differ. This is beyond the annotation's safety-only signal.

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 three short, front-loaded sentences: it leads with the result, then gives provider/profile inference details. No filler, no repetition of schema properties; every phrase earns its place.

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?

Given 8 parameters and no output schema, the description adequately explains the returned content (rank, record, points for/against) and the provider-specific requirements for invoking the tool, leaving little ambiguous about the tool's function and purpose in a typical use case.

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%, so the baseline is 3. The description's mention of team_query requirement on Fantrax and the inferred league when connected adds a marginal provider-driven semantic that the schema already partially covers, but it doesn't substantially compensate for the parameter depth.

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?

The opening phrase 'League standings: rank, record, points for/against' clearly states the resource and content returned. It conveys a read operation on the standings entity, though it does not explicitly differentiate from sibling tools like fantasy_get_league_info or fantasy_get_matchups.

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

Usage Guidelines3/5

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

The description provides provider-specific guidance ('Profile-first: league inferred when connected' and 'Fantrax needs team_query') and implies when the tool should be used, but it lacks any when-not-to-use direction or explicit alternative routing to the sibling standings-related tools.

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