Model Context Protocol is awesome Part I: Turbocharging AI with Formula 1 Data
Anthropic released the open-source Model Context Protocol (MCP) back in November 2024 to a rather cold response [1]. But the start of 2025 has been nothing short of a huge hype train for MCP, and it is well deserved too. Everyone wants to augment the LLM context with stuff that really matters to them, and these models are also getting increasingly incredible at deriving insights or solving problems using this custom contextual information that you can feed it. So it all comes down to one thing really, how well can you feed this information to these models and maybe even let the model interact with where this data resides and let it just take it?
Rise of RAG: Early signs of whats about to come
Early LLM applications relied heavily on custom designing workflows around gathering the relevant data based on the task at hand, often we accessing the data and pushing it to the model to make an inference on it.
But this often meant that we had to figure out what data is useful at what point in the workflow. A question like “the fastest driver in sector 3?” would need us to look at a different portion/table/file of the data than lets say something like “what happened to Carlos Sainz during the safety car?”. This meant it was getting a bit tedious for us to think of a million scenarios and structure our application to look at the right piece of information to answer a given question / proceed further in a workflow.
This is exactly what tool calling models are trying to address. The whole premise is to provide a bit more autonomy to the model to make a judgement call to decide what to use. You ask the model “was there a race today?” let the model figure out that it needs to use a web search tool, or better yet some other tool which will help answer this question directly, like an API call that gets you real-time F1 sessions data.
The Challenge of Function Calls
When we want LLMs to help us execute a function which returns a data object/ has some other side effects there are a few things to consider.
- How do we tell what each input/output parameters are of our function?
- What values are allowed or disallowed and how do we reliably help the LLM figure out what the right value will be?
Take the following example:
from typing import Optional, Literal, List
async def get_sessions(
date_start: str,
session_type: Optional[Literal["Qualifying", "Practice", "Race"]] = None,
) -> List[Session]:
"""
Get all racing sessions happening based on the filters
Args:
date_start: Start Date of the session to filter in ISO 8601 format
session_type: Type of session to filter on
Returns:
List of sessions
"""
url = f"{BASE_URL}/sessions?date_start>={date_start}"
if session_type:
url += f"&session_type={session_type}"
session_response = await get_response(url)
if session_response is None:
logger.warning("Session response is None")
return []
sessions = []
for session in session_response:
meeting_key = session["meeting_key"]
url = f"{BASE_URL}/meetings?meeting_key={meeting_key}"
meeting_response = await get_response(url)
if meeting_response is None:
logger.warning("Meeting response is None")
continue
all_data = {**session, **meeting_response[0]}
sessions.append(Session(**all_data))
return sessionsThis function fetches the F1 sessions using an API call to OpenF1. If I were to ask the LLM to help me call this function I would also need to tell the model that Date should be formatted in a particular way for the server or the session type can only be one of “Qualifying”, “Practice”, or “Race”, and we need to output a list of sessions. We know what session means and what each key in session contains, how do we reliably communicate the same to the model, every time?
Well one might ask, “What if you had something that just understands the type hints that we are providing, and gives it to the model in a standard way every time, clearly telling this is what you need to call get_sessions, and this is what you get from get_sessions? And not just get_sessions, any other complex function we have?”, and to take it a step forward “how do I create a uniform standard so you, me and everyone else can just write any of these functions like usual and we can just plug it into the model making it usable, callable by the model?” This is exactly what MCP solves. A common analogy thats often thrown around goes like “MCP is the USB hub where you can plug many devices(functions) into, which is plugged into the computer (LLM) which can choose how to use them”
Another neat thing? You just need one core LLM logic/application. These servers kind of plug and play onto it without you having to modify anything else. Just attach them and let the LLM choose for you. Since the turn of 2025 many such servers have indeed surfaced on the internet. Many of which you can just choose to plug to your application as is much like downloading an app to run on you r phone. Here’s one such collection, Awesome MCP servers.
Strong Typing FTW
Right now all we need to have a strong type hinted application. You add a few decorators to it and you have your MCP Server. For people who want to customize how to make use of these “adapters” there are custom MCP Clients. Have a look here. The universality of these servers is to be much adored, and I am especially excited about plugging in the server when you need it and just removing it when you are done without anything breaking!
Which brings me to how you write one. The entire codebase for this post is available on github. But here’s the core idea. Going back to the “Sessions” problem, you just define your session in plain english:
from pydantic import BaseModel, Field
from typing import Literal, Optional, List
class Session(BaseModel):
session_key: int = Field(description="Unique identifier for the session")
session_name: str = Field(description="Name of the session")
session_type: Literal["Qualifying", "Practice", "Race"] = Field(
description="Type of session"
)
date_start: str = Field(
description="Starting timestamp of the session in ISO 8601 format"
)
date_end: Optional[str] = Field(
None, description="Ending timestamp of the session in ISO 8601 format"
)
meeting_key: int = Field(description="Unique identifier for the meeting")
circuit_short_name: str = Field(description="Short name of the circuit")
country_name: str = Field(description="Name of the country")
meeting_official_name: Optional[str] = Field(
None, description="Official name of the race"
)Pydantic is pretty neat because it will convert most of these custom types into a well-defined, standard schema, that translates to exactly what most LLM providers use for tool definitions. And to make the get_sessions function from before into an MCP Tool (MCP has other types too, like resources, prompts etc which I wont go into much detail here, a part 2 is on the cards), this is what you do:
from mcp.server.fastmcp import FastMCP
from f1_types import Session
from typing import List, Optional, Literal
from loguru import logger
from openf1_utils import get_response
BASE_URL = "https://api.openf1.org/v1"
mcp = FastMCP(
"F1 Data",
instructions="You can access real-time or historical Formula 1 (F1) data with this",
)
@mcp.tool()
async def get_sessions(
date_start: str,
session_type: Optional[Literal["Qualifying", "Practice", "Race"]] = None,
) -> List[Session]:
"""
Get all racing sessions happening based on the filters
Args:
date_start: Start Date of the session to filter in ISO 8601 format
session_type: Type of session to filter on
Returns:
List of sessions
"""
url = f"{BASE_URL}/sessions?date_start>={date_start}"
if session_type:
url += f"&session_type={session_type}"
session_response = await get_response(url)
if session_response is None:
logger.warning("Session response is None")
return []
sessions = []
for session in session_response:
meeting_key = session["meeting_key"]
url = f"{BASE_URL}/meetings?meeting_key={meeting_key}"
meeting_response = await get_response(url)
if meeting_response is None:
logger.warning("Meeting response is None")
continue
all_data = {**session, **meeting_response[0]}
sessions.append(Session(**all_data))
return sessionsThats right. Just add the decorator and you are done. I think this is a win-win. Everyone will be forced to add strong type hints to your code, making it more readable to not just AI but Humans too. And just decorate when you want something to be accessed by the AI.
The Completed F1 Companion
To test these ideas, I have expanded this tool kit with a few more much the same way.
- A Drivers tool, to fetch the information on the participating drivers
- A Track Conditions tool, which fetches the track conditions like rain, humidity, temperature etc
- A Laps tool, which fetches the laps by a driven during a session with sector wise timing data
- And most importantly a Clock for the AI, so it can reliably tell time. The smartest machines cant tell time, maybe there’s something about time which we all take for granted!
Now once you have the tools setup we need to connect it to a client. There were a few potential options here:
1. Claude Desktop has support for MCP, after all they made this whole thing
2. 5ire is also a solid chatbot application, if you want to use other tool calling models, and even Ollama ones to run stuff locally.
3. A custom python client that is attached to our MCP server, which offers a lot of flexibility. We can swap models in and out, decide what to do with the data so on. The implementation is adapted from the MCP Client example by anthropic team, with a few minor tweaks. This is also available in the same git. I will add the instructions in the README as well to start the server.
Lets take this for a spin.
Connected to server with tools: ['get_sessions', 'get_drivers', 'get_laps', 'get_track_conditions', 'get_current_date_and_time']
MCP Client Started!
Type your queries or 'quit' to exit.
**Query =>** Get me the lap times for lando and max from today's race.
Certainly! I'd be happy to help you get the lap times for both Lando Norris and Max Verstappen in today's race. To do this, we'll need to go through a few steps using the available tools. Let's begin:
1. First, we need to find out today's date and the current race session.
2. Then, we'll need to get the session key for today's race.
3. Finally, we'll fetch the lap times for both drivers.
Let's start by getting the current date:
[Calling tool get_current_date_and_time with args {}]
Great, now we know the current date is 2025-03-16. Let's use this to find today's race session:
[Calling tool get_sessions with args {'date_start': '2025-03-16', 'session_type': 'Race'}]
Perfect! We've found the race session for today. The session key is 9693.
Now, let's get the lap times for both Lando Norris and Max Verstappen. We'll need to make two separate calls, one for each driver. First, let's find out their driver numbers:
[Calling tool get_drivers with args {'session_key': 9693}]
Now we have the driver numbers:
- Max Verstappen: 1
- Lando Norris: 4
Let's get the lap times for both drivers:
[Calling tool get_laps with args {'session_key': 9693, 'driver_number': 1}]
Now, let's get the lap times for Lando Norris:
[Calling tool get_laps with args {'session_key': 9693, 'driver_number': 4}]
**Query =>** Compare the sector-wise performance of both these drivers. Include the weather data and draw any correlations to lap performance and the weather condition.
Certainly! To provide a comprehensive analysis of the sector-wise performance for both Max Verstappen and Lando Norris, including weather data correlation, we'll need to gather the track conditions data as well. Let's start by getting that information:
[Calling tool get_track_conditions with args {'session_key': 9693}]
Now that we have all the necessary data, let's analyze the sector-wise performance for both drivers and correlate it with the weather data:
1. Max Verstappen's Performance:
Sector 1:
- Best time: 28.766 seconds (Lap 21)
- Average time: 32.493 seconds
- Performance trend: Gradually improved throughout the race, with best times in the middle and latter parts.
Sector 2:
- Best time: 18.154 seconds (Lap 21)
- Average time: 19.324 seconds
- Performance trend: Consistent throughout, with slight improvements in the middle of the race.
Sector 3:
- Best time: 35.634 seconds (Lap 20)
- Average time: 40.898 seconds
- Performance trend: Variable, with best times in the middle of the race.
2. Lando Norris's Performance:
Sector 1:
- Best time: 28.553 seconds (Lap 20)
- Average time: 33.155 seconds
- Performance trend: Improved gradually, with best times in the latter part of the race.
Sector 2:
- Best time: 18.537 seconds (Lap 20)
- Average time: 19.471 seconds
- Performance trend: Consistent throughout, with slight improvements towards the end.
Sector 3:
- Best time: 34.890 seconds (Lap 19)
- Average time: 40.524 seconds
- Performance trend: Variable, with best times in the middle and latter parts of the race.
3. Weather Correlation:
- Temperature: The air temperature increased from 15.8°C to 16.2°C during the race, while track temperature remained relatively stable around 19.2°C - 19.3°C.
- Humidity: Decreased from 75% to 71% throughout the race.
- Wind: Wind speed varied between 1.2 m/s to 5.1 m/s, with changing directions.
- Rainfall: There were periods of light rainfall (1.0 mm) during the race, particularly in the early and middle stages.
Analysis:
1. Both drivers showed similar performance trends, with gradual improvements throughout the race.
2. Max Verstappen generally had slightly faster sector times compared to Lando Norris, especially in Sectors 2 and 3.
3. The best lap times for both drivers came in the middle to latter parts of the race (Laps 19-21), coinciding with:
- Higher air temperatures (16.4°C - 16.6°C)
- Lower humidity (68% - 71%)
- Dry track conditions (no rainfall)
4. The variable performance in Sector 3 for both drivers might be attributed to changing wind conditions, as wind direction and speed were more inconsistent during the race.
5. Early in the race, when there was light rainfall, both drivers had slower lap times. As the track dried and temperatures increased, their performance improved.
6. The increase in air temperature and decrease in humidity throughout the race likely contributed to improved grip and faster lap times for both drivers.
7. Wind direction changes may have affected cornering speeds and straight-line performance, explaining some of the variability in sector times.
In conclusion, both Max Verstappen and Lando Norris showed similar performance trends, with Verstappen having a slight edge in overall pace. The improving weather conditions (increasing temperature, decreasing humidity, and drying track) played a significant role in the drivers' ability to achieve faster lap times as the race progressed. The changing wind conditions may have contributed to the variability in Sector 3 performance for both drivers.
**Query =>**There’s more to MCP and am getting around to testing all the features. I will look to cover Prompts and Resources and Server Sent Events (SSE) servers in the upcoming posts to make the full use of MCP. See you then 🙌🏻
Originally published at https://aarunjith.substack.com.
