Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

motogp_entry_grid_options

Resolve a MotoGP content event to its entry-list and starting-grid selectors, returning UUID and season/shortname/category tuples only when native result-event bridges and category names match.

Instructions

Discover MotoGP entry-list and grid selectors. Resolves a native content event's explicit result-event bridge and categories. Returns complete entry-list UUID tuples and GP starting-grid season/shortname/category tuples. Uses the site's native category-name conversion. Missing bridges or mismatched category namespaces fail rather than inventing identifiers. No source rows or media are fetched for discovery.

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_entry_grid_options"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesContent-event UUID from content event discovery; this is a different namespace from result UUIDs

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well by disclosing failure behavior for missing bridges and mismatched category namespaces, noting use of the site's native category-name conversion, and clarifying that no source rows or media are fetched. It does not explicitly state read-only safety or rate-limiting behavior, but the discovery framing strongly implies a read operation.

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?

The description is front-loaded with purpose and return types, then adds behavioral constraints without obvious filler. It is dense with domain jargon, but every sentence contributes useful information about resolution behavior or failure modes.

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 one-parameter discovery tool with no annotations or output schema, the description adequately explains what will be returned at a high level and what failure conditions mean. It could be slightly more explicit about the returned tuple structure or pagination, but the essential behavior is covered.

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 description coverage is 100%, so the single id parameter is already fully documented as a content-event UUID in a different namespace from result UUIDs. The description reinforces the content-event context but adds no syntax, formatting, or example details beyond the schema.

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 states a specific action and resource: discovering MotoGP entry-list and grid selectors and returning UUID/season/shortname/category tuples. It clearly distinguishes this from fetching actual entry rows or media. However, it does not explicitly contrast with siblings like motogp_entries or motogp_starting_grid.

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 implied: this is a discovery step for resolving a content event's bridge and obtaining identifiers, and it will fail on missing bridges or category mismatches. There is no explicit guidance on when to call this instead of direct entry or starting-grid tools, nor are prerequisites such as authentication or prior discovery calls stated.

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