Skip to main content
Glama
sbanthia92

fpl-context-mcp

by sbanthia92
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

query_historical_stats

Execute read-only SQL SELECT statements to pull FPL player stats, fixtures, team strength, gameweek results, and injury/availability info across seasons.

Instructions

Execute a read-only SQL SELECT against the FPL stats database. Use this to answer questions about player stats, fixtures, team strength, gameweek history, and player injury/availability status (FPL's status, chance of playing and news note) for the seasons in the database. Availability here is as of the last data refresh; call get_live_availability for the current flags.

Available tables (read-only). The current season is fully populated; past seasons exist only as season totals in players (see notes below the table list):

seasons — id, label (e.g. '2025/26'), start_year, is_current teams — season_id, fpl_id, name, short_name, strength, strength_attack_home/away, strength_defence_home/away gameweeks — season_id, gw_number (1–38), deadline_time, is_current, is_next, is_finished, average_entry_score, highest_score players — season_id, fpl_id, team_fpl_id, first_name, second_name, web_name, position (GKP/DEF/MID/FWD), now_cost, form, total_points, minutes, goals_scored, assists, clean_sheets, expected_goals, expected_assists, ict_index, selected_by_percent, status, chance_of_playing_next_round, news, news_added fixtures — season_id, fpl_id, gw_number, kickoff_time, home_team_fpl_id, away_team_fpl_id, home_score, away_score, finished, home_team_difficulty, away_team_difficulty gw_player_stats — season_id, player_fpl_id, gw_number, fixture_fpl_id, opponent_team_fpl_id, was_home, minutes, goals_scored, assists, clean_sheets, bonus, total_points, expected_goals, expected_assists, ict_index, starts

Notes:

  • teams, fixtures, gameweeks and gw_player_stats hold the CURRENT season only.

  • For past seasons, players has one row per player per season with season totals (points, minutes, goals, assists, clean sheets, cards, bonus). team_fpl_id is NULL there, and fpl_id is the player's current FPL id. Join seasons for the label.

  • Past seasons only include players in the CURRENT FPL player list. Departed players are absent, so league-wide or team-wide totals for past seasons are incomplete; only trust per-player history for players who appear in the current season.

Injury and availability (current season players rows, refreshed from FPL):

  • status: 'a' available, 'd' doubtful, 'i' injured, 's' suspended, 'u' unavailable (e.g. left the club / on loan), 'n' not in squad.

  • chance_of_playing_next_round: 0–100, NULL when there is no concern.

  • news: FPL's one-line note (e.g. 'Hamstring injury - 75% chance of playing'), '' when none. news_added: when that note last changed — use it for "what's new this week" questions (ORDER BY news_added DESC).

Join hint: teams.fpl_id = players.team_fpl_id (current season, same season_id).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sqlYesA SQL SELECT statement. Only SELECT is allowed — mutations will be rejected. LIMIT is injected automatically if omitted (max 100 rows).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

No annotations are supplied, so the description carries the full burden and does well: it fixes the read-only contract, discloses that LIMIT is auto-injected at max 100 rows, and warns about the current-vs-past-season data gaps and incomplete past-season totals. It does not state rate limits or whether queries can be aborted, which are minor gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and sibling routing, then structured with clearly delimited sections. It is long, but the length is justified by the table/column schema the agent cannot otherwise see; the notes section could be tightened slightly.

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?

For a SQL-over-a-fixed-schema tool with no output schema and no annotations, this is unusually complete: it names every table and column, documents the current-season-only limitation, past-season NULL team_fpl_id quirk, injury-status code semantics, and the join key.

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 there is a single parameter; the schema already documents the SELECT-only rule and auto-LIMIT behavior. The description's table/column map and join hint add schema-discovery value, but that's contextual rather than parameter-level semantics, so baseline 3 applies.

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+resource ('Execute a read-only SQL SELECT against the FPL stats database') and enumerates the question domains it serves. It explicitly distinguishes itself from its sibling by telling the agent to use get_live_availability for current availability flags.

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?

Gives explicit when-to-use coverage across player stats, fixtures, team strength, gameweek history and availability, and names the alternative (get_live_availability) with the precise condition that selects it (need of current vs. last-refresh flags).

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

Deploy Server

Other Tools