Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

fanduel_racing_races

List today's FanDuel Racing races with track, post time, status, type, surface, class, distance, purse and runner count; filter by track, country, race type, status, open state or minutes to post.

Instructions

FanDuel Racing races. Lists today's races (about 500 across all tracks) with track, number, post time, minutes to post, status, race type, surface, class, distance, purse and runner count. Filter by track, country, race type, status, open or closed, or the next N minutes; sort by minutes to post, post time or race number. total counts every match so page and limit page through them.

Input Schema

NameRequiredDescriptionDefault
openNo`true` for races still open for betting (`O` and `IC`), `false` for off or official races; omit for both
pageNoPage number, from 1; default 1, at most 10000
sortNoSort: `mtp` (minutes to post), `post_time`, `race_number`; default is the service's own order
limitNoItems per page, 1 to 200; default 50
orderNo`asc` or `desc`; default `asc`. Only valid together with `sort`
trackNoKeep only these track codes (repeat the parameter or comma-separate), such as `LRL`; list codes with the `tracks` route
statusNoKeep only these race statuses (repeat the parameter or comma-separate): `O` Open, `IC` Up Next, `SK` Race Off, `RO` Race Official
countryNoKeep only races or tracks in these countries (repeat the parameter or comma-separate): upper-case three-letter codes such as `USA`, `GBR`, `AUS`. Today's codes are listed in the `filters` route's `countries`; lower-case or two-letter values return `400`
race_typeNoKeep only these race types (repeat the parameter or comma-separate): `T` Thoroughbred, `H` Harness, `Q` QuarterHorse, `L` Thoroughbred LARC
within_minutesNoKeep races that post within this many minutes, 1 to 1440
exclude_countryNoDrop these countries (repeat the parameter or comma-separate), same codes as `country`

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.16

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 reasonably well: it discloses the result-set scale (~500 races today), the field payload, and the non-obvious fact that `total` counts every match so page/limit traverse the full set. It omits auth requirements, rate limits and failure modes, which keeps it short of 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?

Three sentences, front-loaded with what it lists, then filters/sorts, then pagination semantics. Dense enum-style enumeration in the middle sentence is a bit list-heavy but every sentence carries information; no filler.

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 an 11-parameter, zero-required, read-only listing tool with no output schema, the description covers the returned fields and paging model, which is what an agent needs to construct calls. Missing only operational context (whether results are cached, update frequency of status/post time during the day) that would matter for a live-odds listing.

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% and each parameter is already documented in detail (enum meanings, ranges, defaults, 400 on bad country codes). The description restates the same filter and sort surface at a summary level and adds no new syntax, precedence rules for combining filters, or interaction details (e.g. how `within_minutes` composes with `status`).

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?

States a concrete verb and resource: lists today's races in FanDuel Racing, with scope quantified (~500 across all tracks) and returned fields enumerated. 'Today's races' implicitly separates it from fanduel_racing_past_races and from the single-race fanduel_racing_race, but no sibling is named explicitly, so routing still requires inference.

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 through the filter and sort menu ('Filter by track, country, race type, status, open or closed, or the next N minutes'), which tells an agent what the tool is good for. However there is no explicit when-to-use/when-not statement and no pointer to alternatives such as fanduel_racing_search, fanduel_racing_race, or fanduel_racing_results.

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