FormFav Horse & Greyhound Racing

Get live bookmaker odds

get_prices

Read-onlyIdempotent

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.

Input Schema

Name	Required	Default
`date`	Yes
`race`	Yes
`track`	Yes
`country`	No	au
`timezone`	No
`race_code`	No	gallops

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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.

Conciseness3/5

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.

Completeness5/5

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.

Parameters5/5

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.

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 ('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.

Usage Guidelines5/5

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.

All FormFav Horse & Greyhound Racing tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?