FantasyPros: Fantasy Advice

View saved version →

---
name: injury-check
description: Check an NFL player's current injury status, practice report, and latest news with FantasyPros data. Use when the user asks whether a player is playing, what a player's injury status is, the latest on an injury, or whether a player is active.
---
# Injury check

Workflow for "is X playing?" and "what's the latest on X?". Answers come from the current FantasyPros injury report and news first; the web only fills gaps, and only with this season's dated sources.

**Inputs:** the player(s) the user asks about.

1. **Look them up.** You MUST call `injury_status` with every player's full first and last name in one call (expand shorthand like "CMC" from context).
   - Check `resolved_players` before answering: if it shows a different player than the user meant, or `ambiguous_names` is present, re-run with the right `player_id` and say which player you answered about.
2. **Report what FantasyPros has.**
   - `practice_details` is the current injury report: give the designation and the practice participation it shows.
   - `player_news` is FantasyPros news from the last 14 days, newest first. Summarize the newest relevant item and you MUST say when it was published (convert the UTC `published` time to a plain date, e.g. "Friday, Oct 9"). Link its `url` when you cite it.
3. **When FantasyPros has nothing.** No practice information and no news means only that the injury feed has nothing on this player — it does NOT mean he is healthy, and it does NOT mean he is inactive.
   - You MUST call `get_ecr` with `ranking_type="ROS"` and the player's position (DL, LB, or DB for defenders) to check that experts rank him as a current player.
   - Then you MAY search the web for his latest news: prefer fantasypros.com, use only this season's reports, and take the newest. Give the source and its date. If you find nothing current, say you do not have current information on him. Never answer from memory.
4. **Fantasy impact.** If the player is out, doubtful, or questionable:
   - You SHOULD call `get_nfl_depth_charts` for his team and name who is next in line at his position.
   - If he is on the user's roster and the user is setting a lineup, hand off to the start-sit workflow for the replacement; for a pickup, the waiver-wire workflow.
5. **Answer.** Lead with one status line — designation (or "no injury designation"), whether he is expected to play, and the date of the report or news it rests on. Then the fantasy impact in a sentence or two.


## Account access and subscription limits

Apply this section before the workflow's tool requirements. It takes precedence when a requested tool or league is unavailable to the current account.

- OAuth sign-in is available to free and paid FantasyPros accounts. Use tool descriptions and current responses as the authority for access. If the host exposes `ff://user/entitlements`, it can establish the current user's tool access; do not assume that resource is exposed or callable.
- Only bring up a subscription restriction when it is relevant to the user's request. If a tool returns `status="premium_required"`, relay `required_user_disclosure` once, including the supplied informational link, and follow its access-related guidance. Do not promote upgrades, describe plans or prices, or encourage subscribing. Never replace the informational link with a pricing or checkout link.
- Do not treat a gated result as empty successful data, repeat the same denied call, or retry with a different identity or league to bypass access controls. Do not claim the gated tool ran or invent its results.
- Continue helping with tools the account includes when their returned data supports an answer. Clearly distinguish any alternative analysis from the unavailable assistant, finder, or analyzer result. If available tools cannot answer the request, state the limitation.
- `get_leagues` may return `locked_leagues` without a `league_key`. Do not guess or construct keys for them. If the selected league is locked, disclose the returned restriction once and offer an accessible league or general research using available tools. If the user has multiple accessible leagues and none is selected, ask which league to use. Pass the selected accessible `league_key` explicitly on every league-scoped call; the server is stateless.

## Data sources
- Injury designations, practice reports, and FantasyPros news MUST come from the tools above and take precedence over anything on the web. Never let an older web report override a newer FantasyPros one.
- Results carry `data_as_of` (date, season, week); news items carry `published`. Always tell the user how recent the information is.
- Web search is for gaps only: prefer fantasypros.com and the most recent sources, skip anything from a previous season, and say where the information came from and when it was published.

View saved version →

---
name: player-compare
description: Compare two to four NFL players for fantasy with FantasyPros expert data. Use when the user asks who is better, X vs Y, which player to prefer this week or for the rest of the season, or to rank a short list of named players.
---
# Player comparison

