f1verse MCP Server

Overview Schema Source Related Servers Discussions Admin

Championship standings after the latest completed round.

f1_standings

Read-onlyIdempotent

Retrieve Formula 1 drivers' or constructors' championship standings by season, including points and wins as of the most recently scored round.

Instructions

Championship standings after the latest completed round. Drivers' or constructors' championship table, with points and wins, as of the most recent round that has been scored.

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>"
    },
    "name": "f1_standings"
  }
}

Input Schema

Name	Required	Description	Default
`kind`	No	Which championship table to return.	driver
`year`	Yes	Season year, e.g. 2026. Race data 2023+.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.15.0Nov 9, 2026

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

B3.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description's contribution is the snapshot semantics — results are as of the last scored round, not live or projected — which is genuinely useful context. It stops short of noting data coverage limits or how unfinished rounds are treated.

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?

Front-loaded and short, but the second sentence largely restates the first: 'after the latest completed round' is repeated as 'as of the most recent round that has been scored.' That redundancy consumes roughly half the text without adding new information.

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

Completeness3/5

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

An output schema exists, so return values need not be explained, and the two parameters are fully documented in the schema. What is missing is orientation within a 25-tool sibling set — no signal on when this beats f1_season_status or f1_title_race, and no note that race data only covers 2023+ despite the year minimum of 1950.

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 both parameters are already documented, including the driver/constructor enum and the year bounds. The description echoes the kind choice ('Drivers' or constructors' championship table') without adding format, default behavior, or validity detail beyond the schema. 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?

States a specific resource (drivers' or constructors' championship table) and what it contains (points and wins), plus the temporal anchor (latest scored round). It is clear on its own, but it never distinguishes itself from adjacent siblings such as f1_season_status, f1_title_race, or f1_closest_titles, all of which plausibly return overlapping standings-adjacent 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?

Usage is only implied: an agent can infer this is the tool for a season points table, and the 'most recent round that has been scored' phrasing signals it is a current snapshot rather than a historical lookup. There is no explicit when-to-use or when-not-to-use guidance, and no routing to alternatives for historical or projected standings.

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