Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fastf1-mcp Who won the 2024 Monaco Grand Prix?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A local MCP server that gives Claude (or any MCP-compatible AI client) access to Formula 1 race data. Load any session from 2018 onwards, ask questions in natural language, and get answers backed by real telemetry, timing, and strategy data.
No hosted API. No credentials for data. Everything runs locally on your machine.
pip install fastf1-mcpRelated MCP server: Formula One MCP Server
Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"f1": {
"command": "fastf1-mcp"
}
}
}Restart Claude Desktop. Then ask:
claude mcp add f1 fastf1-mcpThen in any Claude Code session, ask:
"Load the 2024 Monaco qualifying and tell me who got pole"
"Compare Verstappen and Leclerc's race pace at Silverstone"
"What was Hamilton's pit strategy at Monza?"
The MCP server exposes 17 tools that Claude can call to fetch specific F1 data:
Tool | What It Answers |
| Load a race, qualifying, or practice session |
| "What races are in 2024?" |
| "Who won?", "What was the podium?" |
| "Who got pole?", "Q3 times?" |
| "How consistent was Leclerc?" |
| "Who set the fastest lap?" |
| "When did everyone pit?" |
| "What compounds did they use?" |
| "What was Verstappen's top speed?" |
| "Compare Norris vs Piastri" |
| "Was it wet?" |
| "Give me an overview of the race" |
| "Did the track get faster?" |
| "Who gained the most positions?" |
| "Who is car 44?" |
| "Who was in this session?" |
| "What session is loaded?" |
You don't need to know exact driver codes or race names. The server resolves natural language:
You Say | Resolves To |
"Leclerc", "charles", "LEC", "16" | Charles Leclerc (LEC) |
"checo", "Perez", "11" | Sergio Perez (PER) |
"spa" | Belgian Grand Prix |
"monza" | Italian Grand Prix |
"silverstone" | British Grand Prix |
"qualifying", "quali", "Q" | Qualifying session |
You ask Claude: "Who won the 2024 Bahrain race?"
│
▼
Claude picks tool: load_session(year=2024, race="Bahrain", session="race")
│
▼
fastf1-mcp loads data via FastF1 (cached locally after first download)
│
▼
Claude picks tool: race_result()
│
▼
fastf1-mcp returns structured JSON with the classification
│
▼
Claude answers: "Verstappen won from Perez and Sainz..."First load of a session downloads from F1 servers (~10-30 seconds)
Every load after is instant (cached at ~/.cache/f1_mcp/)
No API keys needed for F1 data — it's public timing data via FastF1
Claude only sees small JSON tool results, not raw telemetry dumps
Seasons: 2018 onwards (FastF1 limitation)
Sessions: Race, Qualifying, Sprint, Practice (FP1/FP2/FP3)
Data: Results, lap times, pit stops, tyre stints, telemetry (speed/throttle/brake), weather, circuit info
pip install fastf1-mcp[test]
# Unit tests (no network, instant)
pytest tests/ -m "not integration" -v
# Full suite (downloads F1 data on first run, cached after)
pytest tests/ -v133 tests covering normalization, session management, tool execution, and MCP protocol (stdio JSON-RPC handshake, tool listing, tool calls).
You can also import the package directly without MCP:
from f1_mcp.session import SessionManager
mgr = SessionManager()
mgr.load(2024, "Monaco", "qualifying")
print(mgr.qualifying_result())
print(mgr.lap_times("Leclerc"))
print(mgr.head_to_head("Verstappen", "Norris"))MIT
Get summarized telemetry stats for a driver's lap.
Returns top speed, average speed, throttle application percentage, braking intensity, and other derived metrics. Defaults to the driver's fastest lap if no lap number is specified.
Use this when the user asks about speed, braking, throttle traces, or driving style analysis.
Args: driver: Driver name, code, or number (e.g. "Verstappen", "VER", "1") lap_number: Specific lap number, or -1 for the driver's fastest lap (default: -1)
| Name | Required | Description | Default |
|---|---|---|---|
| driver | Yes | ||
| lap_number | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits like read-only nature, authorization needs, or rate limits. While it explains output and default, safety implications are absent.
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?
Concise and well-structured: single-sentence summary, then bullet-like details, usage guidance, and parameter descriptions. No fluff.
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 inputs and output nature well. With output schema present, missing explicit output list is acceptable. However, does not mention session context requirement (assumes a session is loaded), slightly incomplete.
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 coverage, description adds meaning: driver can be name/code/number, lap_number defaults to -1 (fastest lap). This clarifies usage beyond schema's type/default.
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 returns summarized telemetry stats for a driver's lap, listing examples like top speed and average speed. Distinguishes from siblings as the only telemetry-focused tool.
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 says to use when user asks about speed, braking, throttle, or driving style analysis. Also explains default behavior (fastest lap if no lap number). Provides clear context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the fastest lap set by each driver, ranked.
Use this when the user asks about fastest laps, who set the quickest time, or lap time comparisons across the field.
Args: top_n: Number of drivers to include (default 10)
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | 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 full burden. It only states the retrieval function and does not disclose any behavioral traits such as read-only nature, data freshness, 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?
Description is very concise with three parts: purpose, usage guidance, and parameter explanation. Every sentence adds value, and key info is front-loaded.
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 one parameter and an output schema, the description covers the main purpose and usage. However, it lacks behavioral context (e.g., read-only, rate limits) which reduces completeness.
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 coverage is 0%, but description adds meaning by explaining 'top_n: Number of drivers to include (default 10)'. This clarifies the parameter's purpose beyond the schema's default value.
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 retrieves the fastest lap set by each driver, ranked. This distinguishes it from siblings like 'lap_times' which likely provide more general lap 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?
Explicitly tells when to use: when user asks about fastest laps, quickest times, or lap time comparisons. Does not mention when not to use or alternatives, but guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two drivers across all key metrics.
Use this when the user asks to compare drivers, wants a head-to-head analysis, or asks who was better between two specific drivers.
Args: driver_a: First driver — name, code, or number driver_b: Second driver — name, code, or number
| Name | Required | Description | Default |
|---|---|---|---|
| driver_a | Yes | ||
| driver_b | 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 carry the burden. It doesn't disclose any behavioral traits like mutability, required permissions, or data scoping. It does mention 'all key metrics' but doesn't specify what those are. However, an output schema exists, which likely details the return structure, so the lack of behavioral detail is somewhat mitigated.
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 extremely concise: two sentences for purpose/usage and a brief argument list. Every sentence adds value, and there is no verbose or redundant text.
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 has only two simple parameters and an output schema exists, the description provides enough context for an AI agent to understand when and how to use it. However, it could be slightly more complete by listing the key metrics it compares, but that may be detailed in the 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 input schema only defines parameters as type string. The description adds important semantics: 'name, code, or number' for each driver, clarifying acceptable formats. With 0% schema description coverage, the description fully compensates by explaining what values are valid.
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 purpose: 'Compare two drivers across all key metrics.' It uses a specific verb (compare) and resource (drivers), and distinguishes itself from sibling tools like driver_telemetry or fastest_laps that focus on individual drivers or specific metrics.
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 tells when to use the tool: 'when the user asks to compare drivers, wants a head-to-head analysis, or asks who was better between two specific drivers.' It doesn't provide when-not-to-use or alternatives, but the context from sibling tools implies other tools for single-driver queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a driver name, nickname, or number to their full identity.
Use this when the user refers to a driver ambiguously and you need to confirm who they mean. Handles nicknames ("Checo"), first names ("Charles"), car numbers ("44"), and partial matches ("lec").
Args: name: Any driver reference — name, nickname, abbreviation, or car number
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions handling various formats but omits behavior on no match or multiple matches.
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?
Short, front-loaded, and well-structured. Every sentence adds value with no 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 a simple tool with one parameter and an output schema, the description is nearly complete. Minor gap: no mention of error handling.
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 single parameter 'name' is described in detail with examples (name, nickname, abbreviation, car number), compensating for zero schema description coverage.
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 verb 'resolve' and the resource 'driver identity', distinguishing it from sibling tools like list_drivers.
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 says to use when user refers to a driver ambiguously, and lists input types. No exclusions or alternatives, but clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get lap-by-lap timing data for a specific driver.
Use this when the user asks about a driver's pace, consistency, lap time progression, or when they were fast/slow. Includes tyre compound and stint info per lap.
Driver names are fuzzy-matched: "Leclerc", "charles", "LEC" all work.
Args: driver: Driver name, code, or number (e.g. "Leclerc", "LEC", "16")
| Name | Required | Description | Default |
|---|---|---|---|
| driver | Yes |
| 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 fuzzy matching for driver names and mentions included data (tyre compound, stint info). However, it does not describe output format, session dependency, or any potential side effects, leaving some behavioral gaps.
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 a purpose statement, usage guidance, and parameter details. It is concise but could potentially be tightened by removing redundancy in the parameter examples. Still, it's informative without excessive 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 the single parameter and presence of an output schema, the description covers the tool's purpose, usage context, and parameter semantics adequately. It could mention that a session must be loaded (implied by context signals and sibling tools), but overall it is sufficient.
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 a single string parameter with no description (0% coverage). The description adds significant value by explaining that 'driver' accepts names, codes, or numbers, and that fuzzy matching applies. This is essential for correct 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 explicitly states 'Get lap-by-lap timing data for a specific driver', clearly identifying the verb and resource. It distinguishes from sibling tools like fastest_laps (which aggregates) and tire_stints (which focuses on tire 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?
Provides clear guidance on when to use: 'when the user asks about a driver's pace, consistency, lap time progression, or when they were fast/slow.' It does not explicitly state when not to use or mention alternatives, but the context is clear.
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 the current session with codes, names, and teams.
Use this when the user asks who was in the session, or when you need to find a driver's 3-letter code.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description implies reliance on current session but does not disclose prerequisites (e.g., session must be loaded) or any other behavioral traits. Adequate but could add more context.
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?
Two concise sentences with no redundant information. 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?
Tool has output schema, so return format is covered. Description includes purpose and usage context. Could mention session dependency for completeness.
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?
No parameters exist, so schema coverage is 100%. The description adds no parameter-level detail but that is acceptable as none are needed. Baseline for 0 parameters is 4.
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 lists all drivers in the current session and specifies the fields returned (codes, names, teams). It effectively distinguishes from sibling tools like driver_telemetry or lap_times.
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: when the user asks who was in the session or needs a driver's 3-letter code. However, it does not mention when not to use or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load an F1 session for analysis. Must be called before other tools.
Use this when the user mentions a specific race, GP, or session they want to analyze. Race and session names are fuzzy-matched:
Race: "Bahrain", "Monza", "silverstone", "Monaco GP" all work
Session: "race", "qualifying", "quali", "FP1", "sprint" all work
Args: year: Season year (e.g. 2024) race: Grand Prix name — fuzzy matched (e.g. "Bahrain", "Monza", "silverstone") session: Session type — fuzzy matched (default "race"). Options: race, qualifying, sprint, FP1, FP2, FP3
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| race | Yes | ||
| session | No | race |
| 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 the full burden. It discloses the prerequisite behavior ('Must be called before other tools') and the fuzzy matching behavior for race and session names. It does not describe side effects, idempotency, or data loading details, but for a loading tool, this is adequate.
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 and well-structured with an introduction, usage guidance, and an Args section. Every sentence serves a purpose, and the format makes it 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 complexity (3 parameters, a prerequisite, and an output schema), the description covers all essential aspects: when to use, parameter details, fuzzy matching, and the prerequisite. The output schema exists, so no need to explain 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?
The input schema has 0% description coverage, so the description must compensate. It does so thoroughly by explaining each parameter: year (e.g., 2024), race (fuzzy matched, examples given), and session (default 'race', fuzzy matched, options enumerated). This adds significant meaning beyond the schema property titles.
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 that the tool loads an F1 session for analysis and must be called before other tools. It specifies the verb 'load' and the resource 'F1 session', and the context differentiates it from sibling tools which operate on an already-loaded session.
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 says 'Use this when the user mentions a specific race, GP, or session they want to analyze.' It provides examples of fuzzy matching, which helps the agent map user input to parameters. However, it does not mention when not to use it or provide comparisons to sibling tools like 'season_calendar' or 'race_result', which could be used for information without loading a session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get position changes and pace comparisons between consecutive drivers.
Use this when the user asks about overtakes, who was faster than the car ahead, position gains/losses, or race dynamics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 disclose behavior. It describes what is returned (position changes, pace comparisons) and implies it is a read operation, but does not explicitly state non-destructiveness or any limitations. Given it is a simple retrieval tool, the transparency is adequate but could be slightly more explicit.
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 two sentences, with the first stating the core purpose and the second providing usage scenarios. It is front-loaded and contains no extraneous words, making it highly 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?
Given the tool has no parameters and an output schema (though not shown), the description covers the main return types and use cases. It could mention session scoping or data freshness, but for a straightforward retrieval tool it is sufficiently complete.
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 parameters and schema coverage is 100%. With zero parameters, the description need not add parameter info. The baseline score of 4 is appropriate as no additional meaning is required.
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 retrieves position changes and pace comparisons between consecutive drivers, using a specific verb (Get) and resource (overtakes). It distinguishes itself from siblings like driver_telemetry or head_to_head by focusing on overtakes.
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 tells when to use the tool: when the user asks about overtakes, faster-than-ahead cars, position gains/losses, or race dynamics. This provides clear context and covers multiple relevant scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get pit stop details — when each driver pitted and on which tyre.
Use this when the user asks about pit strategy, when someone pitted, how many stops a driver made, or undercut/overcut timing.
Args: driver: Driver name/code, or "all" for every driver (default: all)
| Name | Required | Description | Default |
|---|---|---|---|
| driver | No | all |
| 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 the full burden. It does not explicitly state that the operation is read-only or non-destructive, nor does it address potential errors or limitations. However, the absence of such information is not critical for a simple retrieval tool, and the description does not contradict annotations (none exist).
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 two sentences plus an Args list, with no unnecessary words. The key information is front-loaded, making it easy to read quickly. Every sentence earns its place.
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 low complexity (one parameter, output schema exists), the description covers the tool's purpose, usage guidance, and parameter details. The existence of an output schema means return values need not be explained, so the description is sufficiently complete.
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 0% description coverage, but the description fully compensates by explaining the 'driver' parameter: 'Driver name/code, or "all" for every driver (default: all).' This adds significant meaning beyond the schema, clarifying acceptable values and defaults.
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 action: 'Get pit stop details' and specifies what details (when each driver pitted and which tyre). It also lists specific use cases like pit strategy and undercut/overcut timing, distinguishing it from sibling tools like tire_stints.
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 provides usage scenarios: 'Use this when the user asks about pit strategy, when someone pitted, how many stops a driver made, or undercut/overcut timing.' It does not mention when not to use or alternatives, but the guidance is clear and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get qualifying results with Q1/Q2/Q3 times.
Use this when the user asks about qualifying positions, Q1/Q2/Q3 times, pole position, or qualifying performance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly describes a read operation with no side effects, though it could explicitly state non-destructive nature. Still, purpose is 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?
Two sentences, front-loaded with main action, no wasted words. Efficient and scannable.
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 zero parameters and output schema present, the description is complete for an agent to understand and invoke the tool. No 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?
No parameters exist, so baseline 4 applies. The description adds no parameter info, but that's acceptable given zero 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?
The description uses a specific verb ('Get') and resource ('qualifying results') and clearly distinguishes from siblings like race_result by specifying Q1/Q2/Q3 times.
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 states when to use: for qualifying positions, Q1/Q2/Q3 times, pole position, or qualifying performance. This provides clear context and excludes other related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full race classification — who finished where.
Use this when the user asks about race results, who won, podium positions, DNFs, points scored, or finishing order.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates it returns race classification data, implying a read operation. However, with no annotations and no mention of prerequisites (e.g., needing a session selected), the behavioral transparency is adequate but could be improved by noting context dependencies.
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 with two sentences: the first states the core purpose, the second gives usage examples. 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 the tool's simplicity (no parameters) and the presence of an output schema, the description is largely complete. It could mention the need for an active race session, but this is implicit from the domain.
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 tool has no parameters, so the baseline is 4. The description does not need to explain parameters, and it appropriately focuses on the tool's purpose.
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 verb 'Get' and resource 'full race classification', and lists specific examples like who won, podium, DNFs, points, and finishing order. This makes the tool's purpose distinct from sibling tools like qualifying_result.
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 says 'Use this when the user asks about race results, who won, podium positions, DNFs, points scored, or finishing order.' This provides clear usage context, though it does not mention 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 the full F1 race calendar for a season.
Use this when the user asks about the schedule, which races happened, or wants to know race names to load a session.
Args: year: Season year (e.g. 2024, 2025, 2026)
| 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 should disclose behavioral traits. It describes the return value but doesn't mention read-only nature, auth needs, or other side effects. Adequate for a simple list tool but could add more.
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?
Two sentences and an args section, front-loaded with purpose. No unnecessary words, every sentence earns its place.
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 simple single-parameter tool and presence of an output schema, the description is complete enough. It explains the purpose and usage context, though could mention that the calendar includes race names and dates.
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 coverage is 0%, so description compensates by explaining the 'year' parameter with examples (e.g. 2024, 2025, 2026), adding meaning beyond the integer type.
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 the full F1 race calendar for a season' with a specific verb and resource. It distinguishes from siblings like load_session or race_result, which are about specific sessions.
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 says 'Use this when the user asks about the schedule, which races happened, or wants to know race names to load a session.' Provides clear context for when to use, though no explicit alternatives or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a session is currently loaded and get its details.
Use this when you need to confirm what session is active before answering a question.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 the full burden. It transparently states it checks state and gets details, but lacks specifics on return format or any potential side effects. With no annotations, a score of 3 is appropriate as it is minimal but accurate.
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?
Two sentences with no unnecessary words. The purpose is front-loaded, and the usage guidance is succinct and clear. Every sentence earns its place.
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 no parameters and an output schema present, the description is complete. It explains both the function and the appropriate usage context without 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?
There are no parameters, and schema description coverage is 100% vacuously. The description adds value by clarifying the 'currently loaded' context, which is not captured in the empty input schema. Exceeds the baseline of 4 for zero-parameter tools.
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 uses a specific verb 'Check' and resource 'session', clearly indicating the tool's purpose to verify if a session is loaded and get details. It distinguishes from sibling tools like 'load_session' and 'session_summary' by focusing on the current loaded state.
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 states when to use: 'Use this when you need to confirm what session is active before answering a question.' This provides clear context, though it does not explicitly mention when not to use or list alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a quick overview of the loaded session with key facts.
Use this as a starting point when the user asks a general question about the session, or when you need context before answering. Includes: winner, DNFs, pit stops, fastest lap, weather.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 describes the contents (winner, DNFs, pit stops, fastest lap, weather) and implies read-only behavior. No contradictions, and the behavior is adequately transparent for a query 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 short, front-loaded with purpose, immediately followed by usage guidance and content listing. Every sentence is essential; 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 zero parameters and the existence of an output schema, the description is complete. It lists all included fields and clearly defines the tool's scope as a quick overview, making it fully sufficient for this simple 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 tool has no parameters and schema coverage is 100%. The description adds value by listing the specific data fields included in the overview, which exceeds the baseline of 4 for zero-parameter tools.
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 a quick session overview with key facts. It distinguishes from sibling tools by positioning itself as a starting point for general questions, making the purpose specific and well-defined.
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 says to use this tool when the user asks a general question about the session or before answering, providing clear context. It does not explicitly mention when not to use it, but the sibling context implies more specific tools exist for detailed queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get tyre stint breakdown — compound, start/end lap, stint length.
Use this when the user asks about tyre strategy, which compounds were used, how long stints were, or compound choices.
Args: driver: Driver name/code, or "all" for top 10 drivers (default: all)
| Name | Required | Description | Default |
|---|---|---|---|
| driver | No | all |
| 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 for behavioral disclosure. It does not mention any behavioral traits such as whether it is read-only, rate limits, or authentication requirements. Only describes the core function.
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 short, with two focused sentences and a clear args section. Every word earns its place, no 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 is simple with one optional parameter and an output schema exists, the description covers purpose, usage, and parameter semantics completely. 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?
The input schema only provides type string and default 'all'. The description adds meaning by explaining the driver parameter accepts a name/code or 'all' for top 10 drivers, which significantly adds value beyond the schema for 0% coverage.
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 explicitly states it gets tyre stint breakdown including compound, start/end lap, stint length. This is a specific verb and resource combination that distinguishes it from sibling tools like pit_stops or fastest_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?
Clearly tells the agent to use this when the user asks about tyre strategy, compounds, stint lengths. Provides explicit usage context but does not mention when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get how track conditions changed during the session.
Use this when the user asks about track rubbering in, grip changes, whether the track got faster, or temperature effects on pace.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose any behavioral traits such as data sources, update frequency, or side effects. For a tool with zero annotations, this is insufficient.
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?
Three sentences: first states purpose, then usage examples. Front-loaded and concise with no redundant information.
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 presence of an output schema (though not shown), the description adequately explains the tool's purpose and use cases. Could mention output summary but not required.
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?
No parameters, so baseline of 4 applies. Schema coverage is 100% trivially, no parameter details needed.
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 gets how track conditions changed during a session. It uses a specific verb and resource, and distinguishes from sibling tools like weather and session_summary.
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 mentions when to use (e.g., track rubbering, grip changes, temperature effects). Does not specify when not to use, but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get weather conditions during the session.
Use this when the user asks about weather, track temperature, rain, or conditions that may have affected the race.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 the full burden. It states it retrieves conditions, which implies a read operation, but lacks details on data freshness or scope beyond 'during the session'. Minimal but acceptable.
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 two sentences, front-loaded with purpose, and contains no unnecessary 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 parameters and an output schema, the description is fairly complete. It explains what and when, though it could clarify that it pertains to the currently loaded session.
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?
There are zero parameters and schema coverage is 100%, so the description does not need to add parameter info. Baseline is 4.
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 gets weather conditions during the session, using a specific verb and resource. It distinguishes from siblings as no other tool explicitly covers weather.
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 lists when to use (weather, track temperature, rain, conditions) but does not mention exclusions or alternatives. Since no sibling covers weather, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly defined and distinct purpose with detailed descriptions that prevent overlap. For example, driver_telemetry focuses on summary lap statistics while lap_times provides lap-by-lap timing, and pit_stops vs tire_stints differentiate between timing and compound details.
All tool names use lowercase snake_case consistently and follow a descriptive pattern, either noun_phrase (e.g., fastest_laps, pit_stops) or verb_noun (e.g., list_drivers, load_session). No mixed conventions or vague verbs are present.
With 17 tools, the server covers the F1 analysis domain thoroughly but slightly exceeds the typical well-scoped range of 3-15. However, each tool serves a distinct purpose, so the count feels justified rather than excessive.
The tool set covers all major aspects of F1 session analysis: session loading, race and qualifying results, driver telemetry and laps, pit stops, tire stints, overtakes, track evolution, weather, head-to-head comparisons, and season calendars. No obvious gaps or dead ends exist for common queries.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
MCP server giving Claude AI access to 22+ NYC public-record databases for real estate due diligence
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/aashnakunk/fastf1-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
