Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

motogp_next_live_session

Read the next live MotoGP session to get broadcast timing, category, and event metadata as clean JSON. Returns only reviewed public data, excluding playback assets and account state.

Instructions

Read next live MotoGP session metadata. Reads the native next-session request with live=true and returns reviewed public broadcast timing, category and event metadata. Preserves source ordering within nested metadata and null/false/zero values. Content-session UUIDs are not result-session UUIDs. Playback assets, account state, client location and venue narratives are excluded. No query parameters.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "motogp_next_live_session"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden and does meaningful work: it discloses the upstream call shape (native next-session request with live=true), the curated 'reviewed public broadcast' nature of the data, ordering preservation, and explicit exclusions (playback assets, account state, client location, venue narratives). It does not state auth requirements, rate limits, or what is returned when no session is live, which keeps it below 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?

Front-loaded and free of filler – the purpose and the upstream request shape come first, then behavioral guarantees and exclusions. The sentence 'Content-session UUIDs are not result-session UUIDs' is cryptic in isolation and costs more parsing effort than it repays, slightly weakening otherwise tight structure.

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?

For a no-parameter read tool with no output schema and no annotations, the description covers what is returned, what ordering/falsy-value guarantees hold, and what is deliberately excluded. The main residual gap is the empty/'no live session' case, which an agent would need in order to handle a null result without guessing.

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?

Zero parameters, so the baseline is 4. The description usefully confirms 'No query parameters', removing any doubt that a session id or series filter exists, though it adds nothing further since there is nothing to describe.

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 description opens with a precise verb+resource pair ('Read next live MotoGP session metadata') and clarifies that it wraps the native next-session request with live=true. It never names or contrasts with the obvious sibling motogp_latest_session, so an agent must infer the boundary between 'next live' and 'latest' on its own.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is only implied: 'next live session' and the live=true upstream request signal that this is for the upcoming/currently-running session rather than completed results. There is no explicit when-to-use statement, no exclusion naming an alternative such as motogp_latest_session or motogp_sessions, and no guidance for what to do when no session is live.

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

Deploy Server