f1verse MCP Server

Overview Schema Source Related Servers Discussions Admin

The circuit measured from the cars that drove it.

f1_circuit_survey

Read-onlyIdempotent

Retrieve telemetry-measured circuit data for a Formula 1 season round: elevation and gradient profile, overtaking zones, full-throttle share, braking points, track width, camber, and DRS zones.

Instructions

The circuit measured from the cars that drove it. What no public circuit map carries, measured from telemetry instead: the height profile with gradients and total climb; where overtakes actually happen, clustered into zones and merged across the timing line; how much of the lap is spent at full throttle and where the braking zones are, with entry and minimum speeds; the width of road the field used and the camber of it. DRS zones are included for seasons that had DRS and reported as a regulation change, not a weather excuse, for those that do not. Every figure names the laps and drivers behind it and declines rather than guesses when the samples cannot support it. Use for track explainers and previews that need real numbers, not an outline.

Tool call template

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

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "year": "<year>",
      "round": "<round>"
    },
    "name": "f1_circuit_survey"
  }
}

Input Schema

Name	Required	Description	Default
`year`	Yes	Season year, e.g. 2026. Race data 2023+.
`round`	Yes	Round number within the season, 1-based.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.15.0Nov 9, 2026

addedInput schema / properties / round / minimum
```
Added value: +1
```
addedInput schema / properties / year / minimum
```
Added value: +1950
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "result": {
+      "type": "object"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "type": "object"
+}

First observedv0.1.0Nov 6, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive, and the description adds real behavioral context on top: every figure is attributed to laps and drivers, and the tool 'declines rather than guesses' when samples are thin — an important expectation for a model that might otherwise treat absence as error. It also discloses how DRS is handled differentially across seasons. Losing a point only because the declining behavior isn't given a concrete shape (what an agent should do when it bites).

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 content is front-loaded into one long catalogue sentence that is genuinely informative, but the opening restates the title verbatim and the prose leans ornamental ('the camber of it', 'not a weather excuse'), which costs tokens without adding selection signal. A tighter enumeration of returned measures would serve an agent better.

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

Completeness4/5

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

With an output schema present and annotations covering the safety profile, the description's remaining job is to convey scope and provenance, which it does well. What an agent still cannot tell is how this differs from f1_circuit_profile or f1_circuit_history — the one completeness gap that matters given three circuit-named siblings.

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 only year and round, both already documented with ranges and the 'Race data 2023+' caveat, so the schema carries the load. The description adds no meaning beyond it — nothing about how a historical season with sparse telemetry is handled at the parameter level.

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 specifies the resource precisely: a telemetry-derived circuit survey covering elevation/gradients, overtake zones, full-throttle share, braking zones, width and camber, with a clear stance on DRS zones. An agent knows the content immediately. It stops short of a 5 because it never names the sibling it displaces — the closing 'not an outline' gestures at f1_circuit_profile without saying so, leaving the agent to infer the distinction.

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?

'Use for track explainers and previews that need real numbers, not an outline' gives a use context, but only for the positive case. There is no exclusion, no 'use f1_circuit_profile for X instead', and no prerequisite about data availability beyond the schema's terse 'Race data 2023+' note.

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