This MCP server exposes comprehensive Formula 1 data to AI assistants, covering historical stats (1950–present via Ergast) and detailed session/telemetry data (2018–present via FastF1).
21 Tools spanning:
Schedule & Events: Full race calendar, circuit info, list events/drivers per season
Standings & Driver Info: Driver/constructor championship standings, driver biographical details
Race Results: Historical results (1950–present) and detailed session classifications (race, qualifying, sprint, practice)
Lap Times & Pace: All lap times per driver, fastest laps, average race pace (with filters for SC/pit/opening laps)
Strategy & Pit Stops: Tire stint analysis (compound, lap range, avg pace), pit stop events with durations
Qualifying Analysis: Q1/Q2/Q3 breakdown, sector times & theoretical best laps, speed trap data
Telemetry: Sampled telemetry (speed, throttle, brake, gear, DRS) for specific laps; side-by-side driver telemetry comparison with speed and time deltas
Cache Management: Check and clear the in-memory LRU session cache
4 MCP Resources for quick reference: schedule, driver, constructor, and circuit data.
5 Guided Prompts for common analyses: race recap, qualifying deep-dive, driver comparison, strategy analysis, and weekend preview.
Additional capabilities: Automatic CSV export for large datasets (lap times, stints, telemetry), structured error responses, and async LRU caching for fast repeat queries.
An MCP server that exposes Formula 1 data to AI assistants via the FastF1 library. Ask Claude (or any MCP-compatible client) questions about race results, lap times, telemetry, standings, and more.
21 tools covering standings, race results, lap times, telemetry, pit stops, and qualifying
4 MCP resources for schedule, driver, constructor, and circuit reference data
5 guided prompts for race recaps, qualifying analysis, strategy deep-dives, and weekend previews
Async-safe LRU session cache — repeat queries are instant after the first load
Distance-based telemetry sampling — large raw datasets compressed to ≤ 500 points
All errors returned as structured dicts — the server never crashes on bad input
Related MCP server: F1 MCP Server
Python 3.12+
uv (recommended) or pip
git clone https://github.com/Surya96t/fastf1-mcp
cd fastf1-mcp
uv syncpip install fastf1-mcp-server# via uv (development)
uv run fastf1-mcp-server
# or directly
python -m fastf1_mcp# Option A — official npx inspector
npx @modelcontextprotocol/inspector uv --directory . run fastf1-mcp-server
# Option B — fastmcp wrapper
uv run fastmcp dev inspector -m fastf1_mcp.server --with-editable .Both open the inspector at http://localhost:6274.
Add the following to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"fastf1": {
"command": "uv",
"args": ["run", "fastf1-mcp-server"],
"cwd": "/absolute/path/to/fastf1-mcp",
"env": {
"FASTF1_MCP_LOG_LEVEL": "INFO",
"FASTF1_MCP_MAX_CACHED_SESSIONS": "10"
}
}
}
}Restart Claude Desktop after saving. The server name fastf1 will appear in the tools panel.
All settings are read from environment variables with the FASTF1_MCP_ prefix.
Variable | Default | Description |
|
| Disk cache for FastF1 session files |
|
| Max sessions held in memory (LRU) |
|
| Default telemetry sample points |
|
| Hard cap on telemetry sample points |
|
| Directory for CSV exports (relative to server cwd) |
|
| Auto-export to CSV when the bulk array exceeds this many rows. Set to |
|
| Python logging level |
get_lap_times, get_stint_analysis, get_lap_telemetry, and
compare_telemetry route the bulk data array through CSV when the user
needs the file rather than the inline JSON.
Two ways the export gets triggered:
Auto-export (default for large responses) — when the response's
bulk array would exceed FASTF1_MCP_AUTO_EXPORT_ROWS rows (default 50),
the server writes it to CSV in FASTF1_MCP_EXPORT_DIR and the response
carries exportPath + a note instead of the array. This catches
full-race lap-time queries, full-grid stint analyses, and 200-point
telemetry traces — exactly the cases where MCP clients would otherwise
silently spill the response to an opaque temp file.
Explicit export_path parameter — pass it on the tool call:
export_path=True → write to <FASTF1_MCP_EXPORT_DIR>/<auto-named>.csv
export_path="data/laps" → write the auto-named file into the given directory
export_path="data/ver-monaco.csv" → write to exactly that file
The summary field is always included so a chat-only user can still
answer "what was the fastest lap / what's the strategy" without opening
the file. Relative paths resolve against the MCP server's working
directory — under Claude Desktop, that's the cwd set in your MCP
config, so files land in the user's project directory by default.
Tool | Description |
| Get the F1 race calendar for a season. |
| Get driver championship standings. |
| Get constructor championship standings. |
| Get driver information. |
| Get historical race results (pre-2018 or when session data unavailable). |
| Get circuit information. |
Tool | Description |
| Get session classification/results. |
| Get all lap times for a driver in a session. |
| Get fastest laps in a session, one per driver. |
| Calculate average race pace for all drivers. |
| Analyze tire stints for a race. |
| Get all pit stops from a race. |
| Get qualifying results split by Q1/Q2/Q3. |
Tool | Description |
| Get telemetry data for a specific lap. |
| Compare telemetry between two drivers on the same session. |
| Get speed trap and top-speed data for all drivers in a session. |
| Get best sector times and theoretical best lap for each driver. |
Tool | Description |
| List all events in a season. |
| List all drivers in a season, optionally filtered to a specific event. |
| Check server in-memory session cache status. |
| Clear cached sessions from in-memory storage. |
URI | Description |
| Full race calendar for a season |
| All drivers who competed in a season |
| All constructors in a season |
| All F1 circuits (all-time) |
Prompt | Args | What it does |
|
| Calls results + fastest laps + pit stops + stints, then narrates the race |
|
| Q breakdown + sector times + top laps analysis |
|
| Season-level head-to-head: standings, races, qualifying |
|
| Stints + pit timing + race pace — explains who won the strategy battle |
|
| Circuit details + recent history + championship context |
Who won the 2024 Monaco Grand Prix and what was the strategy?
→ use race_recap prompt or call get_session_results + get_stint_analysis
Compare Verstappen and Leclerc's telemetry in 2024 Monaco qualifying
→ compare_telemetry(2024, "Monaco", "Q", "VER", "LEC")
Who had the fastest theoretical lap in 2024 Silverstone qualifying?
→ get_sector_times(2024, "Silverstone", "Q")
Show me the 2024 constructor standings after round 10
→ get_constructor_standings(2024, after_round=10)# Install dev dependencies
uv sync --dev
# Run tests
uv run pytest
# Run tests with coverage
uv run pytest --cov=fastf1_mcp
# Lint
uv run ruff check src/Source | Coverage | Used for |
Ergast API (via FastF1) | 1950 – present | Standings, schedules, historical results, circuit info |
2018 – present | Lap times, telemetry, qualifying, pit stops, tire data |
Note: FastF1 session data is only available from 2018 onwards. Use
get_race_results_historicalfor earlier seasons.
MIT
Clear cached sessions from in-memory storage.
Args: year: Optional year filter — only clear sessions for this year event: Optional event filter — requires year to be set
Returns: {"cleared": 3, "remaining": 2}
Example: clear_cache() → {"cleared": 5, "remaining": 0} clear_cache(2024, "Monaco") → {"cleared": 1, "remaining": 4}
Note: Clears the in-memory LRU cache only. The FastF1 disk cache (raw timing files) is preserved and unaffected.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| event | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It fully discloses behavioral traits: clears only in-memory LRU cache, preserves disk cache, returns a JSON with cleared and remaining counts, and parameter constraints (event requires year).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, Example, and Note sections. Every sentence adds value, and the example clarifies expected usage. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and a complete input schema, the description provides all necessary context: clear action, parameter constraints, return format, and side effects (no effect on disk cache). The output schema exists but the description already explains return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates excellently. It explains each parameter's purpose ('year: Optional year filter', 'event: Optional event filter — requires year to be set') and provides example calls demonstrating usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Clear cached sessions from in-memory storage.' It uses a specific verb (clear) and resource (cached sessions), and the note about disk cache distinguishes it from sibling tools like get_cache_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly say when to use vs. alternatives, but it notes that the disk cache is preserved, which guides usage. It lacks explicit exclusion statements (e.g., 'use get_cache_status to view cache').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare telemetry between two drivers on the same session.
Data source: FastF1 Live Timing Coverage: 2018-present
Set export_path=True when the user wants the comparison data for
analysis (notebook, pandas, ML, "plot where one driver gains time",
"save the comparison"). Comparisons at the default 200 sample size
also auto-export.
Args:
year: Season year (2018+)
event: Race name or round number
session: Session type (R, Q, S, FP1, FP2, FP3)
driver1: First driver code (e.g., "VER")
driver2: Second driver code (e.g., "LEC")
lap: Lap number or "fastest" — applied independently to each driver
sample_size: Telemetry points per driver (default 200, max 500)
export_path: If True, write the per-distance comparison array to
a CSV in the configured export directory (default
./fastf1-exports/, override via FASTF1_MCP_EXPORT_DIR)
and omit comparison from the response. Pass a string
for a custom directory or .csv file path.
Returns: { "driver1": {"code": "VER", "lapNumber": 18, "lapTime": "1:10.123"}, "driver2": {"code": "LEC", "lapNumber": 20, "lapTime": "1:10.456"}, "comparison": [ {"distance": 0.0, "speed1": 280.0, "speed2": 275.0, "speedDelta": 5.0, "timeDelta": 0.0}, ... ], "summary": { "lapTimeDeltaSec": 0.333, "maxSpeedDelta": 8.2, "sectors": { "S1": {"driver1": "0:00:28.123", "driver2": "0:00:28.456", "deltaSec": -0.333}, "S2": {...}, "S3": {...} }, "driver1Telemetry": {"maxSpeedKph": 325.0, "brakingZones": 7, ...}, "driver2Telemetry": {"maxSpeedKph": 320.5, "brakingZones": 8, ...} } }
Example: compare_telemetry(2024, "Monaco", "Q", "VER", "LEC")
Note: timeDelta is the cumulative time gap at each distance point, computed from speed integration. Positive = driver1 is ahead. Comparison is aligned to driver1's distance axis.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| event | Yes | ||
| session | Yes | ||
| driver1 | Yes | ||
| driver2 | Yes | ||
| lap | No | fastest | |
| sample_size | No | ||
| export_path | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers data source, coverage, timeDelta calculation, alignment to driver1, and export behavior. Lacks discussion of error handling or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with intro, usage, parameter doc, returns, example, and note. Slightly verbose but appropriate for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, return structure, and includes example. Lacks error handling or data availability information, but sufficient for an experienced agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the Args section provides detailed meaning, defaults, and options for all 8 parameters, including the export_path's custom path feature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it compares telemetry between two drivers on the same session, specifies data source and coverage, and distinguishes from siblings like get_lap_telemetry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use export_path and mentions auto-export at default sample size. Could be improved by stating when NOT to use or comparing to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check server in-memory session cache status.
Returns: { "sessions_cached": 3, "max_sessions": 10, "cached_sessions": [ {"year": 2024, "event": "Monaco", "session": "R", "loaded_at": "2024-05-26T14:00:00"}, ... ], "fastf1_cache_path": "~/.fastf1_cache", "fastf1_cache_size_mb": 1234.5 }
Example: get_cache_status() → {"sessions_cached": 2, "max_sessions": 10, ...}
Note: Reports in-memory LRU cache only. The FastF1 disk cache (used for raw timing data) is reported separately as size_mb.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It fully discloses the return structure with an example, and notes the scope (in-memory only, disk cache reported separately). No side effects are mentioned, which is appropriate for a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is efficient, with clear first sentence. The example and note add value without being overly verbose. Could be slightly more concise, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema (inferred from the description example), the description is fully complete. It explains what is returned and the scope of the cache.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so baseline is 4. Description adds no param info, but none is needed. The return value example compensates for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with a specific verb-resource pair: 'Check server in-memory session cache status.' This clearly distinguishes it from sibling tools like clear_cache which likely mutates the cache. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description states it checks in-memory cache only, implicitly guiding when to use. However, it does not explicitly state when not to use (e.g., for raw timing data) or provide alternatives like clear_cache for clearing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get circuit information.
Data source: Ergast API (via FastF1)
Args: circuit_id: Ergast circuit ID (e.g., "monaco", "silverstone") If None, returns all circuits year: Filter to circuits used in this season
Returns: Circuit info: circuitId, circuitName, locality, country, lat, long
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | No | ||
| year | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the data source and return fields, but does not detail behavior like rate limits, error handling, or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, front-loaded with the purpose, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional parameters) and the presence of an output schema, the description adequately covers purpose, parameters, and return fields, though it lacks error information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides meaningful parameter details with examples (e.g., 'monaco', 'silverstone') and explains the effect of each parameter, compensating well for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get circuit information' and provides specific examples of circuit IDs, distinguishing it from sibling tools that focus on drivers, sessions, or other data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining parameters and data source, but lacks explicit guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get constructor championship standings.
Data source: Ergast API (via FastF1) Coverage: 1958-present (constructor championship started 1958)
Args: year: Season year after_round: Standings after specific round (default: latest)
Returns: Ordered list of constructors with: position, name, nationality, points, wins
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| after_round | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It mentions data source and historical coverage, which is helpful. However, it does not disclose behavioral traits such as error handling, read-only nature (though implied), or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections: main statement, data source, coverage, args, returns. Every sentence adds value, and there is no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (simple read operation) and the presence of an output schema (mentioned in description), the description adequately covers inputs and output format. Minor gap: no behavioral context like rate limits or error handling, but overall complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaningful context: 'year: Season year' and 'after_round: Standings after specific round (default: latest)'. This clarifies the purpose and default behavior beyond the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get constructor championship standings' with specific verb and resource. It distinguishes from sibling tools like get_driver_standings by focusing on constructors and provides coverage details (1958-present).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists arguments and explains 'after_round' with default behavior, but does not explicitly state when to use this tool versus alternatives or provide any when-not guidance. The context is implied by the tool name and sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get driver information.
Data source: Ergast API (via FastF1) Coverage: 1950-present
Args: driver_id: Ergast driver ID (e.g., "max_verstappen", "hamilton") If None, returns all drivers year: Filter to drivers who raced in this season
Returns: Driver info: driverId, code, givenName, familyName, dateOfBirth, nationality, permanentNumber
Note: Use get_session_results to find driver codes, then use this for biographical details.
| Name | Required | Description | Default |
|---|---|---|---|
| driver_id | No | ||
| year | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses data source (Ergast via FastF1) and coverage (1950-present) and return fields. Missing behavioral details like rate limits or error handling, but adequate given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with sections, bullet points, and a clear note. About 10 lines, no redundancy, but could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with 2 optional params and an output schema, the description covers data source, coverage, parameter semantics, return fields, and usage context. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds essential meaning: explains driver_id format with examples and behavior when None, and year filter purpose. This compensates well for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves driver biographical info, with specific verb 'Get' and resource 'driver information'. It distinguishes from siblings like 'get_session_results' (for codes) and 'list_drivers' (likely just names).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to use 'get_session_results' first to find driver codes, then this tool for bio details. Also explains parameters and default behavior, but lacks explicit when-not-to-use examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get driver championship standings.
Data source: Ergast API (via FastF1) Coverage: 1950-present
Args: year: Season year after_round: Standings after specific round (default: latest)
Returns: Ordered list of drivers with: position, driver code, full name, team, points, wins
Example: get_driver_standings(2024) → [ {"position": 1, "code": "VER", "name": "Max Verstappen", "team": "Red Bull", "points": 575, "wins": 19}, ... ]
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| after_round | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It reveals data source and coverage, but does not address error handling, data freshness, or potential side effects (though likely none). Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with headings for Args, Returns, and Example. No unnecessary words, every sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no nested objects) and presence of an output schema, the description covers purpose, parameters, and output adequately. Lacks some behavioral details but overall complete for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates with clear Args explanations ('year: Season year', 'after_round: Standings after specific round (default: latest)') and an example. Adds meaning beyond the schema's types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get driver championship standings', specifies the data source and coverage (1950-present), and distinguishes from sibling tools like 'get_constructor_standings' and 'get_driver_info' by focusing on standings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter details and an example, making it clear when to use (for driver standings). It lacks explicit when-not-to-use or alternatives, but the context with sibling tools allows inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get fastest laps in a session, one per driver.
Data source: FastF1 Live Timing Coverage: 2018-present
Args: year: Season year (2018+) event: Race name or round number session: Session type (default "R") top_n: Number of fastest laps to return (default 10)
Returns: Fastest laps sorted by time: lapNumber, lapTime, sector1, sector2, sector3, compound
Example: get_fastest_laps(2024, "Monaco", "R", 5) → [ {"lapNumber": 67, "lapTime": "0:01:15.456", "compound": "SOFT", ...}, ... ]
Note: Returns one fastest lap per driver. Only accurate laps are included.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| event | Yes | ||
| session | No | R | |
| top_n | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In absence of annotations, description fully discloses behavior: returns one fastest lap per driver, includes only accurate laps, sorted by time. Provides example with return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (Args, Returns, Example) and no fluff. Slightly long but each sentence earns its place. Example adds significant value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and sibling context, the description is complete: specifies data source, coverage, parameters, return format with example. Output schema exists further reduces burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description compensates fully by explaining each parameter (year, event, session, top_n) with defaults and an example, adding meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves fastest laps per driver in a session, differentiating it from siblings like get_lap_times (all laps) or get_session_results (full race results).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for fastest lap data with coverage details, but lacks explicit when-to-use or when-not-to-use compared to similar tools. However, the purpose is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get telemetry data for a specific lap.
Data source: FastF1 Live Timing Coverage: 2018-present
Set export_path=True when the user mentions data analysis, notebooks,
pandas, ML, "plot the telemetry", "save the trace", or downstream
processing — the sampled per-distance trace is written to CSV.
Telemetry responses with the default 200 sample points also auto-export
so the user always gets a real file path in the project.
Args:
year: Season year (2018+)
event: Race name or round number
session: Session type (R, Q, S, FP1, FP2, FP3)
driver: Driver code (e.g., "VER")
lap: Lap number or "fastest" (default)
sample_size: Number of telemetry points to return (default 200, max 500)
export_path: If True, write the sampled data array to a CSV in
the configured export directory (default
./fastf1-exports/, override via FASTF1_MCP_EXPORT_DIR)
and omit data from the response. Pass a string for a
custom directory or .csv file path. The server also
auto-exports when data would exceed
FASTF1_MCP_AUTO_EXPORT_ROWS rows (default 50). Use a
larger sample_size if you want more detail in the
exported file.
Returns: { "driver": "VER", "lapNumber": 42, "lapTime": "0:01:23.456", "summary": { "samplePoints": 200, "maxSpeedKph": 327.5, "minSpeedKph": 80.2, "avgSpeedKph": 218.1, "maxGear": 8, "brakingZones": 7, "fullThrottlePct": 64.5 }, "data": [ {"distance": 0.0, "speed": 280.0, "throttle": 95.0, "brake": false, "gear": 7, "drs": 0}, ... ] }
Example: get_lap_telemetry(2024, "Monaco", "Q", "VER") → fastest Q lap telemetry get_lap_telemetry(2024, "Monaco", "R", "VER", lap=45) → lap 45 telemetry
Note:
Raw telemetry has 5000+ points per lap. Response is sampled to
sample_size evenly-spaced distance points (capped at 500).
summary lets a caller answer top-speed / braking-zone questions
without parsing the full per-distance array.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| event | Yes | ||
| session | Yes | ||
| driver | Yes | ||
| lap | No | fastest | |
| sample_size | No | ||
| export_path | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses data source, coverage, sampling behavior, export side effects, and response structure changes. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, data source, Args, Returns, Example, Note). Slightly verbose in some sentences but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers the tool's behavior including sampling, export, summary, and response format. Comprehensive given complexity, 7 parameters, and output schema present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description's Args section explains each parameter, including defaults, types, and usage examples, adding significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get telemetry data for a specific lap' with specific verb and resource. Distinguishes from siblings like compare_telemetry and get_fastest_laps by focusing on single lap telemetry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use export_path (data analysis, plotting, etc.) and mentions auto-export thresholds. Could more directly compare with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all lap times for a driver in a session.
Data source: FastF1 Live Timing Coverage: 2018-present
Set export_path=True when the user mentions data analysis, notebooks,
pandas, ML, "save as CSV", "export the data", or any downstream
processing — the full per-lap array is then written to a CSV file the
user can open directly. Large responses (>50 laps) also auto-export so
the user always gets a real file path in the project rather than the
MCP client silently spilling the response to a temp file.
Args:
year: Season year (2018+)
event: Race name or round number
session: Session type (R, Q, S, FP1, FP2, FP3)
driver: Driver code (e.g., "VER") or number (e.g., "1")
include_deleted: Include deleted lap times (default False)
export_path: If True, write the full per-lap array to a CSV in the
configured export directory (default ./fastf1-exports/,
override via FASTF1_MCP_EXPORT_DIR) and omit laps from
the response. Pass a string for a custom directory or
.csv file path. The server also auto-exports when
the lap count exceeds FASTF1_MCP_AUTO_EXPORT_ROWS
(default 50).
Returns: Default (no export): { "driver": "VER", "fullName": "Max Verstappen", "teamName": "Red Bull Racing", "summary": {...}, "laps": [{"lapNumber": 1, "lapTime": "0:01:30.456", ...}, ...] }
With export_path:
{
"driver": "VER", "fullName": ..., "teamName": ...,
"summary": {...},
"exportPath": "/abs/path/to/get_lap_times_2024_monaco_r_ver_<ts>.csv",
"rowCount": 52
}Note:
Deleted laps (e.g., track limits violations) are excluded by default.
Set include_deleted=True to include them.
summary lets a caller answer fastest/avg/compound questions without
re-parsing the full per-lap array. Use export_path=True to grab the
full dataset as CSV for downstream analysis / ML work.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| event | Yes | ||
| session | Yes | ||
| driver | Yes | ||
| include_deleted | No | ||
| export_path | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses data source (FastF1 Live Timing), coverage (2018-present), auto-export behavior, and the dual response format (with/without export). It explains that deleted laps are excluded by default and that summary provides aggregated info to avoid parsing the full array.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (data source, coverage, usage hint, Args, Returns, Note). It is front-loaded with the core purpose and each sentence earns its place. Despite length, it remains focused and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters, no annotations, and a detailed output schema documented inline, the description covers all necessary aspects: parameter explanations, behavior, return format, and edge cases (deleted laps, auto-export). It is fully complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully explain parameters. It does so for all six parameters: year, event, session, driver, include_deleted, and export_path. It provides types, defaults, and special behavior (e.g., export_path accepts custom directory or file path, auto-export threshold). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it retrieves all lap times for a driver in a session, specifying the verb (get), resource (lap times), and scope (per driver per session). It clearly distinguishes from sibling tools like get_fastest_laps (which gets only fastest laps) and get_sector_times (sector-level data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: when to set export_path (e.g., data analysis, ML, save as CSV) and mentions auto-export for >50 laps. It also advises setting include_deleted to include deleted laps. While it does not explicitly contrast with siblings, the purpose is distinct enough that no further exclusions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all pit stops from a race.
Data source: FastF1 Live Timing Coverage: 2018-present
Args: year: Season year (2018+) event: Race name or round number
Returns: Pit stops sorted by lap: driver (code), fullName, teamName, lap, stopNumber, duration, tyreFrom, tyreTo
Example: get_pit_stops(2024, "Monaco") → [ {"driver": "LEC", "fullName": "Charles Leclerc", "teamName": "Ferrari", "lap": 28, "stopNumber": 1, "duration": 23.4, "tyreFrom": "MEDIUM", "tyreTo": "HARD"}, ... ]
Note: Duration is calculated from PitInTime (end of in-lap) to PitOutTime (start of out-lap), in seconds. Stops with implausibly long durations (>120s) are filtered as FastF1 data artifacts — commonly a phantom lap-1 entry tied to session start, not a real pit stop.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| event | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses data source (FastF1 Live Timing), coverage (2018-present), duration calculation method, and filtering of implausible stops (>120s) as artifacts. This provides good behavioral context despite no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for args, returns, and a note about filtering. It is concise but includes necessary details; could be slightly shorter but no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description provides comprehensive context: data source, coverage, parameter semantics, return field listing, example, and important behavioral notes about duration and filtering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully by clearly explaining both parameters: year (2018+) and event (race name or round number). The example demonstrates usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get all pit stops from a race' and specifies data source and coverage. It clearly differentiates from siblings like get_lap_times and get_fastest_laps which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving pit stop data with required year and event parameters, but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get qualifying results split by Q1/Q2/Q3.
Data source: FastF1 Live Timing Coverage: 2018-present
Args: year: Season year (2018+) event: Race name or round number
Returns: { "Q1": [{"driver": "VER", "bestTime": "1:10.123", "lapNumber": 3}, ...], "Q2": [...], "Q3": [...], "eliminated_Q1": ["driver1", "driver2", ...], "eliminated_Q2": ["driver3", "driver4", ...] }
Example: get_qualifying_breakdown(2024, "Monaco") → { "Q1": [...20 drivers sorted by best time...], "Q2": [...15 drivers...], "Q3": [...10 drivers...], "eliminated_Q1": ["5 driver codes"], "eliminated_Q2": ["5 driver codes"] }
Note: Uses laps.split_qualifying_sessions() to split by session time. Drivers with no recorded lap time in a segment are omitted from that segment's list.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| event | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses internal behavior ('Uses laps.split_qualifying_sessions()'), a key rule ('Drivers with no recorded lap time... are omitted'), and the return structure. However, it does not cover error behavior, rate limits, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (header, data source, args, returns, example, note). It is concise, front-loading purpose, and each sentence provides necessary detail without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema structured but described in text), the description covers inputs, outputs, behavior, and a practical example. It is fully adequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), but the description's Args section adds meaning: 'year: Season year (2018+)' and 'event: Race name or round number', clarifying types and constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description immediately states 'Get qualifying results split by Q1/Q2/Q3', specifying the verb 'get', the resource 'qualifying breakdown', and the key aspect of splitting by sessions. This clearly distinguishes it from siblings like get_session_results (which returns overall session results) and get_lap_times (which returns lap times without qualifying-specific breakdown).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about data source (FastF1 Live Timing) and coverage (2018-present), but does not explicitly state when to use this tool versus alternatives. It does not mention when not to use it or provide comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate average race pace for all drivers.
Data source: FastF1 Live Timing Coverage: 2018-present
Args: year: Season year (2018+) event: Race name or round number exclude_first_laps: Number of opening laps to exclude (default 2) exclude_sc_laps: Exclude laps behind safety car or VSC (default True) exclude_pit_laps: Exclude in-laps and out-laps (default True) min_laps: Minimum valid laps required to include a driver (default 10)
Returns: { "filters": { "excludeFirstLaps": 2, "excludeSafetyCarLaps": true, "excludePitLaps": true, "minLaps": 10 }, "drivers": [ {"driver": "LEC", "fullName": "Charles Leclerc", "teamName": "Ferrari", "avgLapTime": "0:01:15.678", "lapCount": 52, "deltaToFastestSec": 0.0, ...}, ... ] }
Note:
SC/VSC filter uses track status "1" (green flag only).
Drivers with fewer than min_laps valid laps are excluded.
The filters block echoes the applied filters so the caller can
clearly state which conditions the pace was computed under.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| event | Yes | ||
| exclude_first_laps | No | ||
| exclude_sc_laps | No | ||
| exclude_pit_laps | No | ||
| min_laps | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses data source, coverage, and filter behavior (e.g., SC/VSC using track status '1', driver exclusion). It adds value beyond the bare parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with purpose, but the Args section repeats defaults already in the schema. Still, every sentence adds value, and it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, various filters) and lack of output schema, the description covers purpose, parameters, output structure, and behavioral notes comprehensively. The Returns block compensates for the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description includes an Args section that explains each parameter with defaults and meaning, fully compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Calculate average race pace for all drivers,' specifying the verb, resource, and scope. It distinguishes from siblings like get_lap_times or get_fastest_laps by focusing on average pace and listing unique filtering options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context through the Note and Returns block, but lacks explicit guidance on when to use this tool versus alternatives (e.g., get_lap_times, get_stint_analysis).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical race results (pre-2018 or when session data unavailable).
Data source: Ergast API (via FastF1) Coverage: 1950-present
Args: year: Season year round_num: Round number
Returns: Results with: position, driver, constructor, grid, laps, status, time (if finished), fastestLapTime, fastestLapRank
Note: For 2018+ races, prefer get_session_results which has more detail.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| round_num | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While no annotations exist, the description discloses the data source (Ergast API via FastF1), coverage (1950-present), and return fields. It lacks details on rate limits or latency but adequately covers read behavior for a historical data tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the key purpose, and uses a clear structure with bullet points for parameters and returns. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. It covers purpose, usage guidance, data source, and return field list, making it complete for an agent to understand and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate, but it merely lists parameter names (year, round_num) without adding semantics like valid ranges, formats, or constraints. This adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving historical race results (pre-2018 or when session data unavailable), distinguishes it from the sibling get_session_results, and specifies the data source and coverage period.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (pre-2018 races) and directs to the preferred alternative (get_session_results for 2018+), providing clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the F1 race calendar for a season.
Data source: Ergast API (via FastF1) Coverage: 1950-present
Args: year: Season year (1950-present)
Returns: List of events with: round, raceName, circuitName, country, date, time (if available)
Example: get_schedule(2024) → [ {"round": 1, "raceName": "Bahrain Grand Prix", ...}, ... ]
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description mentions the data source and historical coverage, but does not disclose potential side effects, auth requirements, or rate limits. It is partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (purpose, data source, args, returns, example) and is concise, though the example could be shorter. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides sufficient context including return format and an example. It covers the main aspects needed to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, but the description adds meaning by stating the parameter 'year' refers to the season year and constraining it to 1950-present, which goes beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets 'the F1 race calendar for a season', specifying both the action (get) and resource (schedule). It distinguishes from sibling tools like get_circuit_info or get_driver_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives, nor does it mention when not to use it or any prerequisites. It simply describes the tool's function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get best sector times and theoretical best lap for each driver.
Data source: FastF1 Live Timing Coverage: 2018-present
Set include_laps=True when the user wants per-lap sector breakdowns
(e.g. "show me Antonelli's sector times each lap") rather than just
the per-driver best/theoretical-best summary.
Args:
year: Season year (2018+)
event: Race name or round number
session: Session type (R, Q, S, FP1, FP2, FP3)
driver: Optional driver code to filter (default: all drivers)
include_laps: If True, include a laps array per driver with each
accurate lap's S1/S2/S3 and total lap time. Default
False keeps responses compact for the typical
"fastest sectors / theoretical best" question.
Returns:
For each driver: driver (code), fullName, teamName, bestS1, bestS2,
bestS3, theoreticalBest, actualBest, gapSec. With include_laps,
each entry also has laps: [{lapNumber, s1, s2, s3, lapTime}, ...].
Example: get_sector_times(2024, "Monaco", "Q") → [ {"driver": "VER", "fullName": "Max Verstappen", "teamName": "Red Bull Racing", "bestS1": "0:00:22.123", "bestS2": "0:00:24.456", "bestS3": "0:00:21.789", "theoreticalBest": "0:01:08.368", "actualBest": "0:01:08.570", "gapSec": -0.202}, ... ]
Note: A negative gapSec means the theoretical best (sum of individual sector bests) is faster than the actual best lap — typical, since sector bests usually come from different laps.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| event | Yes | ||
| session | Yes | ||
| driver | No | ||
| include_laps | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses data source (FastF1 Live Timing), coverage range (2018-present), and explains the meaning of negative gapSec. It does not mention error handling, rate limits, or destructive behavior (appropriate as it is read-only).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but well-structured with sections for data source, parameters, return, example, and note. It is front-loaded with the main purpose. One could argue slight conciseness improvements, but it effectively uses its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and an implicitly declared output schema, the description covers all necessary aspects: purpose, parameter usage (with defaults), return format (with example), and a note on gapSec. It is fully complete for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully explain parameters. It does so: year (2018+), event (name/round), session (with examples), driver (optional, default all), include_laps (default false, effect explained). This adds crucial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get best sector times and theoretical best lap for each driver,' which is a specific verb+resource. It distinguishes from sibling tools like get_lap_times by mentioning per-lap sector breakdowns via include_laps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when to set include_laps=True, providing an example query. However, it does not explicitly contrast this tool with alternatives like get_fastest_laps or get_lap_times, leaving some ambiguity about optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get session classification/results.
Data source: FastF1 Live Timing Coverage: 2018-present
Args: year: Season year (2018+) event: Race name (e.g., "Monaco") or round number session: Session type — R, Q, S, SQ, FP1, FP2, FP3
Returns: Ordered classification with: position, driverCode, fullName, teamName, gridPosition, time/status, points
Example: get_session_results(2024, "Monaco", "R") → [ {"position": 1, "driverCode": "LEC", "fullName": "Charles Leclerc", "teamName": "Ferrari", "time": "1:45:12.345", ...}, ... ]
Note: Requires year >= 2018. For historical results use get_race_results_historical.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| event | Yes | ||
| session | No | R |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It discloses data source, coverage, and output format but does not explicitly state read-only nature, rate limits, or potential side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (Args, Returns, Example, Note) and front-loaded purpose. Slightly lengthy but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, description provides example output and covers all parameters, data source, and usage constraints. References alternative tool, making it self-contained and complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description fully explains each parameter: year (2018+), event (name/number), session (type abbreviations). Adds substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get session classification/results', specifies the domain (F1), data source, and coverage. It differentiates from sibling 'get_race_results_historical' by recommending it for historical queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes the year constraint (2018+) and directs to an alternative for historical results. However, it does not elaborate on when to use this tool versus other session-specific tools like get_qualifying_breakdown or get_lap_times, though the session parameter clarifies scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get speed trap and top-speed data for all drivers in a session.
Data source: FastF1 Live Timing (session results) Coverage: 2018-present
Args: year: Season year (2018+) event: Race name or round number session: Session type (R, Q, S, FP1, FP2, FP3)
Returns: { "source": "results" | "laps", "drivers": [ {"driver": "VER", "fullName": "Max Verstappen", "teamName": "Red Bull Racing", "speedTrap": 298.5, "speedFL": 187.2, "speedI1": 245.0, "speedI2": 268.5}, ... ] }
Example: get_speed_trap_data(2024, "Monza", "Q") → {"source": "results", ...}
Note: SpeedST = official speed trap measurement. SpeedFL = speed at the finish line. SpeedI1/I2 = sector intermediate speed measurements. Values are in km/h.
FastF1 publishes per-driver speed columns on `session.results`, but
for many sessions those columns are entirely empty. When the
results-level data is missing, we fall back to the per-lap max
across `session.laps` for the same columns. `source` indicates
which path produced the response.| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| event | Yes | ||
| session | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It thoroughly discloses data sources, coverage, fallback logic (from results to laps when columns are empty), and defines all returned fields. This is highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections: intro, data source, args list, returns with JSON example, and a note. Every sentence adds value; no fluff or redundancy. Length is appropriate for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (JSON example effectively serves that role) and detailed behavioral notes, the description covers all necessary aspects: what it does, parameters, return structure, data sources, and edge cases (fallback). No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema describes parameters but none have descriptions (0% coverage). The description compensates by listing each parameter with context: year (2018+), event (race name or round number), session (R, Q, etc.). An example is provided, but additional guidance on valid string formats for event would improve clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get speed trap and top-speed data for all drivers in a session', which is a specific verb+resource combination. It distinguishes itself from sibling tools like get_lap_times or get_sector_times by focusing on speed trap and top-speed data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about data source (FastF1 Live Timing), coverage (2018-present), and includes an example call. It does not explicitly state when to use or when not to use, but the detail is sufficient for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze tire stints for a race.
Data source: FastF1 Live Timing Coverage: 2018-present
Set export_path=True when the user mentions data analysis, notebooks,
pandas, ML, "save as CSV", "export the strategy data", or any downstream
processing — the full per-stint array is written to CSV. Large
responses (>50 stints, typical for full-grid races) also auto-export.
Args:
year: Season year (2018+)
event: Race name or round number
driver: Optional driver code to filter (default: all drivers)
export_path: If True, write the full per-stint array to a CSV in
the configured export directory (default
./fastf1-exports/, override via FASTF1_MCP_EXPORT_DIR)
and omit stints from the response. Pass a string for
a custom directory or .csv file path. The server
also auto-exports when the stint count exceeds
FASTF1_MCP_AUTO_EXPORT_ROWS (default 50).
Returns: Default (no export): { "summary": {...}, "stints": [{"driver": "LEC", "stintNumber": 1, ...}, ...] }
With export_path:
{
"summary": {...},
"exportPath": "/abs/path/to/get_stint_analysis_<...>.csv",
"rowCount": 45
}Note:
Only accurate laps are included in pace calculations.
Stint numbers match FastF1's internal stint counter.
Phantom lap-1 stints (single-lap entries with no recorded lap time,
paired with the lap-1 pit-stop artifact) are filtered out.
The summary.strategies array gives the 1-stop / 2-stop / compound
sequence per driver in a compact form.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| event | Yes | ||
| driver | No | ||
| export_path | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses data source, coverage, auto-export behavior, phantom stint filtering, and accurate lap inclusion. It explains the side effects of export_path and directory configuration, leaving no ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (purpose, data source, params, returns, notes) and front-loaded with key info. While thorough, it is slightly verbose but still concise for the detail provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and an output schema (partially described), the description covers all necessary aspects: parameters, return structure, edge cases (auto-export, phantom laps), and usage context. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description richly documents each parameter: year range, event flexibility, driver default, and export_path's boolean/string variants with detailed behavior. It adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Analyze tire stints for a race,' using a specific verb and resource. It distinguishes this tool from siblings like get_race_pace and get_lap_times by focusing on stint-level analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to set export_path, including user intents like data analysis or large responses. However, it does not explicitly state when to prefer this tool over alternatives, though the purpose clarity implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all drivers in a season, optionally filtered to a specific event.
Data source: Ergast API (season list) or FastF1 session (event filter) Coverage: 1950-present (season); 2018-present (event filter)
Args: year: Season year event: Optional race name or round number to filter by event (returns only drivers who participated in that session)
Returns: Drivers with: code, fullName, nationality, team, number
Example: list_drivers(2024) → [ {"code": "VER", "fullName": "Max Verstappen", "nationality": "Dutch", "team": "Red Bull Racing", "number": "1"}, ... ]
Note: When event is provided, data comes from FastF1 session results (requires year >= 2018). Without event, uses Ergast season data.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| event | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses data sources (Ergast API vs FastF1), coverage years, return fields, and the note about event requiring year>=2018. This is transparent about behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with sections (Args, Returns, Example, Note) and each part adds value. It is somewhat verbose but not wasteful; all sentences contribute to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, output schema, and sibling tools, the description is comprehensive. It covers purpose, parameters, return format, example, data sources, and limitation about event filter, leaving no obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description fully explains year as season year and event as optional race name or round number. Example shows usage and output, making semantics clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all drivers in a season, optionally filtered by event, which is a specific verb+resource. It distinguishes from sibling tools like get_driver_info and get_session_results by focusing on driver listing rather than detailed info or session results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides when to use with/without event, and mentions data source limitations (1950-present for season, 2018-present for event filter). It does not explicitly list alternatives, but the context of sibling tools and the note about faster response without event gives implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all events in a season.
Data source: Ergast API (via FastF1) Coverage: 1950-present
Args: year: Season year (1950-present)
Returns: Events with: round, eventName, country, circuitName, date
Example: list_events(2024) → [ {"round": 1, "eventName": "Bahrain Grand Prix", "country": "Bahrain", "circuitName": "Bahrain International Circuit", "date": "2024-03-02"}, ... ]
Note: Minimal version of get_schedule — useful for discovering valid event names to pass to other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions the data source and coverage, but does not explicitly state that the tool is read-only or any potential side effects. The example helps, but more transparency (e.g., idempotency, auth requirements) would improve the score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, uses clear sections (Args, Returns, Example, Note), and every sentence adds value. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, list output), the description covers the purpose, input, output, example, and relationship to sibling. It lacks only minor details like error handling or performance, but is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for the 'year' parameter. The tool description adds 'Season year (1950-present)' providing clear meaning and range. With only one parameter and full coverage via description, it adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all events in a season' with a specific verb and resource. It also explicitly distinguishes itself from the sibling 'get_schedule' by calling itself a 'minimal version', providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the tool is 'useful for discovering valid event names to pass to other tools' and specifies the data source and coverage. It implicitly advises using 'get_schedule' for more detail, but does not explicitly list when not to use this tool. Overall clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes targeting specific data types or analyses (e.g., get_lap_telemetry vs get_sector_times vs get_pit_stops). However, some overlap exists between get_schedule and list_events (both provide calendar information) and between get_session_results and get_race_results_historical (both provide race results), which could cause minor confusion.
Tool names follow a consistent verb_noun pattern throughout (e.g., get_driver_standings, compare_telemetry, clear_cache). All tools use snake_case with clear, descriptive names, making them predictable and easy to understand.
With 21 tools, the count feels heavy for a single-domain server, though Formula 1 data is rich. Some tools could potentially be consolidated (e.g., get_schedule and list_events), but the breadth of coverage justifies many tools. It's borderline but manageable.
The toolset provides comprehensive coverage for Formula 1 data analysis, including historical data (via Ergast API), detailed session data (via FastF1 Live Timing), telemetry, standings, schedules, and caching utilities. There are no obvious gaps for core workflows, and tools support both high-level and granular analyses.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Anonymous read-only Formula 1 tools, resources, prompts, completion, and interactive dashboard.
Read-only F1 game laps, telemetry, setups, leaderboard benchmarks, and progress.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Surya96t/fastf1-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