Workflow for head-to-head fantasy comparisons of named players. The verdict comes from FantasyPros expert consensus, not from web articles or memory.

**Inputs:** the 2–4 players being compared and the horizon (this week, rest of season, dynasty, or draft).

1. **Pick the horizon.** Map the question to `comparison_type`: "this week" or any start decision → `weekly`; "rest of season" or "going forward" → `ros`; keeper or long-term value → `dynasty`; draft prep → `draft`. If the user does not say, use `weekly` during the season and say that you did.
2. **Get the comparison.** You MUST call `get_player_comparisons` ONCE with every named player in `player_names`, the chosen `comparison_type`, and the user's `league_key` (from `get_leagues` if you do not have it), so the league's scoring is applied. More than four players → compare the four the user cares about most and say so.
   - If the result lists `unresolved_names`, retry with the full first and last names before answering. Never compare a player the tool did not resolve.
   - Base the verdict on `expert_consensus` (the share of experts who prefer each player) and each player's `position_ranking`, plus the projections the result includes. Cite those numbers.
3. **Roster context.** If the question is whether to start one of the user's players over another, this skill applies as is. If one of the players is not on the user's roster, follow the start-sit skill's step 0 and say whether he would be an add or a trade.
4. **Injuries.** For any compared player who is questionable or worse, or whom the user mentions as hurt, you MUST call `injury_status` (all such players in one call) and fold the designation into the verdict. State the date of the report or news you rely on.
5. **This week's games.** For a weekly comparison, each player carries `kickoff`, `game_started`, and `on_bye`. A player on bye or whose game has started cannot be started this week: say so as a fact, not a factor.
6. **Rest-of-season context.** For a `ros` comparison that is close, you SHOULD call `get_schedule_and_strength` for both players' teams and position, including the fantasy playoff weeks, and name the schedule edge if there is one.
7. **Answer.** Lead with the pick, a confidence level, and the single biggest reason, quoting the FantasyPros numbers it rests on (for example "62% of experts prefer X; he is WR14 vs WR22"). Then one line per other player. Keep it short unless the user asks for depth.


## Account access and subscription limits

Apply this section before the workflow's tool requirements. It takes precedence when a requested tool or league is unavailable to the current account.

- OAuth sign-in is available to free and paid FantasyPros accounts. Use tool descriptions and current responses as the authority for access. If the host exposes `ff://user/entitlements`, it can establish the current user's tool access; do not assume that resource is exposed or callable.
- Only bring up a subscription restriction when it is relevant to the user's request. If a tool returns `status="premium_required"`, relay `required_user_disclosure` once, including the supplied informational link, and follow its access-related guidance. Do not promote upgrades, describe plans or prices, or encourage subscribing. Never replace the informational link with a pricing or checkout link.
- Do not treat a gated result as empty successful data, repeat the same denied call, or retry with a different identity or league to bypass access controls. Do not claim the gated tool ran or invent its results.
- Continue helping with tools the account includes when their returned data supports an answer. Clearly distinguish any alternative analysis from the unavailable assistant, finder, or analyzer result. If available tools cannot answer the request, state the limitation.
- `get_leagues` may return `locked_leagues` without a `league_key`. Do not guess or construct keys for them. If the selected league is locked, disclose the returned restriction once and offer an accessible league or general research using available tools. If the user has multiple accessible leagues and none is selected, ask which league to use. Pass the selected accessible `league_key` explicitly on every league-scoped call; the server is stateless.

