Skip to main content
Glama

Race Calendar F1

Spoiler-safe F1 Race Preview

get_f1_race_preview
Read-onlyIdempotent

Get a structurally spoiler-safe race-weekend briefing containing schedule and venue context but no classifications, winners, podiums, or result fields.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugNoRace Calendar race slug, such as round-6-miami-grand-prix or miami-grand-prix.
yearYesFormula 1 season year.
roundNoChampionship round number for the season.
raceNameNoHuman-friendly Grand Prix or race name, matched case-insensitively.
meetingKeyNoOpenF1 meeting key for the race weekend.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
yearYes
sourceUrlYes
raceWeekendYes
spoilerSafeYes
canonicalUrlYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • removedOutput schema / properties / raceWeekend / properties / countryCode / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / raceWeekend / properties / countryCode / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / raceWeekend / properties / officialName / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / raceWeekend / properties / officialName / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / raceWeekend / properties / statusNote / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / raceWeekend / properties / statusNote / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  2. Changed4 schema fields changed
    • addedInput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / description
      Added value: +"Select one race weekend by season and exactly one of meetingKey, round, raceName, or slug."
    • addedOutput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
    • addedOutput schema / description
      Added value: +"Structurally spoiler-safe Formula 1 race-weekend schedule and venue preview with no result fields."
  3. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds critical behavioral context beyond the annotations: it guarantees the output is structurally free of results, winners, podiums, and classifications. This is a non-obvious behavioral guarantee that prevents the agent from calling this tool when results are requested.

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

Conciseness5/5

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

The description is a single, well-structured sentence that front-loads the key differentiator ('structurally spoiler-safe') and then specifies the content (schedule and venue context) and the explicit exclusions. Every word earns its place with no redundancy.

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

Completeness5/5

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

For a read-only, idempotent briefing tool with no nested objects and a rich output schema (though not shown here), the description fully captures the tool's scope and safety guarantees. There is no missing information an agent would need to invoke it correctly—parameter details are in the schema, and the behavioral guarantee is explicit.

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?

The input schema has 100% description coverage, so all five parameters are individually documented with types, formats, and constraints. The description adds no additional parameter semantics, which is acceptable given the schema's thoroughness. Baseline of 3 is appropriate.

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 states a specific action ('Get') and resource ('race-weekend briefing') with a distinctive attribute ('structurally spoiler-safe'). It clearly differentiates from sibling result-heavy tools like get_f1_race_classification and get_f1_historical_race_result by explicitly excluding classifications, winners, podiums, or result fields.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies when to use this tool: when the user needs schedule and venue context without spoilers. It doesn't explicitly name alternative tools or state when not to use it, but the exclusion of results makes the usage context clear. Sibling names and the absence of results are enough for a competent agent to route correctly.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources