Skip to main content
Glama
Crawlora MCP

Crawlora MCP

Official

openf1_drivers

Fetch Formula 1 drivers for a session or meeting, including numbers, names, acronyms, teams, colours, and headshots. Use the returned driver_number to query telemetry, laps, or position data.

Instructions

OpenF1 Formula 1 drivers in a session or meeting. Returns the drivers entered in a session or meeting with their permanent number, broadcast/full name, three-letter acronym, team name and colour, and headshot URL. Use it to resolve a driver_number before querying telemetry, laps or position data.

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

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, broadcast_name, full_name, name_acronym, team_name, team_colour, first_name, last_name, headshot_url, country_code.
full_nameNoFull driver name example(Lando NORRIS)
team_nameNoTeam name exactly as the source reports it example(McLaren)
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)
country_codeNoThree-letter country code example(BRA)
name_acronymNoThree-letter driver acronym example(NOR)
driver_numberNoPositive permanent driver number (see openf1-drivers) example(1)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A3.6/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 full burden; it partially discharges this by enumerating the exact payload fields, which substitutes for a missing output schema. It says nothing about pagination, result volume, live vs historical freshness, or whether the call is read-only and safe to repeat, leaving real gaps for a data-fetch 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 the resource and its return shape, then the routing hint. Minor redundancy in restating 'drivers in a session or meeting' twice, but no wasted prose.

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?

With no output schema, the description compensates by listing returned attributes, and all 8 optional parameters are documented in the schema, so an agent can call it correctly. Only the absence of any behavioral notes (pagination, freshness, filtering semantics) keeps it short of 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 coverage is 100% and each of the 8 parameters already carries a description with an example, so the schema does the heavy lifting. The description adds only light framing — that driver_number is the identifier to resolve and that lookups are scoped to a session or meeting — which is marginal beyond structured 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 and resource ('Returns the drivers entered in a session or meeting') and enumerates the returned fields (driver number, names, acronym, team, colour, headshot). The session/meeting scoping implicitly distinguishes it from championship-level siblings, but no sibling is named explicitly, so an agent must infer the boundary.

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?

Provides a concrete downstream use: 'resolve a driver_number before querying telemetry, laps or position data,' which tells the agent when this tool is the right first step. It gives no exclusions, though — nothing explains when to prefer openf1_championship_drivers or formula1_json_drivers instead.

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