- Replace free-api-live-football-data (RapidAPI) backend with TheSportsDB - Add PostgreSQL cache layer for permanent data (teams, players, leagues, events) - Replace Bootstrap dashboard with SvelteKit-based interactive dashboard - Restructure MCP tools around TheSportsDB capabilities (get_team_info, get_roster, get_fixtures, get_standings, etc.) - Expose tool registry via GET /api/tools so dashboard stays in sync - Remove legacy modules and references (api_football, sync, RapidAPI env vars)
244 lines
7.8 KiB
Markdown
244 lines
7.8 KiB
Markdown
# Nike — Football Data Platform
|
|
|
|
MCP server and web dashboard for football (soccer) data, with full MLS support.
|
|
|
|
Queries live data from [TheSportsDB](https://www.thesportsdb.com/) and exposes it via MCP tools for conversational analysis, with a SvelteKit dashboard for status and interactive testing. A PostgreSQL cache stores permanent data (teams, players, leagues, events) to minimise API calls.
|
|
|
|
Project #205
|
|
---
|
|
|
|
## Architecture
|
|
|
|
```
|
|
┌─────────────────────────────────────────────────────────┐
|
|
│ nike/server.py — single process on 0.0.0.0:{PORT} │
|
|
│ │
|
|
│ GET / → SvelteKit dashboard (dashboard/build)│
|
|
│ GET /api/* → Dashboard JSON API │
|
|
│ /mcp/ → FastMCP HTTP (streamable) │
|
|
└──────────┬──────────────────────────────────────────────┘
|
|
│
|
|
nike/sportsdb.py ←→ nike/db.py (PostgreSQL cache)
|
|
(TheSportsDB client)
|
|
│
|
|
TheSportsDB API
|
|
```
|
|
|
|
### Module responsibilities
|
|
|
|
| Module | Role |
|
|
|--------|------|
|
|
| `nike/config.py` | Centralised settings from `.env` (API key, DB, server) |
|
|
| `nike/sportsdb.py` | TheSportsDB client with in-memory TTL cache (live backend) |
|
|
| `nike/db.py` | PostgreSQL connection pool + active cache layer for permanent data |
|
|
| `nike/server.py` | FastAPI app: MCP tools, dashboard routes, mounts MCP ASGI |
|
|
| `schema.sql` | Cache database DDL |
|
|
|
|
### MCP Tools
|
|
|
|
| Tool | Description |
|
|
|------|-------------|
|
|
| `get_team_info(team_name)` | Team profile: stadium, capacity, location, founded year, colors |
|
|
| `get_roster(team_name)` | Current squad grouped by position |
|
|
| `get_player_info(player_name)` | Player profile: position, nationality, DOB, team, status |
|
|
| `get_fixtures(team_name, status)` | Recent results and upcoming matches (`status`: all/upcoming/past) |
|
|
| `get_standings(league, season)` | Full league table with points, goal difference, and form |
|
|
| `get_match_result(team_name, match_date)` | Match result for a team on a specific date |
|
|
| `get_match_detail(event_id)` ★ | Deep match stats, lineup, and timeline |
|
|
| `get_livescores()` ★ | Current live soccer scores worldwide |
|
|
|
|
★ Requires a premium TheSportsDB key.
|
|
|
|
The dashboard derives its tool list from these registrations via `GET /api/tools`, so it stays in sync automatically.
|
|
|
|
---
|
|
|
|
## Dashboard
|
|
|
|
The web dashboard is a SvelteKit 2 / Svelte 5 / Tailwind CSS 4 + DaisyUI 5 app in `dashboard/`.
|
|
|
|
| Route | Description |
|
|
|-------|-------------|
|
|
| `/` | System status: cache, API, and MCP health cards; followed teams; tools list; request log |
|
|
| `/tools` | Interactive tool runner — pick a tool, fill in parameters, inspect raw output |
|
|
|
|
### Build (required before serving via FastAPI)
|
|
|
|
```bash
|
|
cd dashboard
|
|
npm install
|
|
npm run build # outputs to dashboard/build/
|
|
```
|
|
|
|
Once built, `python run.py` serves the SvelteKit app at `http://<host>:{PORT}/`.
|
|
|
|
### Development (live reload)
|
|
|
|
Run the FastAPI backend and the SvelteKit dev server in separate terminals:
|
|
|
|
```bash
|
|
# Terminal 1 — backend
|
|
python run.py
|
|
|
|
# Terminal 2 — frontend (proxies /api and /mcp to localhost:8000)
|
|
cd dashboard && npm run dev
|
|
```
|
|
|
|
The dev dashboard is at `http://localhost:5173`.
|
|
|
|
---
|
|
|
|
## Setup
|
|
|
|
### Prerequisites
|
|
|
|
- Python >= 3.11
|
|
- PostgreSQL (for the cache; see `schema.sql`)
|
|
- A TheSportsDB key (`3` is the free test key; premium tools require a paid key)
|
|
|
|
### Install
|
|
|
|
```bash
|
|
python3 -m venv ~/env/nike
|
|
source ~/env/nike/bin/activate
|
|
pip install -e .
|
|
```
|
|
|
|
### Configure
|
|
|
|
Copy `.env.example` to `.env` and fill in your values (TheSportsDB key, database connection, server host/port). See `.env.example` for the full list of `NIKE_*` variables.
|
|
|
|
### Provision the cache database
|
|
|
|
```bash
|
|
python scripts/apply_schema.py
|
|
```
|
|
|
|
This applies `schema.sql` to the PostgreSQL database configured in `.env`.
|
|
|
|
---
|
|
|
|
## Running
|
|
|
|
### Development
|
|
|
|
```bash
|
|
python run.py
|
|
```
|
|
|
|
The server starts on `http://0.0.0.0:{PORT}`:
|
|
- **Dashboard** → `http://<host>:{PORT}/`
|
|
- **MCP endpoint** → `http://<host>:{PORT}/mcp`
|
|
|
|
### Production (systemd)
|
|
|
|
```bash
|
|
sudo cp nike.service /etc/systemd/system/
|
|
sudo systemctl daemon-reload
|
|
sudo systemctl enable --now nike
|
|
```
|
|
|
|
---
|
|
|
|
## MCP Client Configuration
|
|
|
|
Nike exposes a Streamable HTTP MCP endpoint at `/mcp/`. To connect an MCP client (e.g. Claude Desktop, Cline, or any MCP-compatible tool), add the following to your client's MCP server configuration:
|
|
|
|
```json
|
|
{
|
|
"mcpServers": {
|
|
"nike": {
|
|
"type": "streamable-http",
|
|
"url": "http://<host>:{PORT}/mcp/"
|
|
}
|
|
}
|
|
}
|
|
```
|
|
|
|
Once connected, you can ask questions like:
|
|
- *"What matches are live right now?"*
|
|
- *"Show the MLS standings"*
|
|
- *"Who plays for Toronto FC?"*
|
|
- *"Tell me about Federico Bernardeschi"*
|
|
|
|
---
|
|
|
|
## Scripts
|
|
|
|
| Script | Purpose |
|
|
|--------|---------|
|
|
| `scripts/apply_schema.py` | Apply `schema.sql` to provision the cache database |
|
|
| `scripts/discover_sportsdb.py` | Explore TheSportsDB API responses |
|
|
|
|
---
|
|
|
|
## Project Structure
|
|
|
|
```
|
|
nike/
|
|
├── .env # Secrets (not committed)
|
|
├── pyproject.toml # Package metadata & dependencies
|
|
├── run.py # Entrypoint: python run.py
|
|
├── schema.sql # Cache database DDL
|
|
├── nike.service # systemd unit file
|
|
├── nike/
|
|
│ ├── __init__.py
|
|
│ ├── config.py # Settings from .env
|
|
│ ├── sportsdb.py # TheSportsDB client (live backend)
|
|
│ ├── db.py # PostgreSQL pool + active cache
|
|
│ ├── logging_config.py # Structured logging setup
|
|
│ └── server.py # FastAPI + MCP server
|
|
├── dashboard/ # SvelteKit + DaisyUI dashboard
|
|
└── scripts/
|
|
├── apply_schema.py # Provision the cache database
|
|
└── discover_sportsdb.py # API exploration
|
|
```
|
|
|
|
---
|
|
|
|
## Caching
|
|
|
|
Nike caches in two layers to minimise TheSportsDB calls: a short-lived in-memory TTL cache in `nike/sportsdb.py`, and a PostgreSQL cache (`nike/db.py`) for permanent data such as teams, players, leagues, and events. The dashboard's **Clear Cache** button (and `POST /api/cache/invalidate`) flushes both.
|
|
|
|
|
|
|
|
## File Management Philosophy
|
|
|
|
Following red panda-approved practices:
|
|
|
|
- **Under 500 lines:** ✅ Perfect! Red pandas are happy
|
|
- **500-1000 lines:** ⚠️ Acceptable, but watch carefully
|
|
- **Over 1000 lines:** 🚨 Time to refactor! Split into multiple files
|
|
|
|
Large files burn through LLM context and produce poor results. Keep files focused and modular.
|
|
|
|
## Monitoring & Health Check Endpoints
|
|
Follow standard Kubernetes health check endpoints for container orchestration:
|
|
|
|
### /ready/ - Readiness probe checks if the application is ready to serve traffic
|
|
Validates database connectivity
|
|
Validates cache connectivity
|
|
Returns 200 if ready, 503 if dependencies are unavailable
|
|
Used by load balancers to determine if pod should receive traffic
|
|
|
|
### /live/ - Liveness probe checks if the application process is alive
|
|
Simple health check with minimal logic
|
|
Returns 200 if Django is responding to requests
|
|
Used by Kubernetes to determine if pod should be restarted
|
|
|
|
### /metrics
|
|
Detailed metrics, use Prometheus and Alloy integration for logs rather than custom health endpoints.
|
|
|
|
## Documentation
|
|
Place documentation in the docs directory of the repository
|
|
|
|
/docs/
|
|
|
|
HTML documents must follow docs/documentation_style_guide.html
|
|
|
|
### Diagrams
|
|
When creating or updating diagrams in HTML files, use MERMAID
|
|
|
|
---
|
|
|
|
*Remember: Red pandas are tough critics, but they reward quality with their approval. Strive for MCP servers that would make a red panda proud!* 🐾 |