Race Calendar F1

Server Details

Anonymous read-only Formula 1 tools, resources, prompts, completion, and interactive dashboard.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-21 03:21
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.9/5.0

Scored 2026-09-09 18:54 across 15 tools

Disambiguation4/5

Most tools are clearly distinct (schedule, live, preview, results, standings, search). However, get_f1_historical_race_result vs get_f1_historical_race_results vs get_f1_session_results vs get_f1_race_classification could be confusing at a glance; the 'historical' pair is explicitly differentiated, but the session/classification overlap requires careful reading.

Naming Consistency4/5

Tool names follow a consistent get_/search_/compare_ verb + f1 domain noun pattern, mostly snake_case and readable. Minor deviations: compare_f1_competitors uses a different verb order, and get_f1_historical_race_result(s) is a slightly awkward singular/plural pair, but the naming is otherwise predictable.

Tool Count5/5

15 tools is on the upper edge but appropriate for a comprehensive F1 data server covering schedules, live sessions, race weekends, historical results, standings, previews, and search. Each tool addresses a distinct use case and the count is well-scoped for the domain.

Completeness4/5

The surface covers season schedules, race weekends, live sessions, historical classifications, standings, starting grids, previews, and search—strong coverage for typical F1 data needs. Minor gaps include lack of explicit lap-by-lap data, pit stop details, or driver/team profile tools, but these are not core to the stated purpose.

Available Tools

15 tools

compare_f1_competitorsCompare F1 CompetitorsA

Read-onlyIdempotent

Inspect

Compare two Formula 1 drivers or constructors in one season using sourced standings and explicitly described calculations.

ParametersJSON Schema

Name	Required	Description
`left`	Yes	First driver or constructor name to compare.
`year`	Yes	Formula 1 season year.
`right`	Yes	Second driver or constructor name to compare.
`competitorType`	Yes	Compare two drivers or two constructors.

Output Schema

ParametersJSON Schema

Name	Required	Description
`kind`	Yes
`left`	Yes
`year`	Yes
`right`	Yes
`leader`	Yes
`source`	Yes
`comparison`	Yes
`generatedAt`	Yes
`methodology`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds value by noting 'using sourced standings and explicitly described calculations', which informs about data origin and computation method. No contradiction with annotations.

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?

Single sentence, front-loaded with action and resource. Every word earns its place with no redundancy.

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?

Tool has output schema and required parameters are all covered. Description mentions calculations which is important for a comparison tool. Slightly incomplete regarding return format, but output schema likely covers that.

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% with good parameter descriptions. The description adds minimal extra beyond schema (only mentions calculation method). Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'compare two Formula 1 drivers or constructors in one season' with specific verb (compare) and resource (drivers/constructors). It distinguishes from sibling tools like get_f1_standings by emphasizing head-to-head comparison and explicitly described calculations.

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?

Usage context is implied ('compare two...') but no explicit when-to-use or when-not-to-use guidance is given. No alternatives are mentioned despite sibling tools like get_f1_standings that could serve similar purposes.

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

get_f1_circuitF1 Circuit DetailsA

Read-onlyIdempotent

Inspect

Get circuit metadata and normalized track geometry for a race weekend selected by meeting key, round, race name, or slug.

ParametersJSON Schema

Name	Required	Description
`slug`	No	Race Calendar race slug, such as round-6-miami-grand-prix or miami-grand-prix.
`year`	Yes	Formula 1 season year.
`round`	No	Championship round number for the season.
`raceName`	No	Human-friendly Grand Prix or race name, matched case-insensitively.
`meetingKey`	No	OpenF1 meeting key for the race weekend.

Output Schema

ParametersJSON Schema

Name	Required	Description
`year`	Yes
`round`	Yes
`circuit`	Yes
`raceName`	Yes
`sourceUrl`	Yes
`meetingKey`	Yes
`canonicalUrl`	Yes

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description need not repeat safety details. It adds 'metadata and normalized track geometry' but doesn't elaborate on output format or pagination. With annotations covering safety, a score of 3 is appropriate.

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?

The description is a single sentence of 18 words, front-loading the core action and resource. Every word is necessary, with no redundancy.

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?

Given the existence of an output schema and comprehensive annotations, the description adequately covers the tool's purpose and selection method. It could mention that it returns only circuit-related data (not session results), but that is implied. Overall, it is nearly complete for a simple read tool.

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 the schema already documents each parameter thoroughly. The tool description restates the selection criteria but adds no new semantic meaning beyond the schema. Baseline 3 is correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves circuit metadata and normalized track geometry for a race weekend, using specific selection criteria (meeting key, round, race name, or slug). It distinguishes itself from sibling tools, which focus on competitors, sessions, or results.

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?

The description implicitly defines when to use the tool (when circuit details for a specific race weekend are needed) but lacks explicit guidance on when not to use it or mention of alternatives. Since sibling tools are distinct, the context is clear.

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

get_f1_historical_race_resultHistorical race resultA

Read-onlyIdempotent

Inspect

Get one complete historical Formula 1 race classification by season and championship round. Use only for a single race; for two or more races, call get_f1_historical_race_results once instead.

ParametersJSON Schema

Name	Required	Description	Default
`year`	Yes	Formula 1 season year.
`round`	Yes	Championship round number in the historical season.

Output Schema

ParametersJSON Schema

Name	Required	Description
`race`	Yes
`year`	Yes
`round`	Yes
`results`	Yes
`sourceUrl`	Yes
`generatedAt`	Yes
`canonicalUrl`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds 'complete' and 'historical classification' context, but no additional behavioral details such as result format or edge cases. This is adequate but not rich beyond annotations.

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?

Two sentences, front-loaded with the core action and scope, with an explicit routing instruction. Every sentence earns its place and there is no redundant filler.

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

Completeness5/5

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

The tool is simple, its two parameters are fully described by the schema, an output schema exists, and the description provides the key usage distinction from the plural sibling. Nothing necessary for correct invocation is missing.

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%, and both year and round have clear descriptions in the schema. The tool description adds no new parameter meaning beyond mentioning 'season and championship round', so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Get one complete historical Formula 1 race classification by season and championship round.' It clearly distinguishes itself from the plural sibling tool get_f1_historical_race_results by emphasizing the singular race scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Usage guidance is explicit: 'Use only for a single race; for two or more races, call get_f1_historical_race_results once instead.' This directly tells an agent when to use this tool versus the alternative.

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

get_f1_historical_race_resultsHistorical race resultsA

