Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

fanduel_racing_past_race

Retrieve complete results for a specific past horse race by date, track code and race number, including finish order, payoffs, odds, runner details and post-race reports.

Instructions

FanDuel Racing past race result. Returns one past race in full: conditions, the finish order with win, place and show payoffs, beaten lengths, starting price and the post-race report of each runner, the payoff of every wager type, and every entry with its morning-line and final odds and its horse, jockey, trainer, owner and pedigree. Needs a date, a track code and a race number from the past-races route; a race that did not run returns 404. A race whose results the service no longer holds returns no results.

Input Schema

NameRequiredDescriptionDefault
dateYesDay as `YYYY-MM-DD`, from `2008-01-01`
trackYesTrack code such as `BEL`
numberYesRace number, 1 to 99

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 must carry behavioral disclosure, and it does substantially: it enumerates the returned race details and states that a non-run race returns 404 and an unavailable result omits `results`. It could do more by explicitly stating that this is a read-only retrieval operation, but the behavior is otherwise well disclosed.

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?

The description is front-loaded with the tool's purpose, then lists the full return contents, required inputs, and error behavior. Despite the long enumeration of race data, every sentence adds useful information for invocation and interpretation, with no filler.

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?

There is no output schema, so the description must explain the return shape, and it does: it lists conditions, finish order, payoffs, odds, runner details, and pedigree. It also covers required inputs and two meaningful failure modes, making the definition complete for this single-record historical retrieval tool.

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 input schema already documents date format, track code examples, and race-number range. The description adds that those identifiers come from the `past-races` route, but otherwise does not add materially beyond the schema, making the baseline 3 appropriate.

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?

The description gives a specific verb and resource: it returns one past FanDuel race in full. It distinguishes this from the sibling list route by saying it needs a specific date, track code, and race number, so an agent can tell it retrieves a single historical race rather than a list.

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

Usage Guidelines4/5

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

The description clearly explains the required context: date, track code, and race number from the `past-races` route. It also covers two important outcome cases, 404 for a race that did not run and missing `results` when the service no longer holds them. It does not explicitly name `fanduel_racing_past_races` or other alternatives, so it falls short of full when-to-use/when-not-to-use guidance.

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