Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

openf1_pit

Retrieve Formula 1 pit-lane entries with lap number, lane time, and stationary stop time, then filter by session, driver, date, or duration for race analysis.

Instructions

OpenF1 Formula 1 pit lane entries. Returns pit-lane entries with the lap number, time spent in the pit lane and the stationary stop time where the source publishes it (from the 2024 United States Grand Prix onwards). Present across session types, so pass session_key and optionally driver_number.

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_pit"
  }
}

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, lap_number, driver_number, date, pit_duration, lane_duration, stop_duration.
`date_to`	No	Inclusive upper bound; RFC3339 timestamp or YYYY-MM-DD example(2026-11-08)
`date_from`	No	Inclusive lower bound; RFC3339 timestamp or YYYY-MM-DD example(2026-11-07)
`lap_number`	No	Lap number within the session, starting at 1 example(8)
`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)
`driver_number`	No	Positive permanent driver number (see openf1-drivers) example(1)
`stop_duration_lt`	No	Exclusive maximum stationary stop time, in seconds example(2.3)
`lane_duration_gte`	No	Inclusive minimum pit-lane time, in seconds
`lane_duration_lte`	No	Inclusive maximum pit-lane time, in seconds
`stop_duration_lte`	No	Inclusive maximum stationary stop time, in seconds

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It does disclose a genuinely useful data-availability trait the schema does not: stationary stop time is only published from the 2024 United States Grand Prix onwards. However, it says nothing about result volume, ordering, pagination, or what happens when no session_key is supplied despite all parameters being optional.

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 sentences, front-loaded with the resource and its payload, then the availability caveat, then the usage hint. Every sentence contributes; only mild redundancy in restating 'pit lane' twice. No filler or marketing language.

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 an 11-parameter, no-annotation, no-output-schema tool, the description covers the essentials: what is returned, the field-level caveat, and the scoping parameter. Since no output schema exists, the enumeration of return fields is valuable. It remains slightly incomplete on default result limits and on whether an unscoped call is permitted.

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

Parameters3/5

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

Schema coverage is 100%, so all 11 parameters, including the filter syntax and the duration bounds, are already documented upstream; baseline is 3. The description adds only marginal meaning, clarifying that session_key is the primary scoping parameter and driver_number is optional, but does not explain how the duration filters or the free-form filter string relate to the returned fields.

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?

States a specific verb+resource ('Returns pit-lane entries') and enumerates the returned fields: lap number, lane time, stationary stop time. It is clearly distinguishable from every sibling because none of them concern pit lane data. It stops short of a 5 because it never names or contrasts with an adjacent sibling (e.g. openf1_laps, openf1_stints) that an agent might confuse this with.

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?

It gives a concrete invocation hint: 'pass session_key and optionally driver_number', and notes that the data is 'Present across session types', implying a session_key is always needed. There is no when-to-use vs when-not guidance, no mention of using meeting_key or date filters for broader sweeps, and no naming of an alternative tool.

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

Deploy Server