Read-onlyIdempotent

Inspect

Get 2 to 8 complete historical Formula 1 race classifications in one consolidated request, with per-race sources and bounded partial failures. Use once for multi-race questions instead of repeating get_f1_historical_race_result.

ParametersJSON Schema

Name	Required	Description	Default
`races`	Yes	Two to eight historical races to retrieve in one request.

Output Schema

ParametersJSON Schema

Name	Required	Description
`races`	Yes
`unavailable`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint), and the description adds meaningful behavioral context: 'per-race sources' and 'bounded partial failures.' These traits are not present in the annotations and help an agent understand failure handling. The phrase 'bounded partial failures' is somewhat vague about exact behavior, but it still adds genuine transparency.

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?

Two sentences with zero waste: the first front-loads the key operational detail (2-8 races, consolidated, per-race sources, partial failures), and the second gives routing guidance. Every clause earns its place.

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

Completeness5/5

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

For a tool with one well-described parameter, a rich output schema, and safety annotations, the description covers the essential invocation context: when to use it, what it accepts, and the expected outcome characteristics. Nothing critical is missing for correct selection and invocation.

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 the schema fully documents the 'races' parameter including min/max items and item structure. The description reinforces the 2-8 range and consolidated nature but adds no new semantic detail beyond what the schema provides. Baseline 3 is appropriate since the schema carries the parameter documentation burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/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: 'Get 2 to 8 complete historical Formula 1 race classifications in one consolidated request.' It explicitly distinguishes itself from the singular sibling tool by naming 'get_f1_historical_race_result' and the multi-race vs. single-race distinction. This makes the tool's purpose immediately clear and differentiable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

The description gives explicit routing guidance: 'Use once for multi-race questions instead of repeating get_f1_historical_race_result.' This clearly states when to use this tool and identifies the alternative, so an agent can select it correctly without inferring usage from the schema.

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

get_f1_live_sessionLive F1 Session StatusA

Read-onlyIdempotent

Inspect

Get the latest explicitly timestamped status for the current or selected Formula 1 session. Returns unavailable rather than implying stale data is live.

ParametersJSON Schema

Name	Required	Description
`year`	No	Season to inspect. Defaults to the current UTC season.
`meetingKey`	No	Optional OpenF1 meeting key. Omit to discover the current live session.
`sessionKey`	No	Optional OpenF1 session key. Requires meetingKey when supplied.

Output Schema

ParametersJSON Schema

Name	Required	Description
`year`	Yes
`state`	Yes
`isLive`	Yes
`endDate`	Yes
`message`	Yes
`sourceUrl`	Yes
`startDate`	Yes
`meetingKey`	Yes
`observedAt`	Yes
`sessionKey`	Yes
`sessionKind`	Yes
`sessionName`	Yes
`dataTimestamp`	Yes
`dataDelaySeconds`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description does not need to restate those. It adds valuable behavioral context beyond annotations by disclosing that the data is 'explicitly timestamped' and that the tool returns 'unavailable' rather than presenting stale data as live. This is a useful nuance for agent trust.

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?

The description is exactly two sentences, front-loaded with the verb and resource, and every clause adds value—the timestamped nature and the unavailable-vs-stale behavior are both essential. There is no wasted or redundant wording.

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

Completeness5/5

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

With a rich output schema, complete annotations, and full parameter descriptions, the description only needs to add the key behavioral nuance, which it does. The tool's complexity is low, and the description covers the live-status semantic fully so an agent can invoke it correctly.

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%, and each parameter already has clear descriptions (year, meetingKey, sessionKey). The description's mention of 'selected session' does not add new parameter-level detail beyond what the schema provides. Baseline 3 is appropriate since the schema handles semantics well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and clearly identifies the resource (latest explicitly timestamped status for the current or selected Formula 1 session). It also distinguishes this tool from siblings by emphasizing 'explicitly timestamped' and 'unavailable rather than stale,' which differentiates it from historical result tools.

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?

The description clearly sets the context: it is for live session status, with the ability to select a session by season, meeting key, or session key. It does not explicitly name alternative tools or provide when-not-to-use exclusions, but the phrase 'rather than implying stale data is live' gives clear usage expectations for a live-status tool.

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

get_f1_next_eventNext F1 EventA

Read-onlyIdempotent

Inspect

Find the next Formula 1 session or race weekend from a UTC timestamp, including an event already in progress.

ParametersJSON Schema

Name	Required	Description	Default
`from`	No	UTC timestamp to search from. Defaults to the current time.
`year`	No	Season to search. Defaults to the season containing the search timestamp, then the following season if needed.
`level`	No	Return the next individual session or the next race weekend. Defaults to session.	session

Output Schema

ParametersJSON Schema

Name	Required	Description
`year`	Yes
`event`	Yes
`level`	Yes
`sourceUrl`	Yes
`canonicalUrl`	Yes
`searchedFrom`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the key behavior 'including an event already in progress', which provides context beyond annotations, but not extensive behavioral details.

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?

The description is a single, front-loaded sentence that efficiently captures the tool's purpose and key behavior with no unnecessary words.

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

Completeness5/5

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

Given the tool's simplicity, the presence of an output schema, and thorough annotations, the description fully covers the necessary context. No gaps are evident.

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 the baseline is 3. The description reinforces the purpose of the 'from' parameter but does not add meaning beyond what the schema already provides for each parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Find' and the resource 'next Formula 1 session or race weekend', including the nuance of an event in progress. This distinguishes it from sibling tools like get_f1_season_schedule or get_f1_race_weekend.

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?

The description implies usage for finding the next event based on a UTC timestamp, which is clear. However, it does not explicitly mention when not to use it or name alternative tools, but the context is sufficient for an AI agent.

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

get_f1_race_classificationF1 Race ClassificationA

Read-onlyIdempotent

Inspect

Get a published F1DB race, qualifying, or sprint classification by season and a friendly race selector, without requiring meeting or session keys.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	No	Race Calendar race slug, such as round-6-miami-grand-prix or miami-grand-prix.
`year`	Yes	Formula 1 season year.
`round`	No	Championship round number for the season.
`raceName`	No	Human-friendly Grand Prix or race name, matched case-insensitively.
`meetingKey`	No	OpenF1 meeting key for the race weekend.
`classification`	No	Published F1DB classification to return. Defaults to the Grand Prix race.	race

Output Schema

ParametersJSON Schema

