Pitstop — F1 MCP Server

An HTTP-first Model Context Protocol (MCP) server for Formula 1 data. Aggregates real-time, historical, and news data from multiple authoritative sources into 11 tools ready for any MCP client.

v0.5.0 | Author: Praneeth Ravuri

Install

stdio, via uvx (no clone needed):

PITSTOP_TRANSPORT=stdio uvx pitstop-f1

Via the Claude Code CLI:

claude mcp add pitstop -e PITSTOP_TRANSPORT=stdio -- uvx pitstop-f1

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "pitstop": {
      "command": "uvx",
      "args": ["pitstop-f1"],
      "env": { "PITSTOP_TRANSPORT": "stdio" }
    }
  }
}

Docker (HTTP transport, runs the full server incl. the F1 database):

docker compose up
# → http://localhost:8000/mcp

Overview

Pitstop exposes F1 data as 11 MCP tools over HTTP (default) or stdio. It pulls from FastF1, Jolpica, OpenF1, Wikidata, RSS feeds, and its own seeded F1 database, handling pagination, retries, caching, and concurrency limits transparently.

Data Sources

Database refresh: .github/workflows/db-update.yml runs weekly to pull new Jolpica results into the owned F1 database.

Tools

Transport

HTTP (default)

uv sync
uv run pitstop
# → http://localhost:8000

MCP client config:

{
  "mcpServers": {
    "pitstop": {
      "type": "http",
      "url": "http://localhost:8000/mcp"
    }
  }
}

stdio (opt-in)

PITSTOP_TRANSPORT=stdio uv run pitstop

MCP client config:

{
  "mcpServers": {
    "pitstop": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/pitstop", "pitstop"],
      "env": { "PITSTOP_TRANSPORT": "stdio" }
    }
  }
}

Health API

Example /health response:

{
  "version": "0.5.0",
  "overall": "ok",
  "sources": [
    { "name": "fastf1",  "status": "ok", "latency_ms": 2,   "detail": "cache writable" },
    { "name": "f1db",    "status": "ok", "latency_ms": 1,   "detail": "" },
    { "name": "jolpica", "status": "ok", "latency_ms": 134, "detail": "" },
    { "name": "openf1",  "status": "ok", "latency_ms": 98,  "detail": "" },
    { "name": "rss",     "status": "ok", "latency_ms": 210, "detail": "" }
  ]
}

overall is "ok" / "degraded" / "down". HTTP 200 / 207 / 503.

Wikidata SPARQL

query_wikidata runs SPARQL queries against Wikidata for biographical and historical F1 facts not covered by race APIs.

Only SELECT and ASK queries are accepted (read-only). Always include LIMIT in your query.

Example — find F1 drivers with their birthdate:

SELECT ?driver ?driverLabel ?birthDate WHERE {
  ?driver wdt:P31 wd:Q5 ;
          wdt:P641 wd:Q1968 ;
          wdt:P569 ?birthDate .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" }
} ORDER BY DESC(?birthDate) LIMIT 10

Pagination

All list-returning tools accept page (1-based, default 1) and page_size (defaults vary per tool: 10–50). Responses include a pagination block:

{
  "data": [...],
  "pagination": {
    "page": 1,
    "page_size": 20,
    "total_items": 47,
    "total_pages": 3,
    "has_next": true,
    "has_prev": false
  }
}

Configuration

Caching

Pitstop uses in-memory HTTP response caching (via Hishel) for GET requests with 200 responses. This keeps tool calls inside upstream rate limits:

• Jolpica: 4 req/s, 500/hr
• OpenF1: 3 req/s, 30/min
• Wikidata: Query complexity limits
• RSS: Per-feed redirects cached

FastF1 maintains its own disk cache in FASTF1_CACHE directory. Control caching via:

• PITSTOP_ENABLE_CACHING=true (default)
• PITSTOP_CACHE_TTL_SECONDS=300 (default)

Development

uv sync --dev
uv run pytest
uv run ruff check src/

Contributing

See CONTRIBUTING.md.

Credits & attribution

Not affiliated with Formula 1 or the FIA. Data provided by third-party sources under their respective terms.