Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

formula1_json_meetings

Retrieve Formula 1 meeting IDs for a given season from the official JSON API, including names, country codes, and current-meeting flags, to use with results and dataset tools.

Instructions

Formula 1 meeting ids from the JSON API. Returns one season's meeting dropdown from formula1.com's own JSON API: each meeting's numeric id, name, country code and ISO country name, and which one the site marks as current. Use the id with formula1-json-results and formula1-json-meeting-datasets; the JSON API requires the site's embedded public-bundle key, which this service rediscovers on first use and refreshes when the gateway rejects it.

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": {
      "season": "<season>"
    },
    "name": "formula1_json_meetings"
  }
}

Input Schema

NameRequiredDescriptionDefault
seasonYesFour-digit championship year, 1950 through next season example(2026)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose a non-obvious operational trait: the JSON API needs the site's embedded public-bundle key, which the service rediscovers on first use and refreshes when the gateway rejects it. That auth/key-refresh behavior is exactly the kind of context annotations would otherwise provide. It stops short of rate limits, latency, or what an error response looks like.

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?

Three sentences, front-loaded with the resource and return fields, then the follow-on tools, then the auth caveat — a sensible order with little filler. Minor friction: sibling tools are written with hyphens ('formula1-json-results') rather than the actual underscore names, and 'meeting dropdown' is slightly vague phrasing.

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?

There is no output schema, so the description correctly enumerates the returned fields and adds the key-management caveat an agent would otherwise not know. It leaves minor gaps such as ordering of results or the meaning of the 'current' flag, but nothing that would cause a mis-call.

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?

There is a single required parameter and schema coverage is 100%, including the 1950-to-next-season range, so the schema already does the heavy lifting. The description adds only the implication that exactly one season is returned per call, with no format or edge-case 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 opens with a concrete verb+resource ('meeting ids from the JSON API') and immediately specifies the exact returned fields: numeric id, name, country code, ISO country name, and current marker. The 'JSON API' qualifier plus naming of formula1-json-results and formula1-json-meeting-datasets lets an agent separate it from the sibling formula1_meetings and openf1_meetings variants.

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?

It gives a clear downstream use case: take the id and feed it to formula1-json-results and formula1-json-meeting-datasets, which is real routing guidance. It does not state when a caller should prefer this JSON-API variant over the plain formula1_meetings or openf1_meetings siblings, so alternatives are only implied by the 'JSON API' wording.

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