FormFav Horse & Greyhound Racing

Get track barrier bias

get_track_bias

Read-onlyIdempotent

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.

Input Schema

Name	Required	Default
`track`	Yes
`window`	No
`country`	No	au
`distance`	No
`condition`	No
`race_code`	No	gallops

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

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

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?