Skip to main content
Glama

Get Available Players (Free Agents / Waivers)

fantasy_get_available_players
Read-onlyIdempotent

Browse the pool of players you can ADD in ONE league (free agents + waivers), ranked best-first: THE waiver/pickup tool. Excludes rostered players — for a specific named player (rostered or not) use fantasy_get_player_data; for waiver suggestions across ALL your leagues at once, fantasy_get_weekly_digest includes a top add per league.

Support: ESPN (% owned, season + projected points), Sleeper (universe minus rostered, relevance rank), Fantrax (points/ownership/ADP for public/viewable leagues, ADP-backed fallback otherwise).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoRanking key. Default: best available first (ESPN: % owned; Sleeper: relevance rank).
limitNoMax players to return (1-200).
queryNoOptional player-name substring filter.
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.
positionNoFilter to a position code, e.g. 'RB', 'WR', 'PG'.
providerNoFantasy platform. Optional: defaults to your connected platform ('sleeper').
league_idNoThe platform's league id (Fantrax also accepts the full league URL).
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. Changed14 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."
    • removedInput schema / required
      Removed value: -[
      -  "provider"
      -]
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, so the safety profile is covered. The description adds genuinely useful platform-specific behavior: ESPN ranking by % owned + projected points, Sleeper relevance rank, and the Fantrax ADP-backed fallback for non-public leagues — value beyond what annotations provide.

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 compact paragraphs with every sentence earning its place; purpose and scope are front-loaded in the first sentence, sibling routing follows immediately, and the platform-support paragraph adds concrete data without filler.

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?

For an 11-parameter, three-platform tool with no output schema, the description covers scope, exclusions, platform behavior, fallback, and sibling routing. The main omission is explicit return-format details, though the response_format parameter and platform data descriptions largely mitigate this.

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%, so the schema carries the parameter documentation. The description adds platform-specific ranking semantics for the 'sort' parameter (ESPN % owned, Sleeper relevance rank) and the Fantrax fallback, which the schema's enum alone cannot convey, but it does not elaborate individual parameters. Baseline 3 is appropriate.

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 opens with a specific verb+resource ('Browse the pool of players you can ADD') and states the one-league scope explicitly, then names sibling tools (fantasy_get_player_data, fantasy_get_weekly_digest) for adjacent cases and excludes rostered players, making selection unambiguous.

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?

Explicitly names alternatives with the conditions that select them: fantasy_get_player_data for a specific named player, fantasy_get_weekly_digest for cross-league waiver suggestions. The 'in ONE league' scope further clarifies when this applies versus roster views (fantasy_get_rosters/my_players).

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