Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

fanduel_racing_results

Retrieve today's official horse racing results, including finish order, win/place/show payoffs, and wager payoffs; filter by track, country, and race type.

Instructions

FanDuel Racing results. Returns today's official races with their results: winning time, finish order with win, place and show payoffs, and the payoff of every wager type. A race the service reports as refunded has no finishers and one payoff whose selection is Refund. Filter by track, country and race type.

Input Schema

NameRequiredDescriptionDefault
pageNoPage number, from 1; default 1, at most 10000
limitNoItems per page, 1 to 200; default 50
trackNoKeep only these track codes (repeat the parameter or comma-separate), such as `LRL`; list codes with the `tracks` route
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
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

A4/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 full behavioral burden. It discloses the return payload (winning time, finish order, win/place/show payoffs, every wager type) and explains a non-obvious edge case: refunded races have no finishers and one payoff with selection 'Refund.' It does not mention pagination behavior or confirm read-only semantics, but for a results endpoint the disclosure is strong.

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?

Three sentences, front-loaded with the core purpose. The first sentence names the tool and scope, the second enumerates the result payload, the third covers the refund edge case, and the final clause lists filters. Every sentence adds value; nothing is wasted.

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?

There is no output schema, so the description must explain return values, and it does so thoroughly (winning time, finish order, payoffs, refund handling). Pagination is documented only in the schema, and the distinction from past-results siblings is left implicit, but the core completeness for this filtered results tool is solid.

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 schema fully documents all six parameters including track code format, country code format, race_type enum values, and exclusion semantics. The description only echoes the filterable dimensions without adding format or constraint detail, so baseline 3 is 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?

States a specific verb and resource: returns today's official races with results. The word 'today's' distinguishes it from siblings like fanduel_racing_past_races, and the description enumerates what the results contain (winning time, finish order, payoffs). An agent can tell exactly what this tool does.

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?

Says 'Filter by track, country and race type,' which implies the optional filters are available, but never states when to use this tool versus alternatives like fanduel_racing_past_races or fanduel_racing_race. Usage is inferred from 'today's' but not explicitly guided.

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