Horse & Greyhound Racing stats, form and results data services.
Scored across 11 tools
Each tool targets a distinct entity (meeting, race card, results, prices, predictions, runner, jockey, trainer, track bias, usage), and descriptions explicitly cross-reference each other (e.g. 'get_race_card carries no prices'). The four race-keyed tools (card/results/prices/predictions) share identical arguments and could occasionally be confused for a finished race, since results also return prices on Premium, but the purpose boundaries remain clear.
All 11 tools follow a strict snake_case verb_noun pattern (get_meetings, get_race_card, search_runner, get_track_bias). The single search_* verb is semantically appropriate for lookup versus retrieval, so it reads as a deliberate distinction rather than a deviation.
11 tools sits squarely in the well-scoped range for a racing data domain. Each tool maps to a distinct data surface (form, results, odds, predictions, entity stats, quota) with no filler or redundancies.
The surface covers the full workflow: discover meetings, pull form, price, predict, then settle results, plus entity-level stats (runner, jockey, trainer, track bias) and quota checking. A minor gap is the absence of a meeting-level race list (fields, distances, jump times) — agents must infer race numbers 1-20 from get_meetings' race count.
Get track-by-track performance statistics for a jockey (Pro tier).
Returns career wins, win rate, and per-venue breakdown. Accepts partial names
(e.g. 'mcdonald' will match 'James McDonald'). Stats use a ~2019 data window.
Args:
jockey_name: Jockey name (case-insensitive, supports partial match).
race_code: Race type — 'gallops' (default) or 'harness'. Not available for greyhounds.
window: Optional rolling window in days (14-365) for recent stats.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | ||
| race_code | No | gallops | |
| jockey_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, so the bar is lower, and the description still adds meaningful context: a tier gate ('Pro tier') and a data-freshness caveat ('~2019 data window') that an agent cannot infer from the schema. It does not discuss rate limits or result volume, but those are secondary for a read tool with an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded summary sentence followed by a compact Args block; every line adds a constraint or default. The 'Returns career wins, win rate, and per-venue breakdown' sentence is mildly redundant given an output schema exists, but it is short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter read tool with an output schema and safety annotations, everything an agent needs is present: tier requirement, matching semantics, enum values and defaults, a numeric range, and the staleness of the underlying data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden and does: jockey_name is case-insensitive with partial matching ('mcdonald' matches 'James McDonald'), race_code enumerates 'gallops'/'harness' with a default and greyhound exclusion, and window is bounded at 14-365 days. The 14-365 constraint appears nowhere in the schema and is a genuinely additive detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get track-by-track performance statistics for a jockey') and names the returned content (career wins, win rate, per-venue breakdown). The jockey-specific scope cleanly separates it from the sibling get_trainer_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives real usage conditions: Pro tier required, partial name matching supported, race_code defaults to 'gallops' and is unavailable for greyhounds, and window is an optional recent-form modifier. It stops short of routing between siblings (e.g. when to prefer get_runner_profile over this).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List race meetings for a date.
Returns meetings with venue name, race count, and status. This is typically
the first call to make — use it to discover what tracks are racing on a date.
Args:
date: Race date in YYYY-MM-DD format. Range: 30 days ago to 7 days ahead.
race_code: Race type — 'gallops' (thoroughbred, default), 'harness', or 'greyhounds'.
timezone: IANA timezone for date interpretation (e.g. 'America/New_York',
'Europe/London'). Defaults to Australia/Sydney — set this for overseas
racing so the date matches the local race day.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| timezone | No | ||
| race_code | No | gallops |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuinely non-structured behavior: the date range window (30 days back to 7 days ahead) and the timezone default of Australia/Sydney, both of which affect whether a call succeeds or returns the expected day.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose sentence, then return summary, then workflow hint, then a clean Args block. Every line earns its place; the timezone guidance is slightly wordy but justified by the overseas-racing edge case it prevents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so explaining return fields is supplemental rather than required, and the description still summarizes them. Combined with complete parameter guidance, range limits, and workflow placement, an agent has everything needed to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden and does so: 'date' gets format YYYY-MM-DD plus a valid range, 'race_code' gets all three enum values and the default, and 'timezone' gets IANA format, examples, and the default. This is meaning an agent cannot get from the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with scope ('List race meetings for a date') and adds that it returns venue name, race count and status. It positions itself as the discovery entry point, which implicitly separates it from card/results/profile siblings, but it never names an alternative tool explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'This is typically the first call to make — use it to discover what tracks are racing on a date' gives clear when-to-use context and workflow position. It stops short of stating when-not-to-use or naming the downstream siblings (get_race_card, get_race_results) that this call feeds.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ML win/place probability predictions for a race (Pro tier).
Returns probability scores for each runner: winProb, placeProb, modelRank,
and confidence level. Probabilities sum to 1.0 across all runners in the race.
Not all races have predictions — only those with sufficient runner data.
Args:
date: Race date in YYYY-MM-DD format. Range: 30 days ago to 7 days ahead.
track: Track/venue name (e.g. 'flemington', 'randwick').
race: Race number (1-20).
race_code: Race type — 'gallops' (default), 'harness', or 'greyhounds'.
country: Country code — 'au' (default).
timezone: IANA timezone scoping `date` (default Australia/Sydney). Must
match what you passed to get_race_card()/get_race_results() for the
same race, or this will not resolve to the same meeting.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| race | Yes | ||
| track | Yes | ||
| country | No | au | |
| timezone | No | ||
| race_code | No | gallops |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds meaningful behavior: entitlement requirement (Pro tier), partial data availability, and the normalization rule that probabilities sum to 1.0 across runners. It does not cover latency, caching, or error modes, keeping it out of the top band.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose and return shape, then the availability caveat, then a clean per-parameter block. No sentence is filler, and the one operational trap (timezone mismatch silently resolving to a different meeting) is called out where the parameter is described.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, yet the description still names the key return fields (winProb, placeProb, modelRank, confidence), and it covers everything else an agent needs: entitlement, parameter formats, availability limits, and the timezone alignment requirement with sibling calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full parameter burden and does so thoroughly: date format with a range (30 days back to 7 ahead), track naming convention with examples, race number bounds (1-20), enumerated race_code values, country default, and an explicit cross-tool consistency rule for timezone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get ML win/place probability predictions for a race') and immediately scopes it with a tier qualifier. This is clearly distinguishable from siblings like get_race_card (entries) and get_race_results (outcomes), since it returns modeled probabilities rather than factual race data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives real usage context: Pro tier gating, the availability caveat ('Not all races have predictions — only those with sufficient runner data'), and the requirement that timezone match what was passed to get_race_card()/get_race_results(). It stops short of explicitly stating when to prefer this tool over those siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current bookmaker odds for every runner in a race (Premium tier).
Use this for any question about odds, prices, the market, favourites or
"what is X paying". get_race_card() carries no prices. Takes the same
arguments as get_race_card(), so a race you pulled form for can be priced
unchanged.
Each runner has a `prices` list with one entry per bookmaker and market type
(`marketType` is 'fixed' or 'tote'; one bookmaker can quote both), carrying
`bookmaker`, `win` and `place` decimal odds and its own `capturedAt` (books
update independently, so freshness is per bookmaker). Win-market fluctuation
fields `open`, `close`, `high`, `low` and `movements` appear when the bookmaker
publishes them, and `startingPrice` is that bookmaker's own settled price once
the race has run.
Before the jump each priced runner also has a `market` summary across
bookmakers: `best` (longest win price) and `bestBookmakers`, `consensus`
(median price), and `fair` / `fairProbability` (margin removed by the power
method, which allows for the favourite-longshot bias), `edge` (best vs fair)
and `rank` (1 = favourite). Consensus and fair need 3 bookmakers, or 2 of the
market leaders where the race is run: TAB, Ladbrokes and Sportsbet in
Australia, New Zealand and Hong Kong; Ladbrokes UK (with Coral) and William
Hill in the UK, Ireland and Europe. `edge` describes the prices; it is not a
tip. The race-level `market` gives each bookmaker's `overround` and
`bestOverround`, the book made of the best prices.
A quote older than the freshness allowance for this race's time to jump comes
back with `stale: true` and no `win`/`place`; the fluctuation fields stay valid
as a record. That allowance tightens as the race approaches, and a finished
race is always stale, which is not a coverage gap. An empty `prices` list or
only stale quotes means no current price, not that there is no market. Runners
marked `scratched` come from our race card; a missing price does not mean
scratched. Prices are cached for seconds: re-asking shortly before the jump is
fine, but do not poll in a loop.
Requires a Premium or Enterprise account; other tiers get a 403 telling them
so. Pro accounts get results (get_race_results) but not odds.
Args:
date: Race date in YYYY-MM-DD format. Range: 30 days ago to 7 days ahead.
track: Track/venue name (e.g. 'flemington', 'randwick'). Case-insensitive.
race: Race number (1-20).
race_code: Race type — 'gallops' (default), 'harness', or 'greyhounds'.
country: Country code — 'au' (default), 'nz', 'hk', 'gb', 'us', etc.
timezone: IANA timezone for date interpretation (e.g. 'Europe/London').
Defaults to Australia/Sydney — set this for overseas racing so the
date matches the local race day.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| race | Yes | ||
| track | Yes | ||
| country | No | au | |
| timezone | No | ||
| race_code | No | gallops |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations already covering the safe-read profile, the description adds substantial non-obvious behavior: 403 for non-Premium tiers, per-bookmaker freshness with `stale: true` semantics, the caching/'do not poll in a loop' constraint, and the crucial interpretation rule that an empty or all-stale `prices` list means no current price rather than no market. It also preempts a likely misreading by separating `scratched` from missing prices.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and the routing note are correctly front-loaded, and the Args block is tight. However, an output schema exists, yet several paragraphs laboriously enumerate return fields (`prices`, `bookmaker`, `win`/`place`, `open`/`close`/`high`/`low`, `overround`, `bestOverround`) — roughly half the text restates structured data. The semantic caveats (stale, consensus needing 3 bookmakers, edge is not a tip) do earn their place; the field inventories do not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a live-odds tool with tier gating, per-bookmaker caching, staleness decay and derived market metrics, the description covers every decision an agent must make before calling: eligibility, argument interpretation, freshness expectations, and how to report thin data. Nothing needed to call it correctly or interpret its output is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the full load — and it does, with an Args block giving format (YYYY-MM-DD), accepted range (30 days back to 7 ahead), race bounds (1-20), enum values for race_code and example country codes. The timezone explanation adds real meaning the schema cannot: it controls date interpretation and defaults to Australia/Sydney, which overseas callers would otherwise get wrong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource ('Get current bookmaker odds for every runner in a race') and immediately disambiguates from the closest sibling by noting 'get_race_card() carries no prices.' An agent can pick between the two without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit use trigger ('any question about odds, prices, the market, favourites or "what is X paying"'), names the alternative that lacks this data, and states the access-tier boundary (Premium/Enterprise only; Pro accounts get get_race_results but not odds). When-to-use, when-not-to-use and the fallback are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full race form for a specific race.
Returns all runners with barriers, jockeys, trainers, form, and ratings.
Use get_meetings() first to find available tracks for a date.
Args:
date: Race date in YYYY-MM-DD format.
track: Track/venue name (e.g. 'flemington', 'randwick'). Case-insensitive.
race: Race number (1-20).
race_code: Race type — 'gallops' (default), 'harness', or 'greyhounds'.
country: Country code — 'au' (default), 'nz', 'hk', 'gb', 'us', etc.
timezone: IANA timezone for date interpretation (e.g. 'America/New_York',
'Europe/London'). Defaults to Australia/Sydney — set this for overseas
racing so the date matches the local race day.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| race | Yes | ||
| track | Yes | ||
| country | No | au | |
| timezone | No | ||
| race_code | No | gallops |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real behavioral context beyond them: the full-field return payload and the timezone caveat that the default Australia/Sydney may shift the race day for overseas meetings, which is a genuine correctness trap an agent would otherwise hit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose and return contents, then a compact Args block with no filler sentences. The Args list largely restates the schema keys, which is redundant in principle but justified here given 0% schema coverage; length is appropriate for a six-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be detailed, and the description still summarizes them. Combined with the prerequisite call to get_meetings(), the timezone disambiguation, and complete parameter documentation, an agent has everything needed to invoke this correctly on the first try.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the entire burden and does so: formats (YYYY-MM-DD, IANA timezone), value ranges (race 1-20), enum-like choices (gallops/harness/greyhounds, country codes), defaults (gallops, au, Australia/Sydney), case-insensitivity for track, and worked examples. Every one of the six parameters is meaningfully specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get the full race form for a specific race') and immediately enumerates what comes back: runners with barriers, jockeys, trainers, form, and ratings. This distinguishes it cleanly from siblings like get_race_results (results, not pre-race form) and get_runner_profile (single runner, not the full field).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit sequencing instruction: 'Use get_meetings() first to find available tracks for a date,' which names the sibling and the precondition. It does not, however, state when to prefer this over get_race_results or get_predictions for a given race, so the routing guidance is partial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the result of a race, or of every race at a meeting (Pro tier).
Takes the same arguments as get_race_card(), so a race you pulled form for
can be looked up here unchanged. Omit `race` to get the whole card in one
call instead of looping race numbers.
Each runner carries `outcome` ('placed', 'did_not_finish', 'scratched' or
'pending') plus `position` and `margin` when they apply — branch on
`outcome`, since `position` is omitted when it does not. Dead heats share a
position. Each race carries `resultStatus`: 'final', 'interim', 'pending' or
'abandoned'.
On Pro, results are scraped by a pipeline run every 2-3 hours, not streamed,
so a race that has just run reads 'pending' until the next run picks it up.
That is not an error — do not retry in a loop. On Premium/Enterprise the same
call fills in results from the real-time feed before that run, and each runner
also carries live `prices` (see get_prices() for odds on a race that has not
run).
Coverage matches get_race_card(): every market we carry form for. Where no
racing body's results are scraped (US, Canada, Japan, France, ...) the result
comes from bookmaker results feeds and appears about two hours after the race,
with finishing positions but no margins.
Args:
date: Race date in YYYY-MM-DD format. Range: 30 days ago to 7 days ahead.
track: Track/venue name (e.g. 'flemington', 'randwick'). Case-insensitive.
race: Race number (1-20). Omit for every race at the meeting.
race_code: Race type — 'gallops' (default), 'harness', or 'greyhounds'.
country: Country code (e.g. 'au' default, 'nz', 'gb', 'us', 'jp').
timezone: IANA timezone for date interpretation (e.g. 'Europe/London').
Defaults to Australia/Sydney — set this for overseas racing so the
date matches the local race day.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| race | No | ||
| track | Yes | ||
| country | No | au | |
| timezone | No | ||
| race_code | No | gallops |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial tier-specific behavior: results are scraped every 2-3 hours on Pro rather than streamed, so freshly run races read 'pending'; Premium/Enterprise fill from a real-time feed; unscraped territories fall back to bookmaker feeds with ~2 hour latency and no margins. That is context the agent cannot get from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and the key routing decision, then behavior, then args. Density is high and every paragraph earns its place given the zero schema coverage, though the args section restates some hints (defaults) that the schema technically already carries.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter, tier-dependent, multi-territory tool with an output schema, the description covers scope, filtering, failure modes, latency expectations, coverage gaps, and every argument's semantics. An agent could invoke this correctly on the first try without further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden — and it does: date format plus its 30-days-back-to-7-days-ahead range, track examples and case-insensitivity, race number bounds 1-20, race_code enum values, country codes with default, and why timezone matters for overseas race days. This is meaning the schema does not encode at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get the result of a race') and immediately extends scope to a whole meeting. It also distinguishes itself from sibling get_race_card by noting argument compatibility, so an agent can route between form and results without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing: same arguments as get_race_card, omit `race` to avoid looping race numbers, and defer to get_prices for odds on an unrun race. It also states a negative rule — do not retry a 'pending' race in a loop — which is exactly the kind of when-not guidance that prevents agent misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full statistics profile for a runner (Pro tier).
Returns career summary, distance/condition/track stats, spell performance,
jockey partnerships, class profile, and running style. Use search_runner()
first to find the runner ID.
Note: conditionStats uses full career scope while other stats use a ~2019 window.
Stats sections may be null when sample size is below threshold.
Args:
runner_id: Runner ID (from search_runner results).
window: Optional rolling window in days (14-365) for recent stats.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | ||
| runner_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the description's added value is the Pro tier requirement, the conditionStats full-career vs ~2019 window scope caveat, and null sections below sample-size thresholds. Those are genuinely useful quirks not available in structured fields, though nothing is said about rate limits or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then returned sections, then prerequisites, then caveats, then args — every line earns its place with no filler. The section list is dense but directly informs invocation expectations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return format needn't be explained, and the description still covers scoping, null-ability, Pro gating, and parameter sourcing. The main residual gap is how window interacts with the ~2019 vs full-career scope split between stat groups.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the load — and it does: runner_id's provenance (search_runner results) and window's meaning, units, and 14–365 range, none of which appear in the schema. It could go further on how window interacts with the default career window.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get the full statistics profile for a runner') and enumerates the returned sections, which cleanly distinguishes it from siblings like get_jockey_stats and get_trainer_stats. An agent can identify the scope without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the prerequisite path: 'Use search_runner() first to find the runner ID', which routes the agent to the correct sibling. It does not state when-not to call it (e.g., for non-Pro tiers or when only recent stats are needed), so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get barrier/box bias statistics for a track (Pro tier).
Returns win rates by barrier position with advantage scores (win-rate points
above/below expected, 0-1 scale; expected = 1 / average field size). For
greyhounds, barrier numbers represent box positions (1-8); for harness the
barrier is the starting position. `totalRaces` counts races with a recorded
winner. `strongestBarrier`, `weakestBarrier` and `biasStrength` consider only
barriers with at least 30 starts, so thin barriers (still listed in
`barrierStats`) cannot drive them. `biasStrength` is "none" unless the
barriers differ by more than chance, so "none" can also mean too little
data to tell; treat a single barrier's advantage on few starts as noise. `conditionStats` is track-level (races and field size by
going) and is not scoped by `distance`.
By default the response also carries `distanceStats`: the same barrier
breakdown per distance band at that track (gallops: Sprint <1400m / Mile /
Middle / Classic / Staying ≤3200m / Marathon (jumps); harness: Mile/Middle/Staying/Long;
greyhounds: Sprint/Medium/Distance), shortest band first. Barrier bias is
usually distance-specific, so prefer the band — or a `distance` scope — over
the whole-track figures when advising on a particular race.
Args:
track: Track/venue name (e.g. 'flemington', 'randwick').
race_code: Race type — 'gallops' (default), 'harness', or 'greyhounds'.
country: Country code — 'au' (default), 'nz', 'hk', 'gb'.
window: Optional rolling window in days (14-365) for recent stats.
condition: Optional track condition filter (e.g. 'Good', 'Soft', 'Heavy'). Only applies with window.
distance: Optional metres scope — one distance ('1200') or an inclusive range
('1200-1600'). Scopes the top-level report and recentStats to those races;
`distanceFilter` echoes it and `distanceStats` holds one 'Custom' entry for
the slice (its minDistance/maxDistance are the distances actually found).
Must be within 200-5000 m; barriers with under 5 starts in the slice are
omitted. Returns 404 when the track has no data and 422 for a bad value.
| Name | Required | Description | Default |
|---|---|---|---|
| track | Yes | ||
| window | No | ||
| country | No | au | |
| distance | No | ||
| condition | No | ||
| race_code | No | gallops |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (read-only, idempotent, non-destructive), and the description adds substantial extra context: Pro-tier requirement, 404/422 error conditions, the 30-start threshold behind strongestBarrier/weakestBarrier/biasStrength, why biasStrength can be 'none' for two different reasons, the 5-start omission under distance scoping, and that conditionStats is track-level and not distance-scoped. That is far beyond what the annotations declare.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Long but front-loaded with the purpose and return semantics before the Args section. Some content is redundant (shape of distanceStats repeated in prose and Args) and the mid-paragraph line break around conditionStats is awkward, but nearly every sentence carries actionable detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter analytics tool with complex derived fields and a distance-band default, the description covers return-field meaning, edge cases, error behavior and parameter interactions completely. An output schema exists, so explaining return values is a bonus rather than a requirement, and nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% with 6 parameters and zero enums, so the description must carry the full burden. It documents every parameter: track examples, race_code valid values and default, country codes, window range (14-365) and its dependency on condition, condition requiring window, and distance syntax, range limits (200-5000m), scoping behavior, and error responses.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get barrier/box bias statistics for a track') and scopes it to barrier/box positions, which none of the sibling stats tools (jockey, trainer, prices, race card) cover. An agent can select it from the name+description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear operational guidance: prefer the distance band or a `distance` scope over whole-track figures when advising on a particular race, and treat single-barrier advantages on few starts as noise. It does not explicitly name alternatives or exclusion conditions, but the guidance on which scope to pick is concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get track-by-track performance statistics for a trainer (Pro tier).
Returns career runners, win rate, and per-venue breakdown. Accepts partial names.
Stats use a ~2019 data window.
Args:
trainer_name: Trainer name (case-insensitive, supports partial match).
race_code: Race type — 'gallops' (default), 'harness', or 'greyhounds'.
window: Optional rolling window in days (14-365) for recent stats.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | ||
| race_code | No | gallops | |
| trainer_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this as read-only, idempotent and not open-world, so the bar is lower. The description still adds non-obvious behavioural context: the Pro-tier gating, the stale ~2019 data window, and fuzzy partial-name matching — all things the agent cannot derive from annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose and return content, then a compact Args block. The parameter list is somewhat redundant in form, but since the schema has zero descriptions it earns its place rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the description covers gating, data staleness, matching behaviour and parameter ranges. It stops just short of stating error/empty-result behaviour for unmatched names, which is the only real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and no enums are declared, so the description carries the full burden — and it does: it documents case-insensitive partial matching for trainer_name, the three valid race_code values with 'gallops' as default, and the 14–365 day range for window. Without this text the parameters would be unusable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and resource ('track-by-track performance statistics for a trainer') and enumerates the return content: career runners, win rate, per-venue breakdown. The trainer focus separates it cleanly from the sibling get_jockey_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The '(Pro tier)' tag and the note that stats use a ~2019 data window imply context and eligibility, but the description never says when to prefer this over neighbours like get_runner_profile or search_runner, nor what to do when a trainer matches nothing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check how much of the daily request quota is left. Free to call: it does not count.
The quota is a rolling 24-hour window, not a midnight reset, shared by all of the
user's API keys and connected apps. Every other tool call counts as one request.
Returns tier, unlimited, limit, used and remaining, and overQuota. While overQuota is
true, other tools fail with a rate-limit error and availableAt (UTC) says when requests
are allowed again. used, remaining and overQuota can be missing if live counts are
briefly unavailable; limit and remaining are missing on an unlimited tier.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses that the quota is a rolling 24-hour window shared across all API keys and connected apps, that other tool calls consume quota, which fields are returned, and how overQuota affects other tools. It also documents exactly which fields may be missing and under what conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and cost, then provides structured details about quota behavior and return fields. Every sentence adds useful information without unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only quota check with an output schema, the description is complete. It explains return values and edge cases such as missing fields, overQuota behavior, and the rolling window, leaving no important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics burden. The schema coverage is 100%, and no additional parameter guidance is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: checking the remaining daily request quota. It is immediately distinguishable from all sibling tools, which retrieve racing data rather than quota information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains that this tool is free to call and does not count toward the quota, while every other tool call does. It also explains the consequence of overQuota being true, but does not explicitly recommend when to call it relative to other tools beyond the implied check-before-use scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for a runner (horse/greyhound) by name (Pro tier).
Returns matching runners with IDs, sire/dam for disambiguation, and career starts.
Use the returned runner ID with get_runner_profile() for full stats.
Args:
query: Partial name to search for (minimum 3 characters).
race_code: Race type — 'gallops' (default), 'harness', or 'greyhounds'.
country: Optional country filter — 'au', 'nz', 'hk', 'gb'.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| country | No | ||
| race_code | No | gallops |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile needs no restating. The description adds real behavioral context beyond that: a Pro tier entitlement requirement and a hard 'minimum 3 characters' constraint on the query. It does not mention pagination or result limits, keeping it from 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then the return contents, then the hand-off tool, then the arg list. Every sentence earns its place, and the Args block is justified rather than redundant because the schema has zero parameter descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing, the description usefully previews the return shape (IDs, sire/dam for disambiguation, career starts) and closes the workflow loop to get_runner_profile. The Pro tier gate and query minimum length are the kinds of constraints an agent needs before calling, and both are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are no enums in the schema, so the description carries the full burden — and it does: query (partial name, min 3 chars), race_code with its three allowed values and the default of 'gallops', and country with four allowed codes. This supplies value the schema does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search for a runner (horse/greyhound) by name'), names the resource domain, and distinguishes itself from the sibling get_runner_profile by clarifying that it returns IDs rather than full stats. An agent can pick between the two without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context (search by partial name) and an explicit next step: 'Use the returned runner ID with get_runner_profile() for full stats.' That routing is genuinely helpful, but there is no stated when-not-to-use or comparison against other lookup siblings, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_usageget_pricesget_jockey_statsget_meetingsget_predictionsget_race_cardget_race_resultsget_runner_profileget_track_biasget_trainer_statssearch_runner
Add one secure layer between your agents and this server.