Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

openf1_intervals

Retrieve Formula 1 race session interval and gap measurements, including gaps to the car ahead and leader, to analyze race positions and pacing.

Instructions

OpenF1 Formula 1 interval and gap measurements. Returns the gap to the car ahead and the gap to the leader, updated about every four seconds during race sessions. Values are raw source data: a number of seconds, an array, or a string such as +1 LAP, and null for the leader. Race sessions only; other session types return an empty list.

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

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, gap_to_leader, interval, date.
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)
interval_gtNoExclusive minimum gap to the car ahead, in seconds
interval_ltNoExclusive maximum gap to the car ahead, in seconds
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)
driver_numberNoPositive permanent driver number (see openf1-drivers) example(1)
gap_to_leader_gtNoExclusive minimum gap to the leader, in seconds
gap_to_leader_ltNoExclusive maximum gap to the leader, in seconds

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations and no output schema, the description carries the full burden and does so well: it discloses the return value polymorphism (seconds as a number, an array, or a string like '+1 LAP', and null for the leader), the update cadence, and the empty-list behavior for non-race sessions. These are exactly the non-obvious behaviors an agent needs to interpret results correctly.

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 tight sentences, front-loaded with purpose before return semantics and session restrictions. Every sentence carries distinct information; none restates the tool name or title.

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 10-parameter, zero-annotation tool with no output schema, the description covers purpose, return format, cadence, and session scope adequately. It does not address what happens when no filters are supplied (full-dataset behavior) or any ordering/pagination, which is a modest remaining gap.

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 every parameter including the filter grammar and interval_gt/interval_lt bounds is already documented upstream. The description adds indirect meaning by explaining that gap values can be null, arrays, or lap strings, which informs filtering, but it adds no direct guidance on parameter usage beyond the schema. Baseline 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 names the specific resource (F1 interval/gap measurements) and what is returned (gap to the car ahead and gap to the leader), which is concrete enough to distinguish it from siblings like openf1_position or openf1_laps. It stops short of explicitly naming which sibling to use for adjacent needs, keeping it at a 4 rather than 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 Guidelines4/5

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

It gives a clear scoping rule: race sessions only, other session types return an empty list, which tells the agent when not to call it. It also signals the four-second update cadence for interpreting recency, but never names an alternative tool or explains what to use for non-race sessions.

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