Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

fanduel_racing_race

Fetch complete FanDuel Racing race details by track and race number, including entries, odds, pools, payouts, and optional handicapping, Timeform, and pool-grid data.

Instructions

FanDuel Racing race detail. Returns one race in full: its conditions, every entry with morning-line and current odds (fractional and decimal), recent price history, runners (jockey, trainer, owner, pedigree, weight, age, scratch and jockey-change flags, win probability), pool totals, probable payouts, will-pays for multi-race bets, the wagers it accepts with their limits, and, once it is official, the finish order and payoffs. Pools, probables and will-pays appear only when the track reports them (mostly official and Up Next races). Pass include to add optional groups: handicapping (speed, class, pace, jockey-trainer record, power rating, career record and the favorite rank of every runner), timeform (Timeform analyst and production comments, tissue price, flags and, once official, how each finisher was beaten, its starting price and a post-race report) and pool_grids (the money bet on each entry's pairings in every pool, mostly once the race is official). A race that is not on today's card returns 404.

Input Schema

NameRequiredDescriptionDefault
trackYesTrack code from the `tracks` route, such as `LRL`
numberYesRace number, 1 to 99, such as `2`
includeNoOptional groups to add (repeat the parameter or comma-separate): `handicapping` per-runner handicapping figures and favorite rank, `timeform` Timeform comments, tissue price, flags and finisher timing, `pool_grids` per-entry pool pairings. Other values return `400`

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.16

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are provided, so the description carries the behavioral burden and does well: it discloses conditional availability of pools/probables/will-pays, the contents of optional groups, and 400/404 error behavior. It does not explicitly state read-only/no side effects, but 'Returns' 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.

Conciseness5/5

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

Front-loads the core purpose and return scope, then enumerates optional groups without wasted framing. Dense but appropriate for a complex data-retrieval tool.

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?

Given no output schema and no annotations, the description is complete enough: it covers return contents, conditional data, optional groups, and error responses. It also flags the key constraint that races not on today's card return 404.

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?

Schema coverage is 100%, so the baseline is 3, but the description earns an extra point by expanding each `include` enum beyond the schema: it lists the specific handicapping, Timeform, and pool-grid contents the agent will receive. Track and number semantics are left to 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?

Opens with a specific verb and resource ('race detail') and immediately scopes it to one race returned in full. The reference to today's card and 404 behavior distinguishes it from list, results, and past-race siblings even without naming them explicitly.

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?

Explains how to use `include` and the 404 condition for races not on today's card, but never explicitly says when to use this instead of `fanduel_racing_races`, `fanduel_racing_results`, or `fanduel_racing_past_race`. Usage is implied by the detail/full-race framing rather than stated as a selection rule.

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