Crawlora MCP

motogp_content_event

Read-only

Read native public metadata for one MotoGP content event and return its event/category/venue/track/season/schedule context plus explicit results-api event and circuit UUID bridges when the source provides them. id is a required content-event UUID from motogp_content_events or a session's event.id, not a result-event UUID. Missing bridges are not invented, and assets, playback, client location and venue narratives are excluded.

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": {
      "id": "<id>"
    },
    "name": "motogp_content_event"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Required content-event UUID from the content event catalog (or a session's event.id), for example 3f3d3f5e-851c-42d2-887a-8ce8b41fa908. This is a metadata ID, not a result-event UUID.

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.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the description's added value is in data behavior: bridges to results-api event/circuit UUIDs are returned 'when the source provides them' and 'missing bridges are not invented', which tells the agent to expect partial linkage rather than fabricated values. It also itemizes what is deliberately absent (assets, playback, location, narratives), a useful content-boundary disclosure. Return shape is left to the output schema.

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?

Verb and resource are front-loaded in the first clause, and each subsequent clause adds a distinct constraint (UUID provenance, bridge honesty, exclusions). The second sentence is long and clause-dense, which slightly reduces scannability.

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?

For a single-parameter read tool with an output schema, the definition covers what it returns, where the id must come from, what it must not be confused with, and which adjacent data domains are out of scope. Nothing needed to call it correctly is missing.

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?

With one parameter at 100% schema description coverage, the schema already carries the UUID semantics and the 'not a result-event UUID' caveat. The description restates that distinction and the catalog/session sourcing, which reinforces but adds little meaning 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?

States a specific verb and resource ('Read native public metadata for one MotoGP content event') and enumerates the returned context (event/category/venue/track/season/schedule). It also differentiates itself from the result-side tools by insisting the id is a content-event UUID, not a result-event UUID, and points to motogp_content_events or a session's event.id as the source.

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?

Clearly establishes the prerequisite (an id sourced from motogp_content_events or a session's event.id) and an explicit exclusion (not a result-event UUID), plus scope exclusions for assets, playback, client location and venue narratives that route the agent elsewhere. It stops short of naming the alternative tools to call for those excluded domains, so guidance is strong but not fully explicit.

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.