Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

motogp_events

Retrieve native MotoGP season events by season UUID, with an optional finished-status selector to filter race weekend metadata from anonymous results.

Instructions

List native season events. Reads anonymous MotoGP results metadata using the result UUID namespace. Historical categories and test events retain their native source fields.

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

NameRequiredDescriptionDefault
is_finishedNoNative selector; omitted, true and false are distinct; true also includes the current weekend
season_uuidYesResult UUID from the corresponding discovery resource

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

C2.7/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It does add real context: reads are anonymous (no auth implied), the identifier comes from the results UUID namespace, and historical/test events keep their source fields. However, it never states ordering, pagination, scope limits, or what an "event" record contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with no padding, and the action is front-loaded. But the second and third sentences lean on unexplained vocabulary ("result UUID namespace", "native source fields") that costs more clarity than the brevity saves.

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

Completeness2/5

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

The tool has no output schema and no annotations, so the description should explain the shape and ordering of returned events and the meaning of "native" versus content events. It leaves an agent unable to predict the response payload or decide confidently between this and sibling event tools.

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 are fully documented in the schema, including the non-obvious three-state behavior of is_finished. The description adds nothing about either parameter beyond a loose nod to the UUID namespace, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description leads with a verb+resource ("List native season events"), but "native" is undefined jargon and the phrasing does not separate this tool from near siblings such as motogp_content_events, motogp_sessions, or motogp_seasons. An agent can tell it lists events for a season, but not what makes these events different from the alternatives.

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

Usage Guidelines2/5

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

There is no explicit when-to-use, when-not-to-use, or named alternative. The only implicit guidance is that a season UUID is needed, which the schema already states. Nothing tells the agent to prefer this tool over motogp_content_events or motogp_latest_session.

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