FormFav Horse & Greyhound Racing

Get race results

get_race_results

Read-onlyIdempotent

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

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.

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.

Input Schema

TableJSON Schema

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

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 18, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only cover the generic safety profile (readOnly, idempotent, non-destructive); the description adds far more: a 2-3 hour scrape cadence, the fact that 'pending' is expected and must not be retried, dead-heat position sharing, and a coverage caveat for US/Canada/Japan/France where results arrive ~2 hours late without margins. This is exactly the behavioral context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

Front-loaded and tightly organized: semantics, then return-value branching, then latency behavior, then coverage caveats, then args. Dense rather than padded, though the coverage paragraph and a few parentheticals could be trimmed without losing meaning.

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 6-parameter read tool with an output schema, everything an agent needs is present: argument semantics, how to branch on `outcome`/`position`/`resultStatus`, latency expectations, and geographic coverage limits. The output schema covers return shape, so the description correctly spends its words on behavior instead.

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 carries the full burden — and it does: date format and allowed range (30 days back to 7 days ahead), track case-insensitivity, race range 1-20 and omission semantics, race_code enum values, country codes with default, and the timezone's role in interpreting the date with its default. Nothing an agent needs to fill these fields is missing.

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+resource ('Get the result of a race, or of every race at a meeting') and immediately bounds scope (Pro tier, single race vs whole meeting). It names the sibling get_race_card() and states the argument/coverage relationship, so an agent can place it relative to the other eight tools without opening a schema.

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?

Gives concrete operating guidance: omit `race` to fetch the whole card in one call instead of looping, reuse the same args as get_race_card(), and do not retry on 'pending'. It stops short of an explicit when-not-to-use / alternative-tool statement (e.g. 'use get_race_card for pre-race form'), leaving the routing to inference.

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?