Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

formula1_json_meeting_datasets

Retrieve available Formula 1 session datasets for a specific meeting to discover valid dataset paths, labels, and availability for querying results.

Instructions

Formula 1 session datasets for one meeting, from the JSON API. Returns one meeting's dataset dropdown: each dataset's label, its relative path (with the meeting or session parameters), whether it is a session result, whether it is available and the editorial session type. This is the discovery surface for the dataset values formula1-json-results accepts for that meeting; a sprint dataset appears only on sprint weekends.

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>",
      "meeting": "<meeting>"
    },
    "name": "formula1_json_meeting_datasets"
  }
}

Input Schema

NameRequiredDescriptionDefault
seasonYesFour-digit championship year example(2026)
meetingYesNumeric meeting id from formula1-json-meetings example(1299)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations at all, the description carries the full behavioral burden and does so well: it enumerates the returned fields (label, relative path with meeting/session params, session-result flag, availability, editorial session type) and discloses a real conditional quirk — a sprint dataset appears only on sprint weekends. It omits auth, error handling, and whether unavailable datasets should be filtered, keeping it short of 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?

Three sentences, front-loaded with the resource and scope, then the return shape, then the relationship to the sibling tool. The middle sentence's field list is dense but each item is informative; no filler or repetition.

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?

No output schema exists, so the description must describe return values, and it does so with a concrete field list plus the sprint-weekend caveat. Combined with fully documented input parameters, an agent has enough to call this correctly; only edge cases like meetings with zero datasets are unaddressed.

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 coverage is 100% and both parameters (season, meeting) are already described in the schema, including the meeting id's provenance from formula1-json-meetings. The description only echoes that meeting/session parameters appear in the returned paths, adding little semantic meaning beyond the structured fields.

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?

"Formula 1 session datasets for one meeting, from the JSON API" names the resource and scope precisely, and the third sentence ties it to formula1-json-results as its consumer. The retrieval verb is only implicit ("Returns one meeting's dataset dropdown"), but an agent can still distinguish this from results-fetching siblings without reading 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 Guidelines4/5

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

The description explicitly frames itself as "the discovery surface for the dataset values formula1-json-results accepts for that meeting," which is a clear when-to-use rule pointing at the downstream sibling. It stops short of stating when not to call it (e.g., if the dataset name is already known) or whether the path values can be used directly.

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