Name	Required	Description
`year`	Yes
`round`	Yes
`source`	Yes
`results`	Yes
`raceName`	Yes
`available`	Yes
`sourceUrl`	Yes
`meetingKey`	Yes
`sessionKey`	Yes
`resultCount`	Yes
`canonicalUrl`	Yes
`classification`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable context beyond these: it specifies the data source (F1DB), that classifications are published, and that selectors are friendly rather than raw keys. This adds meaningful behavioral insight without any contradiction.

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?

The description is a single, well-structured sentence that front-loads the core purpose (get classification) and follows with essential qualifiers (published F1DB, race/qualifying/sprint, season, friendly selector, no keys). Every word adds meaning, and there is no redundancy.

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

Completeness5/5

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

Given the rich input schema (100% coverage), clear annotations, and the presence of an output schema, the description is adequately complete. It communicates the primary use case, the selector approach, and the data scope. The absence of explicit return-value details is acceptable because the output schema covers that.

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%, with detailed explanations for each parameter including the oneOf selector options and the classification enum. The description's phrase 'friendly race selector' provides a high-level unifying concept, but it does not add syntax or formatting details beyond what the schema already offers. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves published F1DB race, qualifying, or sprint classifications using a season and a friendly race selector, and explicitly notes it does not require meeting or session keys. This differentiates it from sibling tools like get_f1_session_results by specifying the data source and the selector style.

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?

The description clearly implies when to use it (when you need a published classification and have a season plus a human-friendly race selector) and also explains what it avoids (meeting/session keys). However, it does not explicitly exclude alternative tools or name them, so it lacks explicit when-not-to-use guidance.

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

get_f1_race_previewSpoiler-safe F1 Race PreviewA

Read-onlyIdempotent

Inspect

Get a structurally spoiler-safe race-weekend briefing containing schedule and venue context but no classifications, winners, podiums, or result fields.

ParametersJSON Schema

Name	Required	Description
`slug`	No	Race Calendar race slug, such as round-6-miami-grand-prix or miami-grand-prix.
`year`	Yes	Formula 1 season year.
`round`	No	Championship round number for the season.
`raceName`	No	Human-friendly Grand Prix or race name, matched case-insensitively.
`meetingKey`	No	OpenF1 meeting key for the race weekend.

Output Schema

ParametersJSON Schema

Name	Required	Description
`year`	Yes
`sourceUrl`	Yes
`raceWeekend`	Yes
`spoilerSafe`	Yes
`canonicalUrl`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

The description adds significant behavioral context beyond annotations: it clarifies the output contains no classifications, winners, or results, and confirms it is safe for spoiler-sensitive users. No contradiction with readOnlyHint and destructiveHint.

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?

A single sentence that effectively communicates the tool's purpose, contents, and exclusions. No wasted words; key information is front-loaded.

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

Completeness5/5

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

Given the presence of an output schema (not shown) and robust annotations, the description is fully adequate. It covers what the tool does, what it omits, and its safety characteristics without needing elaboration on return format.

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?

The schema already provides 100% coverage with clear descriptions for all parameters (year, meetingKey, round, raceName, slug) and a oneOf constraint. The tool description adds no further parameter-level insights, so baseline score is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: obtaining a spoiler-safe race-weekend briefing with schedule and venue context, explicitly excluding results. This uniquely distinguishes it from siblings like get_f1_historical_race_result and get_f1_session_results that return outcome data.

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?

The description implies usage for spoiler-free previews, but does not explicitly state when to avoid this tool or suggest alternatives for results. While the context is clear, direct guidelines would improve selection accuracy.

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

get_f1_race_weekendF1 Race WeekendA

Read-onlyIdempotent

Inspect

Get one public Formula 1 race weekend by season and exactly one friendly selector: meeting key, round, race name, or slug.

ParametersJSON Schema

Name	Required	Description
`slug`	No	Race Calendar race slug, such as round-6-miami-grand-prix or miami-grand-prix.
`year`	Yes	Formula 1 season year.
`round`	No	Championship round number for the season.
`raceName`	No	Human-friendly Grand Prix or race name, matched case-insensitively.
`meetingKey`	No	OpenF1 meeting key for the race weekend.

Output Schema

ParametersJSON Schema

Name	Required	Description
`year`	Yes
`sourceUrl`	Yes
`raceWeekend`	Yes
`canonicalUrl`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

The description aligns with annotations (readOnlyHint, idempotentHint, destructiveHint) and adds context by specifying 'public' race weekend and listing selector constraints. Annotations already cover the core behavioral traits, so the description provides limited additional transparency.

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?

The description is a single 20-word sentence that delivers all essential information upfront. There is no redundant or extraneous content; every word serves a purpose.

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

Completeness5/5

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

Given the presence of a complete output schema and annotations, the description sufficiently covers the tool's purpose, parameters, and unique constraints. It does not need to explain return values or further behavior.

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?

Input schema coverage is 100%, so the schema documents all parameters. The description adds the notion of 'friendly selector' and reinforces the oneOf constraint, but this is already implied by the schema structure. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Get' and identifies the resource 'one public Formula 1 race weekend'. It lists the exact selectors (meeting key, round, race name, or slug), distinguishing it from sibling tools that may list multiple or require different identifiers.

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?

The description clearly states the required inputs: a season and exactly one of the four selectors. This provides direct usage guidance. However, it does not explicitly mention when not to use this tool or suggest alternatives like get_f1_season_schedule or get_f1_race_preview.

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

get_f1_season_scheduleF1 Season ScheduleA

Read-onlyIdempotent

Inspect

Get the verified public Formula 1 schedule for a season, including UTC session times, freshness, results, and canonical links.

ParametersJSON Schema

Name	Required	Description	Default
`year`	Yes	Formula 1 season year.

Output Schema

ParametersJSON Schema

Name	Required	Description
`year`	Yes
`races`	Yes
`source`	Yes
`raceCount`	Yes
`sourceUrl`	Yes
`staleAfter`	Yes
`generatedAt`	Yes
`canonicalUrl`	Yes
`lastVerifiedAt`	Yes
`refreshIntervalSeconds`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare the tool as read-only and idempotent. The description adds valuable context about the data being 'verified public' and lists specific return elements (UTC times, freshness, results, links). This goes beyond annotations by describing content and quality.

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?

