Skip to main content
Glama

Race Calendar F1

by app.racecalendar
OverviewDiscussionsAdmin

Next F1 Event

get_f1_next_event
Read-onlyIdempotent

Find the next Formula 1 session or race weekend from a UTC timestamp, including an event already in progress.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fromNoUTC timestamp to search from. Defaults to the current time.
yearNoSeason to search. Defaults to the season containing the search timestamp, then the following season if needed.
levelNoReturn the next individual session or the next race weekend. Defaults to session.session

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
yearYes
eventYes
levelYes
sourceUrlYes
canonicalUrlYes
searchedFromYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / from / pattern
      Previous value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"New value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$"
  2. Changed4 schema fields changed
    • addedInput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / description
      Added value: +"Select the next Formula 1 session or race weekend from a UTC point in time."
    • addedOutput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
    • addedOutput schema / description
      Added value: +"Next live or upcoming Formula 1 session or race weekend from the requested UTC instant."
  3. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds the useful boundary trait that an ongoing event counts as the next result and that the lookup is anchored to a UTC instant.

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?

A single front-loaded sentence with no filler. Every element — resource, instrument, UTC anchor, inclusivity — carries meaning.

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, full parameter documentation, and safety annotations, the definition contains everything needed to invoke the tool. It is missing only explicit guidance about sibling alternatives, reflected in usage_guidelines.

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 documentation covers 100% of the parameters, so the baseline is 3. The description's mention of 'session or race weekend' lightly echoes the level enum but adds no semantic detail beyond the schema.

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 uses the specific verb 'Find' on a well-defined resource ('next Formula 1 session or race weekend') and anchors it to a UTC timestamp. 'Next' and 'including an event already in progress' separate it from schedule, live, and historical sibling tools without needing the schema.

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?

The description conveys a clear temporal use case (future event from a UTC timestamp), so an agent can infer when to call it. However, it never names alternatives or says when not to use this tool, leaving sibling routing to inference.

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

All Race Calendar F1 toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources