Skip to main content
Glama
Sign In
f1verse MCP Server

f1verse MCP Server

by jinsim
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Persistent retrospective pace shifts within clean stints.

f1_pace_changes
Read-onlyIdempotent

Detect persistent pace changes across adjacent clean-lap windows in a Formula 1 race, removing trend and treating excluded laps as boundaries.

Instructions

Persistent retrospective pace shifts within clean stints. Adjacent clean-lap windows, with trend removed, detect pace changes. Excluded laps are boundaries; the method does not identify a cause.

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

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. Addedv0.15.0

TDQS

C2.8/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 covered. The description adds genuine analytic context beyond that: laps excluded by the method become window boundaries, and the tool does not attribute a cause to a detected shift. It still leaves the definition of a 'clean stint' and the meaning of 'trend removed' unexplained.

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 definition is short and front-loaded, but the opening sentence duplicates the title verbatim, so the highest-value position is spent on repetition. The remaining two sentences are dense and jargon-heavy ('adjacent clean-lap windows', 'with trend removed') without unpacking the terms.

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 both parameters are fully documented in the schema. What is missing is conceptual scaffolding for a specialized analysis tool: an agent cannot tell how a 'persistent pace shift' is represented or how this differs from the sibling turning-point and tyre-wear 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?

Schema description coverage is 100% with two integer parameters, so the schema already carries the semantics of year and round, including the 2023+ data caveat. The description adds nothing about either parameter, so the baseline of 3 applies.

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

Purpose3/5

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

The description names a specific analysis (detecting pace changes from adjacent clean-lap windows with trend removed), which goes beyond a tautology. However, the phrasing 'Persistent retrospective pace shifts within clean stints' largely restates the title in domain jargon, and it never distinguishes this from plausible siblings such as f1_turning_points or f1_tyre_wear, which an agent could easily confuse with it.

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 when-to-use guidance at all: no statement of which questions this answers, no prerequisites, and no named alternative. The only usage-adjacent content is the caveat that excluded laps act as boundaries, which describes the method rather than when to select the tool.

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

Deploy Server

Other Tools