mcp-f1

Get Race Replay View

get_race_replay_view

Generate an animated bar-chart race replay showing car positions, tyre compounds, and sector times. Use it to visualize F1 race progress.

Instructions

Replay a race as an animated position chart (bar-chart-race style).

MCP App (task 06): in hosts supporting the MCP Apps extension, renders cars stacked by official position with a checkered treadmill paced by the leader (a new lap opens when the leader crosses), tyre compound badges (red S / yellow M / white H), per-sector times with broadcast colors recomputed at the displayed instant (one purple per sector, green = personal best, yellow = slower), the lap time as MM:SS:mmm, PIT badges, a centered Safety Car / VSC / race-suspended banner, and a header with circuit, local start time and track conditions. Retired cars show a permanent OUT or DNS tag and drop gap, sectors and lap time. In other hosts the same payload is returned as JSON text.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`session_key`	No	int \| str — optional, positive int or 'latest'. Defaults to 'latest' when omitted. RACE session identifier; use get_sessions with session_type='Race' to discover it. During a live race, 'latest' yields a snapshot of the data available so far.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 29, 2026

TDQS

A3.6/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: host-dependent rendering (MCP Apps extension vs. JSON fallback), live snapshot handling, and how retired/DNS cars, safety-car banners, and pit badges are treated. It does not mention cost, latency, or that the payload is large, but the host-dependent output behavior is genuinely useful context 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in one clean sentence, but the following run-on sentence enumerates UI minutiae (tyre badge colors, per-sector color rules, MM:SS:mmm formatting) that do not help an agent select or invoke the tool. Roughly half the text is rendering detail rather than invocation-relevant information.

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?

An output schema exists, so return-value explanation is not required, and the description instead covers the host-dependent rendering path and fallback, which the schema cannot express. Combined with the richly documented parameter, an agent has enough to call 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 the single session_key parameter already documents the int|'latest' semantics, default, and live-snapshot behavior. The description adds nothing about the parameter, so the baseline 3 applies.

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

Purpose4/5

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

The opening sentence names a specific verb (replay) and resource (a race) and states the output form (animated bar-chart-race position chart), which is distinct from the raw-data siblings like get_positions or get_laps. It stops short of explicitly naming which sibling to use instead, so an agent must infer the distinction from the word 'chart'.

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 is only implied: the description suggests this is for visual playback rather than data retrieval, but it never states when to prefer it over get_positions/get_laps or that the raw data is unavailable here. No exclusions or prerequisites are given, leaving the agent to guess the selection rule.

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