Skip to main content
Glama
sbanthia92

fpl-context-mcp

fpl-context-mcp

An MCP server that gives any MCP-capable AI agent two tools for answering Fantasy Premier League (FPL) and Premier League football questions. It runs locally in Claude Desktop, Claude Code, Cursor, VS Code Copilot, Windsurf, Gemini CLI and Codex; ChatGPT and other clients that only accept a URL can connect when you host it over HTTP.

Tool

What it does

query_historical_stats

Runs a read-only SQL SELECT against a PostgreSQL database of FPL player, fixture and gameweek stats (whatever seasons you've ingested)

query_press_conferences

Semantic search over BBC Sport and The Guardian press-conference summaries and injury updates stored in Pinecone

Two ingestion jobs keep that data populated and current:

Job

What it does

ingest_press_content

Fetches articles from BBC Sport RSS and The Guardian API, embeds them, and upserts into Pinecone

ingest_match_data

Fetches fixture and player-stat data from the FPL API, and delta-writes to PostgreSQL

This server does not fetch live data per-question. The two tools above only read whatever is already sitting in your PostgreSQL database and Pinecone index. Those stores start out empty — you must run the ingestion jobs once to seed them, and then keep running them on a recurring schedule forever, or answers will silently go stale (press results) or stay empty (stats results). This is not a one-time setup step. See Keeping data fresh (ongoing) — it's the single most important thing to get right before handing this to anyone.


Contents


Related MCP server: FPL MCP Server

Quickstart

The full path from zero to a working MCP tool, in order. Each step links to details further down.

  1. Install: pip install fpl-context-mcp — see Installation.

  2. Provision storage: a PostgreSQL database and a Pinecone index. Run db/schema.sql against a fresh Postgres database and create a Pinecone index named fpl-context (or your own name) using the multilingual-e5-large model — see Provisioning your own database.

  3. Configure: copy .env.example to .env and fill in your DATABASE_URL, DATABASE_ETL_URL, and PINECONE_API_KEY — see Configuration.

  4. Verify connectivity: fpl-context-mcp --check — confirms every credential works before you go further.

  5. Seed data: run the two ingestion commands, then the one-time history backfill, so there's actually something to query — see Seeding data.

  6. Schedule ongoing ingestion: set up cron (or equivalent) to keep re-running the two ingestion commands (not the backfill) indefinitely — see Keeping data fresh. Skipping this is the #1 cause of "the tool returns nothing" reports.

  7. Connect your AI client: Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, Gemini CLI or Codex, or — for ChatGPT and other clients that only accept a URL — run it over HTTP.


Prerequisites

Requirement

Version

Python

3.11+

PostgreSQL

Any recent version, with a read-only role (e.g. fpl_readonly) and a read/write role (e.g. fpl_etl)

Pinecone

An index using the multilingual-e5-large model (1024 dims) — free tier works

You provision both yourself — see the next two sections. Both have free tiers that are enough for this.


Installation

pip install fpl-context-mcp

This installs four CLI commands: fpl-context-mcp (the MCP server), fpl-context-ingest-press and fpl-context-ingest-match (the two recurring ingestion jobs), and fpl-context-backfill-history (a one-time job for past seasons) — see Seeding data.

With uv

git clone https://github.com/sbanthia92/fpl-context-mcp
cd fpl-context-mcp
uv sync

With pip (from source)

git clone https://github.com/sbanthia92/fpl-context-mcp
cd fpl-context-mcp
pip install -e ".[dev]"

As a dependency of another project

fpl-context-mcp @ git+https://github.com/sbanthia92/fpl-context-mcp.git

Configuration

The server reads all secrets from environment variables. Copy .env.example to .env in your working directory (it's gitignored) and fill in your own values:

# PostgreSQL — read-only connection for the query_historical_stats tool
DATABASE_URL=postgresql://fpl_readonly:password@localhost:5432/fpl

# PostgreSQL — read/write connection for the ingest_match_data job
# Falls back to DATABASE_URL if not set
DATABASE_ETL_URL=postgresql://fpl_etl:password@localhost:5432/fpl

# Pinecone — required for both the press tool and the ingest_press_content job
PINECONE_API_KEY=pcsk_...
PINECONE_INDEX_NAME=fpl-context   # optional, defaults to 'fpl-context'

# The Guardian open platform API key
# Register free at https://open-platform.theguardian.com/access/
# Recommended: without a key the Guardian source is skipped (BBC Sport only) —
# the old public 'test' key is rejected by the API.
GUARDIAN_API_KEY=your-key-here

# HTTP transport only (fpl-context-mcp --transport http). Requests to /mcp must
# send "Authorization: Bearer <token>". Leave empty only when bound to localhost.
# MCP_AUTH_TOKEN=

Which variables does each component need?

Component

Variables required

query_historical_stats tool

DATABASE_URL

query_press_conferences tool

PINECONE_API_KEY

ingest_press_content job

PINECONE_API_KEY (plus GUARDIAN_API_KEY for Guardian articles)

ingest_match_data job

DATABASE_ETL_URL (or DATABASE_URL)

Run fpl-context-mcp --check any time to confirm all of the above are set correctly and reachable — see Verifying connectivity.


Provisioning your database

PostgreSQL:

createdb fpl   # or whatever database name you'll use in DATABASE_URL
psql fpl -f db/schema.sql

db/schema.sql creates the six tables query_historical_stats expects (seasons, teams, gameweeks, players, fixtures, gw_player_stats) and includes example CREATE ROLE statements for the read-only and read/write roles referenced in .env.example. It's a starting schema, not a full migration tool — adjust types/constraints as needed.

Pinecone:

  1. Create a free account at pinecone.io if you don't have one.

  2. Create an index named fpl-context (or any name — just set PINECONE_INDEX_NAME to match) configured for the multilingual-e5-large integrated embedding model (1024 dimensions, cosine metric). No separate embedding step needed — the ingestion job and the query tool both call Pinecone's built-in inference.

  3. Grab an API key from the Pinecone console and set PINECONE_API_KEY.

Both tables and the index start completely empty. Continue to Seeding data.


Seeding data (required before first use)

Both ingestion jobs are plain functions you run directly — nothing runs automatically on pip install or on MCP server startup.

# If installed from PyPI
fpl-context-ingest-press
fpl-context-ingest-match
fpl-context-backfill-history   # one-time: past seasons (see below)

# If running from source
python -m jobs.ingest_press_content
python -m jobs.ingest_match_data
python -m jobs.backfill_history

Run these once, right after configuring your .env, before registering the server with Claude Desktop. Run fpl-context-ingest-match before the backfill. Until you do:

  • query_press_conferences will return a message telling you the namespace is unseeded, instead of any article content.

  • query_historical_stats will return Query returned no results. for any query, since the tables are empty.

ingest_match_data loads the current season: every team, gameweek, player and fixture, plus per-player stats for matches already played (the first run can take several minutes mid-season, since it fetches stats player by player). Later runs are quick — see What each run updates.

fpl-context-backfill-history adds past seasons (as far back as FPL has them, about 20). It reads FPL's per-player season history and writes one row per player per season into players. It's safe to re-run and only needs to run once, since past seasons don't change. Know its limits:

  • It holds season totals only — points, minutes, goals, assists, clean sheets, cards, bonus. FPL doesn't serve past fixtures, teams or match-by-match stats, so those tables only ever contain the current season.

  • Past-season rows have team_fpl_id set to NULL (FPL doesn't say which team a player was on), and fpl_id is the player's current FPL id.

  • It only covers players in FPL's current player list. Anyone who has left the league (or retired) has no history here, so a question about a departed player returns nothing, and league-wide or team-wide totals for a past season are incomplete. Per-player questions about current players are reliable.

ingest_press_content only pulls currently-live articles (BBC/Guardian don't offer deep history), so the press index will be thin until it's had a few days of scheduled runs — that's expected, not a bug.


Keeping data fresh (ongoing)

This is not a one-time step. Fixtures change weekly, player stats update after every match, press articles are deleted from the index after 14 days, and injury/availability news is rewritten on every run so it reflects what FPL currently says (ingest_press_content prunes stale docs each time). If you seed once and never run these jobs again, a query a month later will hit a Pinecone namespace with zero documents (everything aged out) and a Postgres database that's missing every fixture since your last run.

You need something to invoke fpl-context-ingest-press and fpl-context-ingest-match on a recurring schedule, indefinitely, for as long as the MCP server is in use. (The backfill is not part of this — run it once.) Pick whichever fits your setup:

What each run updates

Runs are on a clock, not tied to gameweeks — nothing triggers when a match ends. A result shows up in your database at the first run after FPL marks the fixture finished.

Job

Each run

Freshness with the default schedule

fpl-context-ingest-match

Rewrites all teams, gameweeks (deadlines, current/next flags), players (points, form, price, availability) and all 380 fixtures (scores, finished flags, reschedules). Fetches per-player match stats for newly finished fixtures, and re-fetches those from the last 2 days because FPL revises bonus points after full time.

Up to about 12 hours behind (runs at 06:00 and 22:00 UTC)

fpl-context-ingest-press

Adds new BBC/Guardian articles, rewrites every player's injury/availability item with FPL's current text, and deletes articles older than 14 days and injury items FPL has cleared.

Up to about 24 hours behind (nightly)

Run more often on matchdays if you want results sooner — each run takes a minute or two, and steady-state runs make very few requests to FPL.

Option A — cron (simplest, any Linux/macOS host)

# Press content: nightly at midnight UTC
0 0 * * * /path/to/venv/bin/fpl-context-ingest-press >> /var/log/fpl-context-ingest-press.log 2>&1

# Match data: twice daily during the season (06:00 + 22:00 UTC)
0 6,22 * * * /path/to/venv/bin/fpl-context-ingest-match >> /var/log/fpl-context-ingest-match.log 2>&1

Adjust the match-data cadence to the calendar:

Period

Recommended cadence

PL season (Aug–May)

Twice daily, 0 6,22 * * *

World Cup / tournament group stage

Hourly, 0 * * * *

World Cup / tournament knockout

Every 6 hours, 0 */6 * * *

Off-season

Once daily, 0 8 * * *

Option B — GitHub Actions in your own private repo (free, no server needed)

Best if you don't have a machine that's always on. You don't fork this project — you create a tiny repo of your own with one file that installs the package from PyPI and runs the two commands on a schedule.

  1. Create a new private GitHub repository (any name).

  2. Add this file as .github/workflows/ingest.yml:

    name: Ingest sports data
    
    on:
      schedule:
        - cron: "0 6,22 * * *" # twice daily, UTC
      workflow_dispatch: {} # lets you run it by hand from the Actions tab
    
    jobs:
      ingest:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/setup-python@v5
            with:
              python-version: "3.11"
          - run: pip install fpl-context-mcp
          - name: Ingest press content
            run: fpl-context-ingest-press
            env:
              PINECONE_API_KEY: ${{ secrets.PINECONE_API_KEY }}
              PINECONE_INDEX_NAME: ${{ secrets.PINECONE_INDEX_NAME }}
              GUARDIAN_API_KEY: ${{ secrets.GUARDIAN_API_KEY }}
          - name: Ingest match data
            run: fpl-context-ingest-match
            env:
              DATABASE_URL: ${{ secrets.DATABASE_URL }}
              DATABASE_ETL_URL: ${{ secrets.DATABASE_ETL_URL }}
  3. In that repo: Settings → Secrets and variables → Actions → New repository secret, and add PINECONE_API_KEY, DATABASE_URL, and DATABASE_ETL_URL. GUARDIAN_API_KEY is strongly recommended — without it the Guardian source is skipped and only BBC Sport articles are ingested (register a free key at open-platform.theguardian.com). PINECONE_INDEX_NAME is optional and defaults to fpl-context.

  4. Open the Actions tab, pick "Ingest sports data", and click Run workflow once to seed your data. From then on it runs by itself on the schedule.

Notes:

  • A failed run turns red and GitHub emails you (missing credentials, a database that's unreachable, an API outage), so you'll know if data stops flowing.

  • Updates: pip install fpl-context-mcp grabs the latest release on every run, so fixes arrive automatically. Pin a version (fpl-context-mcp==0.3.0) if you'd rather upgrade on purpose.

  • Cost: each run takes about a minute or two, so a twice-daily schedule stays well inside GitHub's free monthly minutes for private repos.

  • Why private: GitHub automatically pauses scheduled workflows in public repos after 60 days without a commit. Private repos aren't paused.

Option C — any other scheduler

Managed cron (Render, Railway, Fly.io machines, GCP Cloud Scheduler + Cloud Run Jobs, AWS EventBridge + Lambda/Fargate, systemd timers, Airflow, Dagster, etc.) all work the same way — point it at fpl-context-ingest-press and fpl-context-ingest-match (or the python -m jobs.* equivalents) with the cadence table above and the environment variables from Configuration.

Whichever option you pick, re-run fpl-context-mcp --check afterward to confirm the scheduled job's credentials actually work in that environment — a job that silently fails every night is worse than no job, since nothing tells you the data's gone stale.


Registering with Claude Desktop

Add the server to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows).

{
  "mcpServers": {
    "fpl-context": {
      "command": "fpl-context-mcp",
      "env": {
        "DATABASE_URL": "postgresql://fpl_readonly:password@localhost:5432/fpl",
        "PINECONE_API_KEY": "pcsk_..."
      }
    }
  }
}

If running from source

{
  "mcpServers": {
    "fpl-context": {
      "command": "python",
      "args": ["/absolute/path/to/fpl-context-mcp/server.py"],
      "env": {
        "DATABASE_URL": "postgresql://fpl_readonly:password@localhost:5432/fpl",
        "PINECONE_API_KEY": "pcsk_..."
      }
    }
  }
}

Tip: If you use uv, replace "python" with "uv" and prepend "run" to args:

"command": "uv",
"args": ["run", "/absolute/path/to/fpl-context-mcp/server.py"]

Restart Claude Desktop. You should see fpl-context appear in the tools panel. If either tool returns nothing useful, re-check Seeding data and Keeping data fresh before assuming the server itself is broken.


Other AI clients (local)

Any client that can launch a local MCP server (stdio) works the same way: run the fpl-context-mcp command with DATABASE_URL and PINECONE_API_KEY in its environment. Swap in your own values below.

Claude Code

claude mcp add fpl-context -e DATABASE_URL=postgresql://fpl_readonly:password@localhost:5432/fpl -e PINECONE_API_KEY=pcsk_... -- fpl-context-mcp

Cursor (~/.cursor/mcp.json), Windsurf (~/.codeium/windsurf/mcp_config.json) and Gemini CLI (~/.gemini/settings.json) all use the same mcpServers shape as Claude Desktop:

{
  "mcpServers": {
    "fpl-context": {
      "command": "fpl-context-mcp",
      "env": {
        "DATABASE_URL": "postgresql://fpl_readonly:password@localhost:5432/fpl",
        "PINECONE_API_KEY": "pcsk_..."
      }
    }
  }
}

VS Code (Copilot agent mode) — .vscode/mcp.json in your workspace:

{
  "servers": {
    "fpl-context": {
      "type": "stdio",
      "command": "fpl-context-mcp",
      "env": {
        "DATABASE_URL": "postgresql://fpl_readonly:password@localhost:5432/fpl",
        "PINECONE_API_KEY": "pcsk_..."
      }
    }
  }
}

OpenAI Codex CLI — ~/.codex/config.toml:

[mcp_servers.fpl-context]
command = "fpl-context-mcp"
env = { DATABASE_URL = "postgresql://fpl_readonly:password@localhost:5432/fpl", PINECONE_API_KEY = "pcsk_..." }

Without installing first — if you have uv, use "command": "uvx" with "args": ["fpl-context-mcp"] in any of the configs above.

Your own agent code — the MCP SDKs (Python, TypeScript) and agent frameworks such as the OpenAI Agents SDK can launch fpl-context-mcp as a stdio server, or connect to it over HTTP as below.


Remote access over HTTP (ChatGPT and other URL-only clients)

Some clients can't launch a local process — they only accept a server URL. That includes ChatGPT (Settings → Apps & Connectors → Advanced → Developer mode → create a connector) and custom connectors on claude.ai. For these, run the server with the streamable HTTP transport on a machine with a public HTTPS address:

MCP_AUTH_TOKEN=some-long-random-string \
fpl-context-mcp --transport http --host 0.0.0.0 --port 8000
  • The MCP endpoint is https://<your-host>/mcp; GET /health returns ok for load-balancer and platform health checks.

  • --transport, --host and --port can also be set with MCP_TRANSPORT, MCP_HOST and MCP_PORT (or the PORT variable that Render, Cloud Run, Heroku and Fly set).

  • The server listens on plain HTTP. Put it behind something that terminates TLS — any of those platforms does, or cloudflared tunnel / ngrok for a quick test from your own machine.

  • The default bind address is 127.0.0.1, so nothing is exposed until you pass --host 0.0.0.0.

Authentication. With MCP_AUTH_TOKEN set, every request to /mcp must send Authorization: Bearer <token>; others get HTTP 401. Clients that let you set headers can use it — for example Claude Code:

claude mcp add --transport http fpl-context https://your-host/mcp --header "Authorization: Bearer some-long-random-string"

and the OpenAI Agents SDK / Responses API MCP tool (headers={"Authorization": "Bearer ..."}).

ChatGPT and claude.ai connectors only support OAuth or no authentication — not a static bearer token. To use them you currently have to leave MCP_AUTH_TOKEN unset (the endpoint is then open to anyone who finds the URL) or put an OAuth-capable proxy in front. If you run it open, understand what that exposes: anyone can run read-only SELECTs against the database behind DATABASE_URL (10-second timeout, 100-row cap) and use up your Pinecone query quota. Only do that with the dedicated fpl_readonly role on a database that holds nothing but FPL data. The server logs a warning at startup when it's bound to a non-local address without a token.

Where the data comes from. A hosted server reads your database and index, exactly like a local one — you still need the ingestion jobs on a schedule (Keeping data fresh). And because you're now serving results to other people, see Data sources and disclaimer.


Running the server standalone

# If installed from PyPI
fpl-context-mcp

# If running from source
python server.py

By default the server communicates over stdio — it is designed to be launched by an MCP client, and running it directly is mainly useful for smoke-testing startup and environment variable loading. To run it as a persistent network service instead, use --transport http (see Remote access over HTTP).


Verifying connectivity (--check)

Before registering the server with a client — and any time something seems off — verify that your environment variables are correct and all backends are reachable:

# If installed from PyPI
fpl-context-mcp --check

# If running from source
python server.py --check

Output example:

=== fpl-context-mcp configuration check ===

✅ Pinecone          connected (index: 'fpl-context')
✅ PostgreSQL (RO)   connected (localhost:5432/fpl)
✅ PostgreSQL (ETL)  connected (localhost:5432/fpl)
✅ Guardian API      registered key configured

✅ All required components OK

The command exits with code 0 if all required components pass, or 1 if any required component fails. Optional components (Guardian API) emit warnings but do not cause a non-zero exit — a missing GUARDIAN_API_KEY just means Guardian articles are skipped. Note that --check only verifies connectivity — it doesn't tell you whether your tables/index actually have data in them; for that, see Seeding data.


Dry-run mode

Set DRY_RUN=true to fetch data and verify routing without writing anything to Pinecone or PostgreSQL:

DRY_RUN=true fpl-context-mcp
DRY_RUN=true fpl-context-ingest-press

In dry-run mode:

  • Tools return a human-readable description of the call that would have been made — the SQL with host, or the Pinecone index/namespace/params — without opening any connection.

  • Ingestion jobs still call all external APIs (verifying connectivity) but skip every Pinecone and PostgreSQL write. Log output shows how many documents would have been upserted.

  • The server logs a DRY RUN MODE warning at startup so it is obvious from the logs.

Accepted values for DRY_RUN: true, 1, yes (case-insensitive). Any other value (or absent) disables dry-run.


MCP tools reference

query_historical_stats

Executes a read-only SQL SELECT against the historical stats database.

Parameters

Parameter

Type

Description

sql

string

A SELECT statement. Mutations are rejected before reaching the database. LIMIT is injected automatically if omitted (capped at 100 rows).

Example prompts

  • "Who are the top 10 midfielders by total points this season?"

  • "Which players have scored the most goals this season?"

  • "Show my captain candidate's goals and points over the last five seasons." (past seasons only cover players still in the current FPL list)

  • "When is the next gameweek deadline?"

  • "Which teams have the best defensive record at home this season?"

Safety

The tool enforces two layers of protection: a keyword blocklist rejects INSERT, UPDATE, DELETE, DROP, and similar statements before any database call is made, and the database connection uses a read-only role with no write grants.


query_press_conferences

Semantic search over Premier League press coverage ingested from BBC Sport and The Guardian.

Parameters

Parameter

Type

Default

Description

query

string

—

Natural-language question or topic

top_k

integer

5

Number of documents to return

recency_weight

float

0.3

Recency boost: 0.0 = pure semantic similarity, 1.0 = heavy recency bias

Ranking formula

Results are re-ranked after retrieval:

final_score = semantic_score × (1 + recency_weight × recency_score)

recency_score is 1.0 for an article published today and decays toward 0.1 over 14 days.

Example prompts

  • "Any injury concerns for Saka this week?"

  • "What did Slot say about Salah's contract situation?"

  • "Who is doubtful for Arsenal's next match?"

No results? If the press namespace hasn't been seeded yet, or everything in it has aged out past 14 days, this tool returns a message explaining that instead of an empty response — see Keeping data fresh.


Database schema

The query_historical_stats tool has access to these tables (see db/schema.sql for the full DDL if provisioning standalone):

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, status, news

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

Current vs past seasons: teams, gameweeks, fixtures and gw_player_stats hold the current season only. players also holds one totals-only row per player per past season (see Seeding data for what that covers and what it misses).

Join hint: teams.fpl_id = players.team_fpl_id (current season, same season_id; team_fpl_id is NULL for past seasons).


Running tests

# Install dev dependencies if you haven't already
pip install -e ".[dev]"

# Run the full suite (all mocked — no real DB or API calls)
pytest tests/ -v

# Lint and format
ruff check . && ruff format .

The test suite covers:

File

What's tested

tests/test_config.py

Env var reading, defaults, dotenv loading, dry-run flag

tests/test_tools_stats.py

Mutation guard, row formatter, async DB path, dry-run

tests/test_tools_press.py

Pinecone query, recency re-ranking, degradation, dry-run

tests/test_ingest_press_content.py

BBC/Guardian fetchers, deduplication, orchestration, dry-run

tests/test_ingest_match_data.py

Fixture/gameweek upserts, stats selection, thread coordination, rollback, dry-run

tests/test_server_http.py

HTTP transport: bearer-token auth, /health, no /mcp redirect, CLI/env argument parsing

tests/test_backfill_history.py

Past-season backfill: season handling, NULL team, best-effort ALTER, exit codes


Extending with new press sources

To add a new press source, subclass _BaseFetcher in jobs/ingest_press_content.py and add an instance to the FETCHERS list. The orchestrator picks it up automatically — no other changes needed.

class MySportsFetcher(_BaseFetcher):
    source_name = "My Sports Site"

    def fetch(self) -> list[tuple[str, str, dict]]:
        # return a list of (doc_id, text, metadata) tuples
        ...


FETCHERS: list[_BaseFetcher] = [BBCSportFetcher(), GuardianAPIFetcher(), MySportsFetcher()]

Each tuple is (doc_id, text, metadata) where:

  • doc_id — a stable 32-char hex ID (use _doc_id(source + url))

  • text — the full text to embed, prefixed with the source name

  • metadata — must include type, source, recency_score, and pub_timestamp


Data sources and disclaimer

fpl-context-mcp is an independent open-source project. It is not affiliated with, endorsed by, or sponsored by the Premier League, Fantasy Premier League, the BBC, or Guardian News & Media.

The package ships no data. The ingestion jobs fetch it, on your machine and under your credentials, from:

Source

Used for

Notes

Fantasy Premier League API (fantasy.premierleague.com/api)

Players, teams, fixtures, match stats, injury news

Unofficial and undocumented; it can change or rate-limit without notice.

BBC Sport RSS feed

Press articles

BBC feeds are provided for personal, non-commercial use under the BBC's terms.

The Guardian Open Platform

Press articles

Requires your own API key, and use is governed by the Guardian's Open Platform terms (the free developer tier is non-commercial).

You are responsible for complying with each source's terms of use for the data you ingest, store, and — if you host the server for other people — serve. This is especially relevant for commercial use and for public deployments. The MIT license below covers this project's code only, not any third-party content it retrieves.


License

MIT © 2026 Shubham Banthia

Available Tools

2 tools
query_historical_statsA

Execute a read-only SQL SELECT against the FPL stats database. Use this to answer questions about player stats, fixtures, team strength, or gameweek history for the seasons in the database.

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, status, news 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.

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

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

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries full disclosure burden. It states the operation is read-only, enumerates the exposed tables, and discloses critical behavioral caveats: current-season-only tables, past-season rows lacking team_fpl_id, and incomplete past-season league/team totals due to departed players being absent. This is exactly the kind of context an agent needs before generating SQL.

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?

The description is long, but the length is earned: it provides a full denormalized schema for a SQL tool. It is front-loaded with the purpose, then structured into table list, notes, and join hint. Minor redundancy ('read-only' appears twice) keeps it from a 5.

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 read-only SQL tool with no output schema, this is complete: it covers what can be queried, table relationships, current vs. past season behavior, and data-quality limitations. No required input or result-shape information 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 100% for the single sql parameter, so the baseline is 3. The description adds substantial meaning beyond the schema by providing the full table/column inventory, join hints, and season-scoping notes, enabling the agent to write realistic SELECT statements rather than guessing table names.

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?

Description opens with a specific verb and resource: 'Execute a read-only SQL SELECT against the FPL stats database.' It then names the exact question types in scope (player stats, fixtures, team strength, gameweek history), and the table list makes clear it is a general stats/history query tool, distinguishing it from the press-conference sibling.

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?

'Use this to answer questions about player stats, fixtures, team strength, or gameweek history' gives direct guidance on when to call it. It does not explicitly name the sibling alternative or state exclusions (e.g., press-conference questions), but with only one sibling and a clear scope, the context is strong.

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

query_press_conferencesA

Semantic search over Premier League press conference summaries, match reports, and player injury/availability updates ingested from BBC Sport and The Guardian. Use this to find recent quotes, injury news, or manager/team news.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesNatural-language question or topic to search for.
top_kNoNumber of documents to retrieve. Default 5.
recency_weightNoHow strongly to boost recent articles in ranking. 0.0 = pure semantic similarity, 1.0 = heavy recency bias. Default 0.3.

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does clarify that this is a semantic search over ingested articles with defined sources and content types, but it does not describe the output format, ranking behavior beyond the schema, or limitations such as no exact-match guarantee, which would help an agent set expectations.

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 two sentences with no filler. The core operation and scope are front-loaded, followed by concrete use cases. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple and the schema covers all three parameters, but there is no output schema, so the description should clarify what the agent will receive (e.g., matched document snippets, source links, relevance scores). It adequately covers what the tool searches over and why to use it, but the return shape is left implicit.

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 parameters are already well documented. The description adds context about the overall semantic-search behavior and the 'recent' emphasis, which loosely relates to recency_weight, but it does not add new parameter-level meaning beyond what the schema provides.

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 names a specific operation ('Semantic search'), a clear resource ('Premier League press conference summaries, match reports, and player injury/availability updates'), and identifies the data sources. This distinguishes it from the sibling tool query_historical_stats, which is about historical statistics rather than news, quotes, and injury updates.

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 description explicitly tells the agent when to use the tool: 'Use this to find recent quotes, injury news, or manager/team news.' It provides clear usage context, though it does not explicitly state when not to use it or mention the sibling alternative by name.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.0
    • First observedquery_historical_stats
    • First observedquery_press_conferences

TDQS

A4.2/5.0

Scored across 2 tools

Disambiguation5/5

The two tools are completely distinct in purpose: one executes SQL queries on structured stats data, the other performs semantic search over press conference text. There is zero overlap, so an agent can unambiguously select the correct tool.

Naming Consistency5/5

Both tools follow the exact same 'query_' + noun pattern (query_historical_stats, query_press_conferences). This is a perfectly consistent and predictable naming convention.

Tool Count3/5

With only 2 tools, the surface is thin, but it matches the narrow scope of providing FPL context (stats and news). It sits at the borderline where the count is low but arguably sufficient for the server's stated purpose.

Completeness4/5

The two tools cover the core needs of an FPL context server: historical/current stats via SQL and recent news/availability via press conferences. Minor gaps exist (e.g., no dedicated tool for current standings or transfers), but the SQL tool can be used to derive much of that, so the surface is largely complete.

Maintenance

ActivityNo data
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    B
    quality
    D
    maintenance
    Enables interaction with Fantasy Premier League data through natural language queries. Supports retrieving fixtures, league standings, player performance, and other FPL statistics via the official FPL API.
    16
    15 npm
    3
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    Connects LLMs to the Fantasy Premier League API for intelligent team management, enabling natural language player research, competitor analysis, transfer decisions, and strategic planning using friendly names instead of IDs.
    3
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    AI-powered Fantasy Premier League assistant — scored captain picks, transfer suggestions, differentials, fixture outlook, price predictions, live points, and a full manager hub that auto-detects your squad, bank balance, and free transfers.
    2
    13
    11
    MIT
  • A
    license
    A
    quality
    C
    maintenance
    Enables AI assistants to analyze Fantasy Premier League data, providing tools for player search, fixture analysis, manager comparisons, and strategy prompts for transfer planning and lineup selection.
    19
    17 PyPI
    1
    MIT