Skip to main content
Glama
f1verse MCP Server

f1verse MCP Server

by jinsim

A race from 1996-2022, before the live-timing feeds.

f1_archive_race
Read-onlyIdempotent

Retrieve Formula 1 race results, lap-by-lap running order, lead changes, laps led, and post-2011 pit stops for 1996–2022 seasons, with a coverage block clarifying available fields.

Instructions

A race from 1996-2022, before the live-timing feeds. Results, lap-by-lap running order, lead changes and laps led for the seasons the modern feeds do not cover. Pit stops are included from 2011. The reply carries a 'coverage' block naming exactly what that era does and does not hold, so an absent field is never mistaken for a zero. Use f1_race_story for 2023 onward — it knows strictly more.

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_archive_race"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearYesSeason year, e.g. 2026. Race data 2023+.
roundYesRound number within the season, 1-based.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.15.0
    • 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"
      +}
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), so the bar is lower, and the description still adds real behavioral context: partial coverage surfaced via a 'coverage' block and the warning that an absent field is not a zero. The only gap is that it doesn't say how the coverage block is shaped, but output schema likely carries that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The era constraint and payload list are front-loaded, and the sibling routing comes last where a reader will look for it. The opening sentence duplicates the title verbatim, a minor waste, but the remaining sentences all carry 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?

With an output schema present, return values needn't be explained, yet the description still sketches the payload, and it covers era limits, coverage semantics, and sibling routing. Completeness is slightly undercut by the internal tension between the stated 1996-2022 scope and the schema's 1950 minimum plus 'Race data 2023+' note.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both year and round are already documented, making 3 the baseline. The description adds the era context (1996-2022) that constrains valid years, though it does not reconcile this with the schema's minimum of 1950 and the 'Race data 2023+' note.

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 names a specific resource (a race) with an explicit era bound (1996-2022) and enumerates the payload: results, lap-by-lap running order, lead changes, laps led, and pit stops from 2011. It also distinguishes itself from the sibling f1_race_story by era, so an agent can choose between them without opening either schema.

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?

It states the exact routing rule: use f1_race_story for 2023 onward, 'it knows strictly more.' That is an explicit when-to-use and when-not-to-use with a named alternative, leaving nothing to inference.

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