Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

openf1_overtakes

Retrieves Formula 1 race position exchanges, naming the overtaking and overtaken driver plus the position held after the pass. Filter by meeting, session, driver or date.

Instructions

OpenF1 Formula 1 overtakes. Returns position exchanges during race sessions, naming the overtaking and overtaken driver and the position held after the pass. The source includes pit-stop and penalty position changes and states the data may be incomplete. Race sessions only.

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

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, overtaking_driver_number, overtaken_driver_number, date, position.
`date_to`	No	Inclusive upper bound; RFC3339 timestamp or YYYY-MM-DD example(2026-11-08)
`position`	No	Exact position, starting at 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)
`overtaken_driver_number`	No	Number of the driver who lost the position example(4)
`overtaking_driver_number`	No	Number of the driver who gained the position example(63)

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the full burden, and it does meaningful work: it warns that pit-stop and penalty position changes are included in the source, which would otherwise look like genuine overtakes, and it states the data may be incomplete. Those are exactly the caveats an agent needs to avoid misinterpreting results; only the absence of any pagination or response-shape detail keeps it from a 5.

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

Conciseness5/5

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

Four short sentences, front-loaded with the resource and return content, then the caveats, then the scope restriction. No filler and nothing buried.

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?

There is no output schema, so the description must convey return content, and it does by naming the drivers involved and the resulting position. The main remaining gap is that it doesn't mention the identifying keys (meeting_key, session_key) the results carry, which would help an agent chain calls, but for this complexity the coverage is nearly complete.

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 description coverage is 100%, so all eight parameters (including the repeatable filter syntax and the 'latest' shorthands) are already fully documented in the schema. The description adds no parameter-level meaning beyond what the schema supplies, so the baseline of 3 applies.

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?

The description uses a specific verb and resource: 'Returns position exchanges during race sessions,' and names the fields returned (overtaking and overtaken driver, position after the pass). This clearly separates it from raw-standings siblings like openf1_position, though it never names that sibling explicitly.

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 constraint 'Race sessions only' tells the agent when the tool is applicable, which is real guidance. But there is no explicit when-to-use-versus-alternative routing (e.g., use openf1_position for full order, this for exchanges), so the guidance is implied rather than stated.

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

Deploy Server