Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

openf1_weather

Fetch Formula 1 track weather samples by session, meeting, or date window, including air/track temperature, humidity, pressure, wind, and rainfall. Use filters to bound minute-level race conditions.

Instructions

OpenF1 Formula 1 track weather samples. Returns track-weather samples updated about once a minute: air and track temperature, humidity, pressure, wind speed and direction, and the rainfall flag. Pass session_key or meeting_key plus a date window for a bounded read.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "openf1_weather"
  }
}

Input Schema

Name	Required	Description
`filter`	No	Repeatable upstream filter written as <attribute><operator><value>, with operators >=, <=, =, > and <. Repeated filters on the same attribute are OR'ed, a lower and upper bound form an inclusive range, and different attributes are AND'ed. Filterable attributes on this route: meeting_key, session_key, date, air_temperature, humidity, pressure, rainfall, track_temperature, wind_direction, wind_speed.
`date_to`	No	Inclusive upper bound; RFC3339 timestamp or YYYY-MM-DD example(2026-11-08)
`rainfall`	No	Rainfall flag, 0 or 1
`date_from`	No	Inclusive lower bound; RFC3339 timestamp or YYYY-MM-DD example(2026-11-07)
`meeting_key`	No	Positive meeting key from openf1-meetings, or `latest` for the current meeting example(1299)
`session_key`	No	Positive session key from openf1-sessions, or `latest` for the current session example(11408)
`humidity_gte`	No	Inclusive minimum relative humidity percentage
`humidity_lte`	No	Inclusive maximum relative humidity percentage
`pressure_gte`	No	Inclusive minimum air pressure in mbar
`pressure_lte`	No	Inclusive maximum air pressure in mbar
`wind_speed_gte`	No	Inclusive minimum wind speed in m/s
`wind_speed_lte`	No	Inclusive maximum wind speed in m/s
`wind_direction_gte`	No	Inclusive minimum wind direction in degrees example(130)
`wind_direction_lte`	No	Inclusive maximum wind direction in degrees
`air_temperature_gte`	No	Inclusive minimum air temperature in Celsius
`air_temperature_lte`	No	Inclusive maximum air temperature in Celsius
`track_temperature_gte`	No	Inclusive minimum track temperature in Celsius example(52)
`track_temperature_lte`	No	Inclusive maximum track temperature in Celsius

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry behavioral disclosure, and it does add genuinely useful context: the ~1-minute update cadence and the implication that omitting session/meeting key plus date window yields an unbounded read. It stops short of disclosing result caps, pagination, ordering, or defaults for an all-optional 18-parameter read, which leaves meaningful gaps for a bulk time-series endpoint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences: identity, returned fields and cadence, then the invocation rule. The field enumeration is slightly list-like but conveys actual payload content, so almost every clause earns its place; nothing is padded or front-loaded behind throat-clearing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only weather timeseries with 18 optional params, no output schema, and no annotations, the description covers what the tool is, what it returns, how fresh the data is, and how to bound a query — enough for an agent to call it correctly. The remaining gaps (unfiltered query size, the filter-vs-typed-param overlap, no output shape description) are modest rather than disqualifying.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, and the description adds a bit beyond the schema by recommending the session_key/meeting_key + date-window combination for a bounded read. It does not, however, explain the relationship between the dedicated gte/lte properties and the repeatable `filter` array, which is the one genuinely ambiguous part of the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"OpenF1 Formula 1 track weather samples" names a specific resource with an explicit verb (returns samples) and enumerates the payload fields (air/track temperature, humidity, pressure, wind speed/direction, rainfall). It is clearly distinguishable from data siblings like openf1_laps or openf1_position, though it never contrasts itself with the other weather tool (pgatour_tournament_weather) or states its own uniqueness beyond the OpenF1 prefix.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The closing sentence gives a positive invocation recipe — "Pass session_key or meeting_key plus a date window for a bounded read" — which is real usage guidance about how to scope a call. However, it offers no when-not guidance, no statement about what happens without filters beyond implying an unbounded read, and no explicit alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server