Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

formula1_session_results

Retrieve one Formula 1 session result table by meeting ID and session type, covering race, qualifying, practice, sprint, grid, pit stops, and fastest laps.

Instructions

One Formula 1 session result table by meeting id. Returns one session's classified table for a meeting: race, qualifying, starting grid, practice 1 to 3, pit-stop summary, fastest laps or the three sprint sessions. The meeting id is the real selector; the season and slug parameters only build the upstream URL and are decorative on the site's own detail pages. A session the site has no data for (a sprint view on a non-sprint weekend, or a practice session the weekend did not run) is a valid empty result.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "meeting_id": "<meeting_id>",
      "session": "<session>"
    },
    "name": "formula1_session_results"
  }
}

Input Schema

Name	Required	Description
`season`	No	Four-digit season used in the upstream URL only; the meeting id selects the data. Defaults to the current season example(2026)
`session`	Yes	Session view: race-result, qualifying, starting-grid, practice-1, practice-2, practice-3, pit-stop-summary, fastest-laps, sprint-results, sprint-grid or sprint-qualifying
`meeting_id`	Yes	Numeric meeting id from formula1-meetings, such as 1299 example(1299)
`meeting_slug`	No	Results-archive slug used in the upstream URL only; the meeting id selects the data. Defaults to a fixed placeholder example(brazil)

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

TDQS

A3.6/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 does well on the important behavior: a session the site has no data for returns a valid empty result rather than an error, which prevents an agent from misreading a null/empty table as failure. It also discloses that season and slug are decorative URL components. It stops short of describing the returned table's shape, pagination, or what happens on an invalid meeting id.

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?

Four sentences, front-loaded with the resource and its scope, then the selector semantics, then the empty-result caveat. Every sentence carries information, though the selector sentence partially duplicates what the schema already says about season and slug.

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?

For a tool with no annotations and no output schema, the description covers input selection and the empty-result case but never characterizes the return value beyond the vague phrase 'classified table' — column set, ordering, or units (e.g. race position, time gaps) go unexplained. An agent knows how to call it, but not what it will get back.

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 both required and optional parameters are already documented, and the description's statements about meeting_id being the real selector and season/slug being decorative largely restate the schema descriptions. It reinforces the most error-prone semantic (which parameter actually selects data) but adds no new format or value detail beyond the schema.

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 state a specific verb and resource ('Returns one session's classified table for a meeting') and enumerate the session views covered (race, qualifying, grid, practice, pit stops, fastest laps, sprints). It is clear this is a per-meeting session table rather than a season- or driver-aggregate tool, though it never names the sibling tools (formula1_season_results, formula1_json_results) it should be preferred over.

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 strong selection guidance for the parameters ('The meeting id is the real selector') and a useful edge case (a missing session yields a valid empty result), which implies when the tool is appropriate. It does not state when to use a different tool instead, nor does it mention prerequisites such as first resolving a meeting id via formula1-meetings, which is only referenced inside the schema.

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

Deploy Server