Skip to main content
Glama
lacausecrypto

Sports Hub MCP Server

by lacausecrypto
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

f1: Get qualifying

f1_get_qualifying
Read-onlyIdempotent

Retrieve Formula 1 qualifying results, including Q1, Q2, and Q3 times for each driver in a chosen season and round.

Instructions

Get Formula 1 qualifying results. Returns Q1/Q2/Q3 times for drivers in a specific qualifying session.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of results to return (default 30, max 1000)
roundNoRound number within the season
fieldsNoKeys to keep (comma-separated).
offsetNoNumber of results to skip for pagination
seasonNoSeason year (e.g. "2024") or "current" (default: "current")

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.4.1
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • addedInput schema / properties / fields
      Added value: +{
+  "description": "Keys to keep (comma-separated).",
+  "type": "string"
+}
    • removedInput schema / properties / offset / maximum
      Removed value: -9007199254740991
  2. Changed2 schema fields changedv1.3.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / offset / maximum
      Added value: +9007199254740991
  3. First observedv1.2.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds that the return contains Q1/Q2/Q3 driver times, which is useful context, but says nothing about pagination, the 'current' season default, or behavior on missing rounds.

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?

Two short sentences, front-loaded with the core action and followed by the return contents. Nothing is redundant or padded.

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 no output schema, the description does double duty by naming the returned Q1/Q2/Q3 times, which is the key return-value information. For a 5-parameter, all-optional tool with full schema coverage this is nearly sufficient, though it omits how session/round scoping interacts with the default 'current' season.

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 every parameter (limit, round, fields, offset, season) is already documented in the schema. The description adds no parameter-level detail, such as season/round format requirements, so the 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 verb and resource ('Get Formula 1 qualifying results') and clarifies the payload ('Q1/Q2/Q3 times for drivers in a specific qualifying session'). This separates it from race/sprint result siblings, but it never explicitly distinguishes itself from f1_get_driver_results or f1_get_lap_times, which an agent could plausibly confuse with qualifying data.

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?

No when-to-use, when-not-to-use, or alternative tool is named. The description only implies the domain (session qualifying), leaving the agent to infer whether f1_get_race_results, f1_get_sprint, or f1_get_driver_results should be used instead.

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