Skip to main content
Glama
tlo1216

espn-fantasy-mcp

by tlo1216

Get Free Agents

get_free_agents
Read-onlyIdempotent

Retrieve free agents and waiver-wire players sorted by ownership percent or projection, with optional filter by lineup slot to target specific positions.

Instructions

Free agents and waiver-wire players, sorted by ownership percent (default) or projection. Optionally filter by lineup slot id (see get_league for slot ids, or the README's slot tables).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax players to return.
sportNoffl (football), fba (basketball), or flb (baseball). Defaults to ESPN_SPORT.ffl
seasonNoSeason year. Defaults to ESPN_SEASON.
sort_byNoowned
league_idNoESPN league id. Defaults to ESPN_LEAGUE_ID.123456
position_slot_idNoFilter to one lineup slot id, e.g. 2 for RB in football.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the safety profile is fully covered. The description adds useful behavioral context about the default sort order and the projection sort option, but does not detail what qualifies as a free agent vs waiver-wire player or any response characteristics.

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 with no filler; the primary behavior and default sorting are front-loaded, and the optional filtering note is placed at the end. Every clause earns its place.

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?

With rich annotations, a complete input schema covering defaults and valid values, and an output schema present, the description covers all that an agent needs to invoke the tool correctly. Nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is high (83%), and the description reinforces the meaning of sort_by and position_slot_id. It uniquely adds the cross-reference to get_league/README for slot IDs, which helps an agent supply valid values for position_slot_id.

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 ('free agents and waiver-wire players') and clarifies sorting by ownership percent or projection. It is clearly distinct from sibling mutation tools like add_free_agent or waiver_claim, which operate on this same player pool.

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?

The intended use—browsing available unrostered players—is clear from the description, and the optional filter is explained. It does not explicitly state when not to use it or compare against get_player/get_transactions, but the context is strong enough that an agent can select it correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.