Crawlora MCP

motogp_events

Read-only

List one MotoGP result season's events and return every event's native result UUID, name, sponsored name, circuit context, date range, test flag and report metadata. season_uuid is required and comes from motogp_seasons; is_finished is the source's own selector, where omission, true and false are distinct and true also includes the current weekend. Empty event arrays are valid, and the returned UUID is the event namespace for motogp_categories, motogp_sessions and motogp_event_files.

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_uuid": "<season_uuid>"
    },
    "name": "motogp_events"
  }
}

Input Schema

Name	Required	Description	Default
`is_finished`	No	Optional native finished-event selector. Omitting it keeps the unfiltered native result; true also includes the current weekend while false selects upcoming weekends, so omission, true and false are distinct.
`season_uuid`	Yes	Required result-season UUID from motogp_seasons, for example e88b4e43-2209-47aa-8e83-0e0b1cedde6e. Result UUIDs are a distinct namespace from broadcast and rider-directory IDs.

Output Schema

Name	Required	Description	Default
`data`	Yes	The tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 11, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description adds genuinely useful behavior beyond that: empty event arrays are valid, the three-way semantics of is_finished (omission, true, false) are distinct, and the returned UUID is the namespace for motogp_categories, motogp_sessions and motogp_event_files. That chaining information is the kind of context annotations cannot convey.

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?

Purpose and required parameter are front-loaded, and the passage is dense with no filler sentences. The long field enumeration in the first sentence partially duplicates the output schema, and the is_finished explanation restates the schema text, which is minor redundancy rather than waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema, full annotation coverage and 100% parameter description coverage, the description fills the remaining gaps an agent needs: the upstream source of season_uuid, edge-case behavior for empty arrays, selector semantics, and the downstream namespace for related tools. Nothing essential to a correct invocation is missing.

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 both parameters are already documented, making 3 the baseline. The description goes beyond the schema by saying where season_uuid originates (motogp_seasons) and by warning that result UUIDs are a distinct namespace, and it reinforces the omission/true/false distinction for is_finished including the current-weekend inclusion rule.

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?

The definition opens with a specific verb and scoped resource: 'List one MotoGP result season's events', then enumerates the returned fields (UUID, name, sponsored name, circuit context, date range, test flag, report metadata). This makes the operation unmistakable. It does not explicitly contrast itself with potentially confusable listing siblings such as motogp_content_events, which keeps it just short of a 5.

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 states the required entry point ('season_uuid is required and comes from motogp_seasons') and explains the tricky selector semantics of is_finished, including that true also includes the current weekend. That is clear workflow context for calling the tool. It stops short of explicit when-not-to-use guidance or an alternative for other event listings.

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

All Crawlora MCP tools Inspect

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.