The description is a single, well-structured sentence that front-loads the core action and immediately specifies what the tool returns. Every word is necessary, and there is no redundancy or verbosity.

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 simple read tool with one parameter and an existing output schema, the description covers the key return aspects. However, given the sibling tools, a brief note on when to use this vs. others would make it more complete. The output schema compensates for missing return format details.

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% for the single 'year' parameter, with a clear description in the schema. The tool description does not add new parameter-level information beyond confirming the schedule is 'for a season,' which is baseline acceptable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get'), the resource ('verified public Formula 1 schedule for a season'), and the contents ('UTC session times, freshness, results, and canonical links'). It is distinct from sibling tools which focus on circuits, driver sessions, or specific events.

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 implies usage when the full season schedule is needed but provides no explicit guidance on when to use this tool instead of alternatives like get_f1_next_event or get_f1_race_weekend. With 14 siblings, more differentiation would improve score.

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

get_f1_session_resultsF1 Session ResultsB

Read-onlyIdempotent

Inspect

Get the published F1DB classification for one Formula 1 session by season, meeting key, and session key, with positions and available result details.

ParametersJSON Schema

Name	Required	Description
`year`	Yes	Formula 1 season year.
`meetingKey`	Yes	OpenF1 meeting key for the race weekend.
`sessionKey`	Yes	OpenF1 session key.

Output Schema

ParametersJSON Schema

Name	Required	Description
`year`	Yes
`source`	Yes
`results`	Yes
`sourceUrl`	Yes
`meetingKey`	Yes
`sessionKey`	Yes
`resultCount`	Yes
`canonicalUrl`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the context that results are 'published' (not live) and that it returns 'positions and available result details', which is useful but doesn't cover edge cases or response behavior.

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?

A single, focused sentence with no filler words. The key information is front-loaded in the first phrase.

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?

Given the high schema coverage and strong annotations, the description is largely sufficient for a simple read-only lookup tool. It defines the unique purpose and scoping ('one session', 'published') but lacks usage guidelines to differentiate from sibling tools.

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?

Input schema covers all three parameters (year, meetingKey, sessionKey) with descriptions, so the description adds no additional parameter semantics. It merely restates the keys in the same terms as 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 description uses the specific verb 'Get' and identifies the resource as 'published F1DB classification for one Formula 1 session', with key identifiers 'by season, meeting key, and session key'. It clearly communicates what the tool returns, though it does not explicitly contrast with sibling tools like get_f1_race_classification.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives such as get_f1_race_classification or get_f1_historical_race_result. The description only states what it does, not the scenarios for which it is appropriate.

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

get_f1_standingsF1 StandingsA

Read-onlyIdempotent

Inspect

Get the public Formula 1 driver and constructor standings for a season with canonical source links.

ParametersJSON Schema

Name	Required	Description	Default
`year`	Yes	Formula 1 season year.

Output Schema

ParametersJSON Schema

Name	Required	Description
`year`	Yes
`drivers`	Yes
`sourceUrl`	Yes
`sessionKey`	Yes
`canonicalUrl`	Yes
`constructors`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, fully covering safety and idempotency. The description adds minor behavioral context (canonical source links) but does not significantly expand beyond annotations. No contradiction present.

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?

The description is a single sentence of 14 words, conveying all essential information with zero redundancy. Every word earns its place—no wasted text.

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 simple tool with one parameter and an output schema (exists but not shown), the description covers the main goal. However, it could explicitly state that both driver and constructor standings are returned in a single call to avoid ambiguity. Still, it is largely 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% with the 'year' parameter already described in the input schema. The description does not add new meaning or constraints beyond what the schema provides, such as valid season ranges or date formats, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves both driver and constructor standings for a season, using a specific verb ('Get') and resource ('public Formula 1 driver and constructor standings'). It distinguishes from sibling tools like get_f1_session_results or get_f1_driver_session_summary, which have different scopes.

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 provides no explicit guidance on when to use this tool versus alternatives. Given the large set of sibling tools (e.g., get_f1_historical_race_result, get_f1_season_schedule), some contextual advice on when standings are appropriate would help agents, though the purpose is clear enough.

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

get_f1_starting_gridF1 Starting GridA

Read-onlyIdempotent

Inspect

Get the published F1DB starting grid for one Formula 1 session by season, meeting key, and session key; use session results for the final classification.

ParametersJSON Schema

Name	Required	Description
`year`	Yes	Formula 1 season year.
`meetingKey`	Yes	OpenF1 meeting key for the race weekend.
`sessionKey`	Yes	OpenF1 session key.

Output Schema

ParametersJSON Schema

Name	Required	Description
`year`	Yes
`source`	Yes
`sourceUrl`	Yes
`entryCount`	Yes
`meetingKey`	Yes
`sessionKey`	Yes
`canonicalUrl`	Yes
`startingGrid`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that this returns the 'published' starting grid for a single session and clarifies it is not the final classification, but it does not disclose additional behavioral details such as pagination or error conditions.

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?

The description is a single sentence, front-loaded with the verb 'Get', and every clause adds value. No redundant or filler text.

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

Completeness5/5

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

Given the output schema exists and the annotations cover safety, the description provides the essential information: what the tool returns, how to identify the session, and when to use an alternative. Enough for an agent to invoke correctly.

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?

The input schema provides 100% coverage with descriptions for each of the three required parameters (year, meetingKey, sessionKey). The description merely names these keys ('by season, meeting key, and session key') without adding any meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Get' and identifies the exact resource 'F1DB starting grid for one Formula 1 session', clearly distinguishing it from sibling tools like get_f1_session_results or get_f1_race_classification.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

The description explicitly advises to 'use session results for the final classification', providing an alternative for a different need. This tells the agent when not to use this tool (for final classifications) and points to the appropriate sibling.

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

get_f1_updatesRecent F1 ChangesA

Read-onlyIdempotent

Inspect

Get recent public schedule, standings, and result changes after an optional timestamp or cursor.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum changes to return. Defaults to 20 and never exceeds 50.
`since`	No	Only return changes after this UTC timestamp.
`cursor`	No	Opaque continuation cursor returned by an earlier updates request.

Output Schema

ParametersJSON Schema

Name	Required	Description
`items`	Yes
`since`	Yes
`nextCursor`	Yes
`generatedAt`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value by specifying the type of data returned (schedule, standings, results) and the optional timestamp/cursor for incremental updates. No contradictions.

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?

