Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

formula1_race_hub

Fetch a Formula 1 race weekend's official event details, UTC session schedule, circuit facts, and top-five results by event slug.

Instructions

One Formula 1 race weekend hub. Returns one race weekend's hub: the event's official name, description, host location and weekend bounds from the page's schema.org structured data, the published session schedule with UTC start and end times, the circuit facts (length, first Grand Prix, lap count) and, once the race has run, the top-five result table. The event slug is the race-hub slug from formula1-race-calendar and is a different slug space from the results-archive slug.

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": {
      "event_slug": "<event_slug>"
    },
    "name": "formula1_race_hub"
  }
}

Input Schema

NameRequiredDescriptionDefault
seasonNoFour-digit championship year, 2018 through next season; defaults to the current season example(2026)
event_slugYesRace-hub event slug from formula1-race-calendar, such as brazil or united-arab-emirates example(brazil)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are supplied, so the description carries the full burden, and it discloses genuinely useful behavior: the data origins are schema.org structured data from the page, and the result table is only present 'once the race has run,' warning the agent about conditionally-missing content. It omits error behavior for an unknown slug, rate limits, and whether the payload is ever partial beyond the results case, which keeps it from a 5.

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?

Two sentences, front-loaded with the identity of the tool, then a dense enumeration of the returned fields followed by the slug-space caveat. The second sentence is long and packs several clauses, but every clause carries information; little could be cut without losing a returned field or the namespace warning.

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 and no annotations, the description must explain the return payload — and it does so field by field, including the conditional results table. What remains thin is failure handling (invalid or calendar-mismatched slug) and the season parameter's interaction with the weekend, minor gaps for a read-only lookup tool of this shape.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by adding a namespace constraint the schema does not state — that the slug is a race-hub slug and is NOT interchangeable with the results-archive slug. It adds nothing about the season parameter (defaulting, valid range), which the schema already handles.

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?

States a specific verb and resource ('Returns one race weekend's hub') and then enumerates the exact payload: official name, description, host location, weekend bounds, session schedule with UTC times, circuit facts, and conditional top-five results. It also explicitly distinguishes its slug space from formula1-race-calendar's and the results-archive's, so an agent can separate it from siblings without opening a schema.

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?

Clear guidance on the prerequisite: the event_slug must come from formula1-race-calendar and lives in a different slug space than the results-archive slug, which is exactly the mistake an agent would otherwise make. It stops short of naming when to prefer an alternative tool (e.g. per-session data via formula1_session_results), so no explicit exclusions are stated.

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