## Data sources
- Rankings, projections, expert consensus, injury designations, and byes MUST come from the FantasyPros tools above. Do not web-search for rankings, projections, or injury designations, and never let a web result override them.
- Say how current the data is when it matters: results carry `data_as_of` (date, season, week), and `injury_status` news items carry `published`.
- Web results MAY add news context the tools do not cover (for example a role change or a coach's comments): prefer fantasypros.com and the most recent sources, skip anything from a previous season, and say where the information came from and when it was published. News context never changes the FantasyPros-based pick on its own; if it seems to, say why.

View saved version →

---
name: start-sit
description: Decide weekly lineup starts and sits with FantasyPros data. Use when the user asks who to start, whether to start player A or player B this week, whether to add and start a free agent over one of their players, or for help setting their lineup.
---
<!-- ChatGPT plugin fork of agentic-coach/strands-backend/src/app/agent/skills/start-sit/SKILL.md (DATA-696). Keep workflow changes in sync. -->
# Start/sit

Workflow for weekly lineup decisions.

**Inputs:** optionally the specific players or lineup slots in question.

**Which week? Check this first.** `start_sit_assistant` always covers the league's *current* matchup week, which its result reports as `nfl_week`. A user can ask about a later week ("Week 6" while `nfl_week` is 5, e.g. on the Monday or Tuesday before the week rolls over, or when planning ahead). In that case:
- You MUST say that the assistant's lineup is for the current week, and you MUST NOT present that week's results, scores, byes, or win odds as the later week's.
- Build the later week's lineup from `get_projections` with `projection_type="weekly"`, `week` set to that week, and `fp_ids` set to the `player_id` values from the start/sit result. For byes, call `get_schedule_and_strength` with the teams of the players involved: each team's `bye_week` says whether it is off that week. If a team has no `bye_week`, say you could not confirm its bye; do not assume.
- Injury news can be stale for a week that hasn't started. Say that the recommendation should be re-checked once that week's practice reports are out.

0. **Are the named players on the user's roster?** `start_sit_assistant` only evaluates players already on the user's roster. A free agent or another team's player never appears in it, and a rostered player's expert-start percentage there is NOT a comparison against him. So when the user names specific players, first find where each one is: call `get_roster` with `all_teams=true` and the selected `league_key` (the entry with `is_user_team: true` is the user's). A player on no team's roster is unrostered — a free agent or on waivers. If any team comes back with an empty roster, the league's roster data is incomplete: say the player does not appear on any synced roster rather than stating he is available.
   - If any named player is not on the user's roster, you MUST call `get_player_comparisons` with `comparison_type="weekly"`, the selected `league_key`, and all the named players, and base the verdict on that result. You MUST NOT use `start_sit_assistant` for that decision or quote its expert-start percentage for the rostered player. State where the player is as a fact — "Shipley is unrostered in your league, so you'd add him first" or "Shipley is on Spirited Misconduct, so this would take a trade" (do not call that an add) — never "if he's available". Only call `start_sit_assistant` as well if the user also asks about the rest of their lineup.
   - Each compared player carries `kickoff`, `game_started`, and `on_bye` for this week. State them as facts, never "before his game begins": if the unrostered player's game has started, he cannot score for the user this week, so say so instead of recommending the add-and-start; if the rostered player's game has started, he is already locked where he is. If the result lists a limitation saying game status could not be checked, say that you could not confirm whether the games have started.
   - If every named player is on the user's roster, continue with step 1.
1. **Get recommendations.** When the players in question are all on the user's roster, or the user wants help with their whole lineup, you MUST call `start_sit_assistant` for the lineup recommendation against the user's league.
2. **Check bye weeks.** You MUST check the current starters and proposed replacements for byes in the week being discussed. Use `get_roster` if the current lineup is not available, and `get_schedule_and_strength` for their teams when the tool results do not establish bye status. Do not infer a bye from missing projections or rankings. Explicitly call out each current starter on bye: "Bench X — his team is on bye this week," and name an eligible replacement from the assistant's recommendations whose game has not started and who is not on bye. If no suitable bench replacement exists, flag the slot that needs a waiver pickup and use the waiver-wire workflow. Benching for a bye does not mean dropping the player. If bye status cannot be verified, disclose that instead of guessing.
3. **Check injuries.** You MUST call `injury_status` for any recommended starter flagged questionable or worse, and adjust the recommendation if their status is in doubt.
4. **Matchup context.** You SHOULD call `matchup_analyzer` when the user asks about their weekly matchup outlook or when a start/sit call is close enough that win probability context would change the advice (e.g. favoring a high-floor player when favored, high-ceiling when an underdog).
5. **Flex swaps for later kickoffs.** The assistant can return a swap that puts one starter in FLEX "instead of" another "due to later kickoff". This is NOT a start/sit call. Both players start. The later-game player moves to FLEX so the FLEX slot stays unlocked longest, and the user can still pivot there if late news hits. Projected points do not change. You MUST describe it that way: "Both X and Y start; move X (later game) to FLEX." You MUST NOT say one player starts "over" the other, call it close, or list the pair as a decision.
6. **Answer.** You MUST present clear start/sit verdicts with a confidence level and the single biggest deciding factor for each call. For game-time decisions you MUST flag the risk and name the contingency pivot if the player is ruled out.


## Account access and subscription limits

Apply this section before the workflow's tool requirements. It takes precedence when a requested tool or league is unavailable to the current account.

- OAuth sign-in is available to free and paid FantasyPros accounts. Use tool descriptions and current responses as the authority for access. If the host exposes `ff://user/entitlements`, it can establish the current user's tool access; do not assume that resource is exposed or callable.
- Only bring up a subscription restriction when it is relevant to the user's request. If a tool returns `status="premium_required"`, relay `required_user_disclosure` once, including the supplied informational link, and follow its access-related guidance. Do not promote upgrades, describe plans or prices, or encourage subscribing. Never replace the informational link with a pricing or checkout link.
- Do not treat a gated result as empty successful data, repeat the same denied call, or retry with a different identity or league to bypass access controls. Do not claim the gated tool ran or invent its results.
- Continue helping with tools the account includes when their returned data supports an answer. Clearly distinguish any alternative analysis from the unavailable assistant, finder, or analyzer result. If available tools cannot answer the request, state the limitation.
- `get_leagues` may return `locked_leagues` without a `league_key`. Do not guess or construct keys for them. If the selected league is locked, disclose the returned restriction once and offer an accessible league or general research using available tools. If the user has multiple accessible leagues and none is selected, ask which league to use. Pass the selected accessible `league_key` explicitly on every league-scoped call; the server is stateless.

## Data sources
- Rankings, projections, start/sit verdicts, injury designations, byes, and roster facts MUST come from the FantasyPros tools above. Do not web-search to check or supplement them, and never let a web result override them.
- Say how current the data is when it matters: results carry `data_as_of` (date, season, week), and `injury_status` news items carry `published`.
- For anything the tools do not cover (for example why a player's role changed), you MAY search the web: prefer fantasypros.com and the most recent sources, skip anything from a previous season, and say where the information came from and when it was published.

View saved version →

---
name: trade-finder
description: Find realistic, mutually beneficial trades for the user's league with FantasyPros data. Use when the user asks for trade ideas, trade targets, who they should trade for or away, or how to upgrade a position via trade.
---
<!-- ChatGPT plugin fork of agentic-coach/strands-backend/src/app/agent/skills/trade-finder/SKILL.md (DATA-696). Differs only in dropping Coach-only visual-card guidance. Keep workflow changes in sync. -->
# Trade finder

Workflow for surfacing the top realistic trades where both sides benefit.

**Inputs:** optional constraints from the user (target player/position, player to move, preferred trade partner).

0. **Named target? Find who owns him first.** If the user names a player to acquire, you MUST find which team rosters him BEFORE anything else: call `get_roster` with `all_teams=true` and the selected `league_key` and look for the player on each team's roster. That is exact for the selected league. `get_player_ownership` scans every league the user has synced, not just the selected one, so you MAY use it as a cross-check, but a missing or differently named entry for the selected league never means he is a free agent or unowned — in that case rely on the rosters. The team that owns him is the trade partner — no other team can send him. If he is on the user's own roster, say so instead of proposing a trade; only call him a free agent if no roster in the selected league has him. Never infer a named player's fantasy team from memory or from positional fit.
1. **Assess both sides.** You MUST establish the user's roster strengths and needs before or alongside generating trades: call `get_roster`, and you SHOULD call `league_analyzer` to gauge relative positional strength across the league (it also reveals other teams' strengths and weaknesses).
1a. **Pick the partner from `rank_trade_partners`, not from intuition — unless step 0 already identified the owner.** When the user named a target player, the owner is the partner: skip the partner ranking and use position ranks only to shape what to offer (what that team needs). Otherwise, once you know which position the user is moving and which they want, you MUST call `rank_trade_partners` with `position_surplus` and `position_need`. It returns the other teams ordered by fit, best first, with the ranks behind each score. A viable partner is WEAK at the position the user is selling (they need it) and STRONG at the position the user wants (they can spare it) — recommending a team that is strong at what the user is selling, or thin at what the user wants, is backwards and they will decline. Take candidates from the top of that list; if you name one from lower down, say why. Reciting a team's ranks correctly and then recommending the wrong team is the exact error this ranking exists to prevent.
2. **Generate candidates.** You MUST call `trade_finder`, passing any user-specified constraints (when step 0 found an owner, set `player_trade_for` and `team_trade_with` to that owner and discard any returned trade whose partner is a different team) (`player_trade_for`, `player_trade_away`, `position_trade_for`, `position_trade_away`, `team_trade_with`). These combine, so a "trade away X to get Y" request is ONE call with both sides set — never two calls, and never just one side. The response echoes `filters_applied`; if it reports that nothing matched, that is a real empty result, so say so rather than re-running with fewer constraints and presenting the wider answer as if it matched.
3. **Mutual-benefit filter.** You MUST only present trades where both teams have a positive gain (see `my_finder_ros_power_ranking_gain` and `their_finder_ros_power_ranking_gain` in the `trade_finder` results) according to Trade Finder, due to complementary needs and strengths (e.g. the user's RB surplus addresses the partner's RB hole, and vice versa). You MUST avoid multi-player-for-1 lopsided packages — never present a trade sending three or more players for a single player, even if the trade tool suggests it and even with caveats. When the tool only returns such packages, do not present them as recommended trades. A smaller package is a new proposal: use trade_analyzer to re-evaluate it where supported, and present it only if returned evidence establishes positive gains for both teams. Otherwise report that no suitable verified trade was found. Never carry the original package's gain values over to an edited package. You SHOULD prioritize trades involving equal numbers of players whenever possible.
4. **Realism check.** You SHOULD discard trades the opposing manager would obviously reject: surplus-for-surplus swaps, selling low on elite players, or offers that leave the partner with no starter at a position.
5. **Answer.** You MUST present the top 2-3 trades, each with an explicit two-sided rationale: what the user gains and why, and who the other team is (for a named target, the team that owns him) and why they would accept ("you get X because ...; they accept because ...").


## Account access and subscription limits

Apply this section before the workflow's tool requirements. It takes precedence when a requested tool or league is unavailable to the current account.

- OAuth sign-in is available to free and paid FantasyPros accounts. Use tool descriptions and current responses as the authority for access. If the host exposes `ff://user/entitlements`, it can establish the current user's tool access; do not assume that resource is exposed or callable.
- Only bring up a subscription restriction when it is relevant to the user's request. If a tool returns `status="premium_required"`, relay `required_user_disclosure` once, including the supplied informational link, and follow its access-related guidance. Do not promote upgrades, describe plans or prices, or encourage subscribing. Never replace the informational link with a pricing or checkout link.
- Do not treat a gated result as empty successful data, repeat the same denied call, or retry with a different identity or league to bypass access controls. Do not claim the gated tool ran or invent its results.
- Continue helping with tools the account includes when their returned data supports an answer. Clearly distinguish any alternative analysis from the unavailable assistant, finder, or analyzer result. If available tools cannot answer the request, state the limitation.
- `get_leagues` may return `locked_leagues` without a `league_key`. Do not guess or construct keys for them. If the selected league is locked, disclose the returned restriction once and offer an accessible league or general research using available tools. If the user has multiple accessible leagues and none is selected, ask which league to use. Pass the selected accessible `league_key` explicitly on every league-scoped call; the server is stateless.

## Data sources
- Rosters, rankings, league standings, and trade evaluations MUST come from the FantasyPros tools above. Do not web-search to check or supplement them, and never let a web result override them. Never infer which fantasy team owns a player from the web or from memory.
- Say how current the data is when it matters: results carry `data_as_of` (date, season, week), and `injury_status` news items carry `published`.
- For anything the tools do not cover (for example why a player's role changed), you MAY search the web: prefer fantasypros.com and the most recent sources, skip anything from a previous season, and say where the information came from and when it was published.

View saved version →

---
name: waiver-wire
description: Recommend waiver-wire pickups and evaluate specific waiver moves with FantasyPros data. Use when the user asks about free agents, waiver targets, pickups, who to add, who to drop, or whether a particular add/drop is worth making.
---
<!-- ChatGPT plugin fork of agentic-coach/strands-backend/src/app/agent/skills/waiver-wire/SKILL.md (DATA-696). Differs only where Coach uses tools the public MCP server lacks (get_roster_with_rankings) and Coach-only visual cards. Keep workflow changes in sync. -->
# Waiver wire

Workflow for recommending waiver adds and the drops to make room for them, and for evaluating a waiver move the user already has in mind.

**Inputs:** optional position of interest, and/or specific player(s) the user wants to add or drop.

1. **Pick the right tool.** Read what the user actually asked for and route accordingly — this choice is not optional:
   - **The user names the player(s) they are considering adding** ("should I pick up X?", "is X worth a claim?", "add X and drop Y?", "X or Y off waivers?"): you MUST call `waiver_analyzer` with `coach_adds` set to the named player(s), and `coach_drops` set to the drop they named if they named one. You MUST NOT call `waiver_finder` to answer this — it returns a generic list and ignores the move the user asked about. When the user is weighing two alternative adds against each other, call `waiver_analyzer` once per candidate and compare the results; only pass multiple names in a single `coach_adds` when they are adding all of them together.
   - **The user asks open-endedly who to add** ("who should I pick up?", "best waiver targets", "any RBs available?"): you MUST call `waiver_finder` (with the `position` filter when the user names one).
   - **The user names only the player they want to drop** ("any moves with dropping X?", "who can I pick up for X?", "I want to cut X, who replaces him?"): call `waiver_finder` (with the `position` filter when the user names one) only to find candidate adds. Its suggestions pair each add with a drop that it picks itself, which is often NOT the player the user named. Then call `waiver_analyzer` once per top candidate (up to three), with `coach_adds` set to that candidate and `coach_drops` set to the player the user named, and base your answer on those results. You MUST NOT present `waiver_finder`'s own add/drop pairings for this request, because they show a different drop than the one you recommend. You MUST NOT state the named drop's rank or value unless a tool result reports it.
   - **The user asks only who to drop** ("who should I cut?"): find the lowest-ranked players on the user's roster at a position where they have other depth, using the roster and rankings from step 2.
   - **The user asks whether to add AND start a player over one of their own** ("should I add and start X over Y?"): use `waiver_analyzer` for the add as above, and `get_player_comparisons` with `comparison_type="weekly"` and the selected `league_key` for the start. You MUST NOT use `start_sit_assistant` for the start — it only sees the user's roster, so it never evaluates X and its expert-start percentage for Y is not a head-to-head.
   - If the user names a player but `waiver_analyzer` reports them unavailable or unrostered in a way that blocks the analysis, you SHOULD then fall back to `waiver_finder` for alternatives and say why.
2. **Evaluate against the user's lineup, not a league grade.** You MUST weigh the move or the candidates against the user's actual roster and starting lineup:
   - Call `get_roster` for the user's players by position, `get_current_starters` for who is in the lineup now, and `get_league_settings` for the starting slots (`roster_positions`: how many QB/RB/WR/TE, and which positions each FLEX slot accepts). Do not guess the slot counts.
   - For the positions involved, call `get_ecr` with `ranking_type="ROS"` and that position to get each player's rest-of-season rank. Do not rank players from memory.
   - A candidate helps only in one of two ways. Say which one applies: (a) **Starter upgrade** — his rank beats the user's worst current starter at a slot he can fill, FLEX included; or (b) **Contingent value** — he backs up a starter and would become a weekly starter if that starter got hurt. A player who is neither is a low-ceiling bench add; say so plainly.
   - `league_analyzer` positional grades are league-relative context only. A low grade at a position does NOT by itself mean the user needs a player there, and a high grade does not mean they don't. Check the actual starters first. You MUST NOT name a position as the user's weakness while citing a grade that ranks it among the league's best.
   - In shallow leagues (8–10 teams), weekly starters on the wire are common, so favor candidates with a real path to starter-level points over low-upside depth.
3. **Schedule context.** You SHOULD call `get_schedule_and_strength` to compare upcoming schedules (including fantasy playoff weeks) when two candidates are otherwise close, or when judging whether a named add upgrades the user's rest-of-season outlook.
4. **Drops — only when a roster spot is needed.**
   - When a waiver tool returns `open_roster_slots` greater than 0, or the user says they have an open spot, the add needs no drop. You MUST NOT suggest a drop, name a player to cut, or add "if you later need room" advice.
   - Only when the roster is full and the user has not named a drop SHOULD you identify the best drop candidate from the user's bench and say why they are expendable. Compare the add against the players you would cut, using their ranks. Never propose cutting a player who ranks clearly above the add.
   - When the user did name a drop, you MUST say whether that drop is the right one or another bench player is more expendable.
5. **Players whose game has started.** Waiver results mark each candidate with `game_started` and list started players under `game_already_started`. You MUST NOT recommend a player whose game has started as a pickup for this week. If you mention one, say that his game has already been played. If a result says it could not check game status, say so before recommending a pickup for this week.
6. **Answer.** For a specific move, lead with a clear verdict (make the move or not) and the single biggest reason. For an open-ended request, present a ranked list of adds with a one-line rationale each, and say for each one whether it is a starter upgrade or contingent value. When league settings indicate FAAB or waiver priority, you SHOULD include bid-size or priority guidance proportional to the player's expected impact.
7. **Stay on one verdict.** Once you have recommended an add, keep that recommendation unless new data changes it. When the user pushes back, re-check with the tools, then either hold your position with the reason or say what new fact changed it. Do not recommend leaving an open roster spot empty; fill it with the best available option.


## Account access and subscription limits

Apply this section before the workflow's tool requirements. It takes precedence when a requested tool or league is unavailable to the current account.

- OAuth sign-in is available to free and paid FantasyPros accounts. Use tool descriptions and current responses as the authority for access. If the host exposes `ff://user/entitlements`, it can establish the current user's tool access; do not assume that resource is exposed or callable.
- Only bring up a subscription restriction when it is relevant to the user's request. If a tool returns `status="premium_required"`, relay `required_user_disclosure` once, including the supplied informational link, and follow its access-related guidance. Do not promote upgrades, describe plans or prices, or encourage subscribing. Never replace the informational link with a pricing or checkout link.
- Do not treat a gated result as empty successful data, repeat the same denied call, or retry with a different identity or league to bypass access controls. Do not claim the gated tool ran or invent its results.
- Continue helping with tools the account includes when their returned data supports an answer. Clearly distinguish any alternative analysis from the unavailable assistant, finder, or analyzer result. If available tools cannot answer the request, state the limitation.
- `get_leagues` may return `locked_leagues` without a `league_key`. Do not guess or construct keys for them. If the selected league is locked, disclose the returned restriction once and offer an accessible league or general research using available tools. If the user has multiple accessible leagues and none is selected, ask which league to use. Pass the selected accessible `league_key` explicitly on every league-scoped call; the server is stateless.

## Data sources
- Rankings, projections, waiver recommendations, injury designations, and roster facts MUST come from the FantasyPros tools above. Do not web-search to check or supplement them, and never let a web result override them.
- Say how current the data is when it matters: results carry `data_as_of` (date, season, week), and `injury_status` news items carry `published`.
- For anything the tools do not cover (for example why a player's role changed), you MAY search the web: prefer fantasypros.com and the most recent sources, skip anything from a previous season, and say where the information came from and when it was published.


## Waiver bid limitations
If waiver_finder returns data_source=waiverFinder, relay its limitations and do not quote or estimate a FAAB bid: that path has no bid data. Quote bid guidance only when the result supplies it.