The description is a single, clear sentence with zero wasted words. Essential information is front-loaded.

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 simple read-only polling tool, the description covers the core functionality. An output schema exists, so return values are covered. Minor gap: could mention that cursor is for pagination, but schema already explains it.

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 the schema already documents all three parameters. The description mentions 'optional timestamp or cursor' which mirrors the schema. No additional semantic meaning beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and specifies the resource: 'recent public schedule, standings, and result changes' with a condition 'after an optional timestamp or cursor.' It effectively distinguishes itself from sibling tools which focus on specific races, sessions, or historical data.

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 implies usage for polling changes over time but does not explicitly mention when to use or avoid this tool relative to alternatives. No guidance on when not to use or how it differs from similar update tools.

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

search_f1_historySearch F1 HistoryA

Read-onlyIdempotent

Inspect

Search the Formula 1 history index for drivers, teams, circuits, and races with bounded, cursor-based results.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum results to return. Defaults to 10 and never exceeds 20.
`query`	Yes	Driver, team, circuit, or race text to find.
`types`	No	Optional unique entity types to include in the search.
`cursor`	No	Opaque continuation cursor returned by an earlier history search.

Output Schema

ParametersJSON Schema

Name	Required	Description
`items`	Yes
`query`	Yes
`types`	Yes
`nextCursor`	Yes
`generatedAt`	Yes
`sourceUpdatedAt`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that results are 'bounded, cursor-based', which provides some behavioral context beyond the annotations, but does not disclose details like default sorting or pagination limits beyond the schema.

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?

The description is a single, efficient sentence that covers the key aspects without unnecessary words. It is front-loaded with the main purpose and succinctly includes scope and result mechanism.

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?

Given the tool is a search with cursor-based pagination and four parameters, the description is fairly complete. The presence of an output schema reduces the need to describe return values. However, it lacks details on search behavior (e.g., substring matching, case sensitivity) and what the cursor represents, though these are minor.

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?

All parameters have schema descriptions (100% coverage), so the baseline is 3. The description does not add significant additional meaning beyond what the schema already provides; it references 'bounded' and 'cursor-based' but these are also reflected in the parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Search' and the resource 'Formula 1 history index', listing specific entity types (drivers, teams, circuits, races). This distinguishes it from sibling tools which are all 'get_*' or 'compare' operations.

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 implies usage for searching across multiple entity types and mentions 'bounded, cursor-based results', but does not explicitly state when to use it versus alternatives. No exclusions or when-not-to-use guidance is provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesSep 5, 2026

Changedget_f1_historical_race_result1 field changed

changedOutput schema / properties / results / items / properties

