Skip to main content
Glama
Crawlora MCP

Crawlora MCP

Official

openf1_position

Retrieve every Formula 1 driver position change during a session with timestamps. Filter by session, driver, date, or position range to return compact results.

Instructions

OpenF1 Formula 1 driver position changes. Returns each driver's position at every change during a session, with the timestamp of the change. Pass session_key with driver_number or a position bound to keep the result small.

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

Input Schema

NameRequiredDescriptionDefault
filterNoRepeatable 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, driver_number, date, position.
date_toNoInclusive upper bound; RFC3339 timestamp or YYYY-MM-DD example(2026-11-08)
date_fromNoInclusive lower bound; RFC3339 timestamp or YYYY-MM-DD example(2026-11-07)
meeting_keyNoPositive meeting key from openf1-meetings, or `latest` for the current meeting example(1299)
session_keyNoPositive session key from openf1-sessions, or `latest` for the current session example(11408)
position_gteNoInclusive minimum position, starting at 1
position_lteNoInclusive maximum position, starting at 1 example(3)
driver_numberNoPositive permanent driver number (see openf1-drivers) example(1)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the burden: it discloses the return shape (one record per position change, with timestamp) and warns that unfiltered calls produce large results. It says nothing about pagination, result caps, auth, or what an empty result means, which leaves real gaps for a data-feed tool.

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?

Two sentences, front-loaded with what is returned, followed by the filtering hint. No filler or repeated wording; tightening would only marginally improve it.

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

Completeness3/5

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

With eight optional parameters, no annotations, and no output schema, the definition covers purpose and result shape but not the effective requirement of a session filter, pagination behavior, or the record fields returned. Adequate to make a first call, but not complete.

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 schema already explains each parameter and a baseline of 3 would apply. The description still adds value beyond the schema by recommending a specific combination (session_key plus driver_number or a position bound) even though no parameter is marked required, which steers an agent toward a well-scoped query.

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 first two sentences name a specific verb and resource ('Returns each driver's position at every change during a session, with the timestamp'), which is concrete enough to distinguish this from interval, lap, or overtake data. It doesn't explicitly name a sibling to route against, which keeps it just short of a 5.

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 description gives practical narrowing advice ('Pass session_key with driver_number or a position bound to keep the result small'), which implies the intended usage pattern. However, it never states when to choose this over openf1_intervals or openf1_overtakes, nor any exclusions.

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

Deploy Server

Other Tools