Previous value: -"[Object: undefined]"New value: +{
+  "carNumber": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  },
+  "constructor": {
+    "additionalProperties": false,
+    "properties": {
+      "id": {
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      },
+      "nationality": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "id",
+      "name",
+      "nationality"
+    ],
+    "type": "object"
+  },
+  "driver": {
+    "additionalProperties": false,
+    "properties": {
+      "code": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "id": {
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      },
+      "nationality": {
+        "type": "string"
+      },
+      "permanentNumber": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      }
+    },
+    "required": [
+      "id",
+      "name",
+      "code",
+      "nationality",
+      "permanentNumber"
+    ],
+    "type": "object"
+  },
+  "fastestLap": {
+    "anyOf": [
+      {
+        "additionalProperties": false,
+        "properties": {
+          "averageSpeedKph": {
+            "anyOf": [
+              {
+                "type": "number"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "lap": {
+            "anyOf": [
+              {
+                "maximum": 9007199254740991,
+                "minimum": -9007199254740991,
+                "type": "integer"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "rank": {
+            "anyOf": [
+              {
+                "maximum": 9007199254740991,
+                "minimum": -9007199254740991,
+                "type": "integer"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "time": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          }
+        },
+        "required": [
+          "lap",
+          "rank",
+          "time",
+          "averageSpeedKph"
+        ],
+        "type": "object"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  },
+  "grid": {
+    "anyOf": [
+      {
+        "maximum": 9007199254740991,
+        "minimum": -9007199254740991,
+        "type": "integer"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  },
+  "laps": {
+    "anyOf": [
+      {
+        "maximum": 9007199254740991,
+        "minimum": -9007199254740991,
+        "type": "integer"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  },
+  "points": {
+    "type": "number"
+  },
+  "position": {
+    "anyOf": [
+      {
+        "exclusiveMinimum": 0,
+        "maximum": 9007199254740991,
+        "type": "integer"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  },
+  "positionText": {
+    "type": "string"
+  },
+  "status": {
+    "type": "string"
+  },
+  "time": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  }
+}

Changedget_f1_historical_race_results1 field changed

changedOutput schema / properties / races / items / properties / results / items / properties

Previous value: -"[Object: undefined]"New value: +{
+  "carNumber": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  },
+  "constructor": {
+    "additionalProperties": false,
+    "properties": {
+      "id": {
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      },
+      "nationality": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "id",
+      "name",
+      "nationality"
+    ],
+    "type": "object"
+  },
+  "driver": {
+    "additionalProperties": false,
+    "properties": {
+      "code": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "id": {
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      },
+      "nationality": {
+        "type": "string"
+      },
+      "permanentNumber": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      }
+    },
+    "required": [
+      "id",
+      "name",
+      "code",
+      "nationality",
+      "permanentNumber"
+    ],
+    "type": "object"
+  },
+  "fastestLap": {
+    "anyOf": [
+      {
+        "additionalProperties": false,
+        "properties": {
+          "averageSpeedKph": {
+            "anyOf": [
+              {
+                "type": "number"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "lap": {
+            "anyOf": [
+              {
+                "maximum": 9007199254740991,
+                "minimum": -9007199254740991,
+                "type": "integer"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "rank": {
+            "anyOf": [
+              {
+                "maximum": 9007199254740991,
+                "minimum": -9007199254740991,
+                "type": "integer"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "time": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          }
+        },
+        "required": [
+          "lap",
+          "rank",
+          "time",
+          "averageSpeedKph"
+        ],
+        "type": "object"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  },
+  "grid": {
+    "anyOf": [
+      {
+        "maximum": 9007199254740991,
+        "minimum": -9007199254740991,
+        "type": "integer"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  },
+  "laps": {
+    "anyOf": [
+      {
+        "maximum": 9007199254740991,
+        "minimum": -9007199254740991,
+        "type": "integer"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  },
+  "points": {
+    "type": "number"
+  },
+  "position": {
+    "anyOf": [
+      {
+        "exclusiveMinimum": 0,
+        "maximum": 9007199254740991,
+        "type": "integer"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  },
+  "positionText": {
+    "type": "string"
+  },
+  "status": {
+    "type": "string"
+  },
+  "time": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  }
+}

5 tool updatesAug 5, 2026

Removedget_f1_driver_session_summary
Addedget_f1_race_classification
Removedget_f1_session_analysis

Changedget_f1_session_results4 fields changed

addedOutput schema / properties / results / items / properties / positionLabel

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

changedOutput schema / properties / results / items / required

Previous value: -[
-  "driverNumber",
-  "driverName",
-  "headshotUrl",
-  "constructorName",
-  "position",
-  "numberOfLaps",
-  "points",
-  "duration",
-  "gapToLeader",
-  "status"
-]New value: +[
+  "driverNumber",
+  "driverName",
+  "headshotUrl",
+  "constructorName",
+  "position",
+  "positionLabel",
+  "numberOfLaps",
+  "points",
+  "duration",
+  "gapToLeader",
+  "status"
+]

addedOutput schema / properties / source

Added value: +{
+  "const": "F1DB",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "year",
-  "meetingKey",
-  "sessionKey",
-  "canonicalUrl",
-  "sourceUrl",
-  "resultCount",
-  "results"
-]New value: +[
+  "year",
+  "meetingKey",
+  "sessionKey",
+  "canonicalUrl",
+  "sourceUrl",
+  "source",
+  "resultCount",
+  "results"
+]

Changedget_f1_starting_grid2 fields changed

addedOutput schema / properties / source

Added value: +{
+  "const": "F1DB",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "year",
-  "meetingKey",
-  "sessionKey",
-  "canonicalUrl",
-  "sourceUrl",
-  "entryCount",
-  "startingGrid"
-]New value: +[
+  "year",
+  "meetingKey",
+  "sessionKey",
+  "canonicalUrl",
+  "sourceUrl",
+  "source",
+  "entryCount",
+  "startingGrid"
+]

2 tool updatesAug 1, 2026
- Addedget_f1_historical_race_results
- Changedget_f1_live_session1 field changed
  - removedInput schema / dependentRequired
```
Removed value: -{
-  "sessionKey": [
-    "meetingKey"
-  ]
-}
```

15 tool updatesJul 31, 2026

Changedcompare_f1_competitors6 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / description

Added value: +"Compare two drivers or two constructors within one Formula 1 season."

addedInput schema / properties / left / description

Added value: +"First driver or constructor name to compare."

addedInput schema / properties / right / description

Added value: +"Second driver or constructor name to compare."

addedOutput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / description

Added value: +"Sourced same-season Formula 1 driver or constructor comparison with explicit methodology."

Changedget_f1_circuit4 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / description

Added value: +"Select one race weekend by season and exactly one of meetingKey, round, raceName, or slug."

addedOutput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / description

Added value: +"Formula 1 circuit identity, venue metadata, normalized geometry, and canonical links."

Changedget_f1_driver_session_summary4 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / description

Added value: +"Select one driver's summary within a Formula 1 session."

addedOutput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / description

Added value: +"One Formula 1 driver's lap, sector, speed, grid, position, and interval session summary."

Changedget_f1_historical_race_result4 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / description

Added value: +"Select a historical Formula 1 race by season and championship round."

addedOutput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / description

Added value: +"Complete historical Formula 1 race classification with driver, constructor, fastest-lap, and source details."

Changedget_f1_live_session4 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / description

Added value: +"Inspect the current Formula 1 session or select one by season, meeting key, and session key."

addedOutput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / description

Added value: +"Explicitly timestamped Formula 1 session state with data freshness and availability context."

Changedget_f1_next_event4 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / description

Added value: +"Select the next Formula 1 session or race weekend from a UTC point in time."

addedOutput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / description

Added value: +"Next live or upcoming Formula 1 session or race weekend from the requested UTC instant."

Changedget_f1_race_preview4 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / description

Added value: +"Select one race weekend by season and exactly one of meetingKey, round, raceName, or slug."

addedOutput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / description

Added value: +"Structurally spoiler-safe Formula 1 race-weekend schedule and venue preview with no result fields."

Changedget_f1_race_weekend4 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / description

Added value: +"Select one race weekend by season and exactly one of meetingKey, round, raceName, or slug."

addedOutput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / description

Added value: +"Resolved Formula 1 race-weekend context with sessions, available classifications, recap, and source links."

Changedget_f1_season_schedule4 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / description

Added value: +"Select one Formula 1 season."

addedOutput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / description

Added value: +"Verified Formula 1 season schedule with freshness metadata, canonical links, and race weekends."

Changedget_f1_session_analysis4 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / description

Added value: +"Select one typed analysis view for a Formula 1 session."

addedOutput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / description

Added value: +"Strictly typed Formula 1 session analysis with freshness, data availability, and source links."

Changedget_f1_session_results4 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / description

Added value: +"Select one Formula 1 session by season, meeting key, and session key."

addedOutput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / description

Added value: +"Published Formula 1 session classification with source and canonical links."

Changedget_f1_standings4 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / description

Added value: +"Select one Formula 1 season."

addedOutput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / description

Added value: +"Formula 1 driver and constructor standings with the source session and canonical links."

Changedget_f1_starting_grid4 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / description

Added value: +"Select one Formula 1 session by season, meeting key, and session key."

addedOutput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / description

Added value: +"Published Formula 1 session starting grid with source and canonical links."

Changedget_f1_updates6 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / description

Added value: +"Read a bounded page of recent public Formula 1 changes."

addedInput schema / properties / cursor / description

Added value: +"Opaque continuation cursor returned by an earlier updates request."

addedInput schema / properties / limit / description

Added value: +"Maximum changes to return. Defaults to 20 and never exceeds 50."

addedOutput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / description

Added value: +"Bounded cursor page of recent public Formula 1 schedule, standings, and result changes."

Changedsearch_f1_history7 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / description

Added value: +"Search the bounded Formula 1 history index."

addedInput schema / properties / cursor / description

Added value: +"Opaque continuation cursor returned by an earlier history search."

addedInput schema / properties / limit / description

Added value: +"Maximum results to return. Defaults to 10 and never exceeds 20."

addedInput schema / properties / types / description

Added value: +"Optional unique entity types to include in the search."

addedOutput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / description

Added value: +"Bounded cursor page of matching Formula 1 drivers, teams, circuits, and races."

13 tool updatesJul 24, 2026

Addedcompare_f1_competitors
Addedget_f1_circuit
Addedget_f1_driver_session_summary
Addedget_f1_historical_race_result
Addedget_f1_live_session
Addedget_f1_next_event
Addedget_f1_race_preview

Changedget_f1_race_weekend5 fields changed

addedInput schema / oneOf

Added value: +[
+  {
+    "required": [
+      "meetingKey"
+    ]
+  },
+  {
+    "required": [
+      "round"
+    ]
+  },
+  {
+    "required": [
+      "raceName"
+    ]
+  },
+  {
+    "required": [
+      "slug"
+    ]
+  }
+]

addedInput schema / properties / raceName

Added value: +{
+  "description": "Human-friendly Grand Prix or race name, matched case-insensitively.",
+  "maxLength": 120,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / round

Added value: +{
+  "description": "Championship round number for the season.",
+  "maximum": 99,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / slug

Added value: +{
+  "description": "Race Calendar race slug, such as round-6-miami-grand-prix or miami-grand-prix.",
+  "maxLength": 160,
+  "minLength": 1,
+  "pattern": "^[a-z0-9]+(?:-[a-z0-9]+)*$",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "year",
-  "meetingKey"
-]New value: +[
+  "year"
+]

Addedget_f1_session_analysis
Addedget_f1_session_results
Addedget_f1_starting_grid
Addedget_f1_updates
Addedsearch_f1_history

3 tool updatesJul 22, 2026

Changedget_f1_race_weekend6 fields changed

addedInput schema / properties / meetingKey / description

Added value: +"OpenF1 meeting key for the race weekend."

addedInput schema / properties / meetingKey / exclusiveMinimum
```
Added value: +0
```
addedInput schema / properties / meetingKey / maximum
```
Added value: +9007199254740991
```
removedInput schema / properties / meetingKey / minimum
```
Removed value: -1
```
addedInput schema / properties / year / description
```
Added value: +"Formula 1 season year."
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "canonicalUrl": {
+      "format": "uri",
+      "type": "string"
+    },
+    "raceWeekend": {
+      "additionalProperties": false,
+      "properties": {
+        "circuit": {
+          "type": "string"
+        },
+        "country": {
+          "type": "string"
+        },
+        "countryCode": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "endDate": {
+          "type": "string"
+        },
+        "latestResultKind": {
+          "anyOf": [
+            {
+              "enum": [
+                "sprint",
+                "qualifying",
+                "race"
+              ],
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "location": {
+          "type": "string"
+        },
+        "meetingKey": {
+          "exclusiveMinimum": 0,
+          "maximum": 9007199254740991,
+          "type": "integer"
+        },
+        "name": {
+          "type": "string"
+        },
+        "officialName": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "recap": {
+          "anyOf": [
+            {
+              "additionalProperties": false,
+              "properties": {
+                "detail": {
+                  "anyOf": [
+                    {
+                      "type": "string"
+                    },
+                    {
+                      "type": "null"
+                    }
+                  ]
+                },
+                "summary": {
+                  "type": "string"
+                }
+              },
+              "required": [
+                "summary",
+                "detail"
+              ],
+              "type": "object"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "resultHighlights": {
+          "items": {
+            "additionalProperties": false,
+            "properties": {
+              "constructorName": {
+                "anyOf": [
+                  {
+                    "type": "string"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ]
+              },
+              "driverName": {
+                "anyOf": [
+                  {
+                    "type": "string"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ]
+              },
+              "position": {
+                "exclusiveMinimum": 0,
+                "maximum": 9007199254740991,
+                "type": "integer"
+              }
+            },
+            "required": [
+              "position",
+              "driverName",
+              "constructorName"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "resultStatus": {
+          "enum": [
+            "notStarted",
+            "pending",
+            "available"
+          ],
+          "type": "string"
+        },
+        "resultSummary": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "round": {
+          "exclusiveMinimum": 0,
+          "maximum": 9007199254740991,
+          "type": "integer"
+        },
+        "sessions": {
+          "items": {
+            "additionalProperties": false,
+            "properties": {
+              "endDate": {
+                "type": "string"
+              },
+              "id": {
+                "maximum": 9007199254740991,
+                "minimum": -9007199254740991,
+                "type": "integer"
+              },
+              "kind": {
+                "enum": [
+                  "practice",
+                  "sprintQualifying",
+                  "sprint",
+                  "qualifying",
+                  "race",
+                  "other"
+                ],
+                "type": "string"
+              },
+              "name": {
+                "type": "string"
+              },
+              "startDate": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "id",
+              "name",
+              "kind",
+              "startDate",
+              "endDate"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "startDate": {
+          "type": "string"
+        },
+        "status": {
+          "enum": [
+            "scheduled",
+            "cancelled"
+          ],
+          "type": "string"
+        },
+        "statusNote": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "winner": {
+          "anyOf": [
+            {
+              "additionalProperties": false,
+              "properties": {
+                "constructorName": {
+                  "anyOf": [
+                    {
+                      "type": "string"
+                    },
+                    {
+                      "type": "null"
+                    }
+                  ]
+                },
+                "driverName": {
+                  "type": "string"
+                }
+              },
+              "required": [
+                "driverName",
+                "constructorName"
+              ],
+              "type": "object"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        }
+      },
+      "required": [
+        "meetingKey",
+        "round",
+        "name",
+        "circuit",
+        "location",
+        "country",
+        "countryCode",
+        "startDate",
+        "endDate",
+        "status",
+        "statusNote",
+        "resultStatus",
+        "winner",
+        "resultSummary",
+        "sessions",
+        "officialName",
+        "latestResultKind",
+        "resultHighlights",
+        "recap"
+      ],
+      "type": "object"
+    },
+    "sourceUrl": {
+      "format": "uri",
+      "type": "string"
+    },
+    "year": {
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "year",
+    "canonicalUrl",
+    "sourceUrl",
+    "raceWeekend"
+  ],
+  "type": "object"
+}

Changedget_f1_season_schedule2 fields changed

addedInput schema / properties / year / description
```
Added value: +"Formula 1 season year."
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "canonicalUrl": {
+      "format": "uri",
+      "type": "string"
+    },
+    "generatedAt": {
+      "type": "string"
+    },
+    "lastVerifiedAt": {
+      "type": "string"
+    },
+    "raceCount": {
+      "maximum": 9007199254740991,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "races": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "circuit": {
+            "type": "string"
+          },
+          "country": {
+            "type": "string"
+          },
+          "countryCode": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "endDate": {
+            "type": "string"
+          },
+          "location": {
+            "type": "string"
+          },
+          "meetingKey": {
+            "exclusiveMinimum": 0,
+            "maximum": 9007199254740991,
+            "type": "integer"
+          },
+          "name": {
+            "type": "string"
+          },
+          "resultStatus": {
+            "enum": [
+              "notStarted",
+              "pending",
+              "available"
+            ],
+            "type": "string"
+          },
+          "resultSummary": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "round": {
+            "exclusiveMinimum": 0,
+            "maximum": 9007199254740991,
+            "type": "integer"
+          },
+          "sessions": {
+            "items": {
+              "additionalProperties": false,
+              "properties": {
+                "endDate": {
+                  "type": "string"
+                },
+                "id": {
+                  "maximum": 9007199254740991,
+                  "minimum": -9007199254740991,
+                  "type": "integer"
+                },
+                "kind": {
+                  "enum": [
+                    "practice",
+                    "sprintQualifying",
+                    "sprint",
+                    "qualifying",
+                    "race",
+                    "other"
+                  ],
+                  "type": "string"
+                },
+                "name": {
+                  "type": "string"
+                },
+                "startDate": {
+                  "type": "string"
+                }
+              },
+              "required": [
+                "id",
+                "name",
+                "kind",
+                "startDate",
+                "endDate"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "startDate": {
+            "type": "string"
+          },
+          "status": {
+            "enum": [
+              "scheduled",
+              "cancelled"
+            ],
+            "type": "string"
+          },
+          "statusNote": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "winner": {
+            "anyOf": [
+              {
+                "additionalProperties": false,
+                "properties": {
+                  "constructorName": {
+                    "anyOf": [
+                      {
+                        "type": "string"
+                      },
+                      {
+                        "type": "null"
+                      }
+                    ]
+                  },
+                  "driverName": {
+                    "type": "string"
+                  }
+                },
+                "required": [
+                  "driverName",
+                  "constructorName"
+                ],
+                "type": "object"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          }
+        },
+        "required": [
+          "meetingKey",
+          "round",
+          "name",
+          "circuit",
+          "location",
+          "country",
+          "countryCode",
+          "startDate",
+          "endDate",
+          "status",
+          "statusNote",
+          "resultStatus",
+          "winner",
+          "resultSummary",
+          "sessions"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "refreshIntervalSeconds": {
+      "maximum": 9007199254740991,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "source": {
+      "const": "OpenF1",
+      "type": "string"
+    },
+    "sourceUrl": {
+      "format": "uri",
+      "type": "string"
+    },
+    "staleAfter": {
+      "type": "string"
+    },
+    "year": {
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "year",
+    "source",
+    "generatedAt",
+    "lastVerifiedAt",
+    "staleAfter",
+    "refreshIntervalSeconds",
+    "canonicalUrl",
+    "sourceUrl",
+    "raceCount",
+    "races"
+  ],
+  "type": "object"
+}

Changedget_f1_standings2 fields changed

addedInput schema / properties / year / description
```
Added value: +"Formula 1 season year."
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "canonicalUrl": {
+      "format": "uri",
+      "type": "string"
+    },
+    "constructors": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "colour": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "constructorName": {
+            "type": "string"
+          },
+          "logoUrl": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "points": {
+            "minimum": 0,
+            "type": "number"
+          },
+          "position": {
+            "exclusiveMinimum": 0,
+            "maximum": 9007199254740991,
+            "type": "integer"
+          }
+        },
+        "required": [
+          "position",
+          "points",
+          "constructorName",
+          "colour",
+          "logoUrl"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "drivers": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "driverName": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "driverNumber": {
+            "exclusiveMinimum": 0,
+            "maximum": 9007199254740991,
+            "type": "integer"
+          },
+          "headshotUrl": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "points": {
+            "minimum": 0,
+            "type": "number"
+          },
+          "position": {
+            "exclusiveMinimum": 0,
+            "maximum": 9007199254740991,
+            "type": "integer"
+          }
+        },
+        "required": [
+          "position",
+          "points",
+          "driverNumber",
+          "driverName",
+          "headshotUrl"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "sessionKey": {
+      "exclusiveMinimum": 0,
+      "maximum": 9007199254740991,
+      "type": "integer"
+    },
+    "sourceUrl": {
+      "format": "uri",
+      "type": "string"
+    },
+    "year": {
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "year",
+    "sessionKey",
+    "canonicalUrl",
+    "sourceUrl",
+    "drivers",
+    "constructors"
+  ],
+  "type": "object"
+}

3 tool updatesJul 22, 2026
- First observedget_f1_race_weekend
- First observedget_f1_season_schedule
- First observedget_f1_standings

Related MCP Connectors

F1LapsOAuth
com.f1laps
Read-only F1 game laps, telemetry, setups, leaderboard benchmarks, and progress.
Games & Gamification Sports
1
Openf1 A
io.github.pipeworx-io
OpenF1 MCP — real-time & historical Formula 1 data.
Sports Open Data
2
Fmind AI Security Architect Portfolio A
io.github.fmind
Read-only portfolio tools, resources, and prompts for Fmind.
Documentation Access
91
One AI Guide A
com.oneaiguide
Read-only approved AI tools, public stacks, guides, and evidence-aware comparisons.
AI & Machine Learning Documentation Access
71

Related MCP Servers

f1-mcp-server
Sports Data Visualization
drivenrajat
A
license
Not graded
quality
C
maintenance
Provides comprehensive Formula 1 data and analytics for Claude Desktop, including race results, telemetry, standings, and strategy insights through 36+ tools.
Updated 8 months ago (2026-01-18 21:20 UTC)
1
MIT
mcp-f1analisys
Sports Research & Data
Maxbleu
A
license
Not graded
quality
D
maintenance
Enables Formula 1 data analysis through natural language, providing tools like track dominance, lap time analysis, and team performance comparisons.
Updated 10 months ago (2025-12-03 11:19 UTC)
Apache 2.0
OpenF1 MCP Server
commitNotFound
A
license
Not graded
quality
D
maintenance
Enables AI assistants to query real-time and historical Formula 1 data through the OpenF1 API, providing tools for driver info, lap times, telemetry, race events, and more.
Updated 10 months ago (2025-11-10 18:17 UTC)
MIT
F1 MCP Server
Sports Search
Kevin29Johnson
F
license
Not graded
quality
D
maintenance
A real-time Formula 1 analytics server that lets you ask natural language questions about races, lap times, tyre strategies, pit stops, and more using live data from the OpenF1 API.
Updated 3 months ago (2026-06-22 03:31 UTC)
-

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?